Infrastructure delivery,
without the mystery.

The hard part is not producing a plan.

The hard part is proving that the infrastructure change somebody reviewed is the change that eventually ran—with the same source code and infrastructure target.

Installed into the customer boundary.

Argus Deploy is delivered as a versioned infrastructure module plus immutable runner and dashboard images. The platform is installed by a human from a dedicated bootstrap root; it never manages its own installation through its runners.

1. 01

   Create the bootstrap boundary.

   Begin from isolated local state, create the protected S3/KMS backend, then migrate the same root into that customer-owned backend.

2. 02

   Publish immutable images.

   Copy the supplied runner and dashboard release images into source ECR in the primary account. Regional execution pulls from customer ECR.

3. 03

   Apply one module per account.

   The primary account creates the dashboard, plans storage, orchestrator, source repositories, and regional workers. Workload accounts create only their local execution plane.

4. 04

   Choose dashboard ingress.

   The module can create the ALB by default or attach Argus Deploy to a customer-provided ALB. A supplied ACM certificate selects HTTPS on port 443.

5. 05

   Commit the trigger workflow.

   A small GitHub-hosted launch job uses OIDC only to start the customer-resident orchestrator. The actual infrastructure work does not run on GitHub-hosted compute. With the default 1 vCPU / 2 GiB worker, current public list prices put raw Fargate task compute at roughly one-seventh of GitHub's standard 2-core Linux runner minute. Included GitHub minutes, different CPU sizes, image startup, and other AWS charges can change the real ratio.

module "argus_deploy" {
  source = "git::https://github.com/.../bootstrap?ref=<release>"

  infrastructure_repository = "acme/infrastructure"
  execution_folders          = ["network", "compute", "dns"]
  env_order                  = ["dev", "staging", "prod"]
  gated_envs                 = ["staging", "prod"]

  regions = {
    us-west-1 = {
      vpc_id     = "vpc-..."
      subnet_ids = ["subnet-a", "subnet-b"]
      root_folder = "stacks"
    }
  }
}

env_order  = ["dev", "staging", "prod"]
gated_envs = ["staging", "prod"]

orchestration_targets = [
  {
    environment = "dev"
    account_id  = "111111111111"
    region      = "us-west-1"
    root_folder = "stacks/dev"
  },
  {
    environment = "staging"
    account_id  = "222222222222"
    region      = "us-west-1"
    root_folder = "stacks/staging"
  }
]

In this example, staging is gated because its environment label appears in gated_envs—not because it uses account 222222222222. Each execution folder is resolved beneath the registered target root.

One place to review. Runners where the work lives.

Argus Deploy installs one central dashboard and orchestrator in your chosen primary AWS account. It dispatches short-lived workers into the customer accounts and Regions you register. Your GitHub repository supplies the code and the event that starts the run.

The dashboard is the review surface; the orchestrator runs the workflow. Approval applies only to the saved plan reviewers saw, and the later worker executes that plan without making a replacement. Normal runs do not require a _fromTheCode-hosted control plane.

From the code to exact apply.

One small GitHub trigger starts the process. Everything that reads credentials, plans infrastructure, or changes AWS runs inside the customer boundary.

Your infrastructure never becomes our infrastructure.

Approval binds to evidence, not intention.

Why customer-resident runners can cost less.

Argus Deploy does not charge per workflow or per run. Customers pay the fixed Argus Deploy subscription plus their own short-lived AWS compute and storage costs.

Least privilege starts with location.

Argus Deploy starts with the assumption that infrastructure credentials should not cross a vendor boundary.

Offline validation. No runtime phone-home.

The customer stores a signed license token in its own Secrets Manager. Each new central orchestrator verifies it locally before dispatching work. The dashboard never reads the secret.