—Delivery · AWS ECS
Deploy through your workflow and your AWS role.
Axiom dispatches a workflow in the selected GitHub repository. GitHub Actions uses OIDC to assume the AWS role configured for the selected environment.
No AWS access key in Axiom
01
Prepare the repository
Add the supported .github/workflows/axiom-deploy-aws-ecs.yml workflow to the repository selected in Axiom. Limit workflow_dispatch inputs and GitHub environment access to the values your team intends to permit.
02
Create the OIDC trust boundary
Create an AWS role whose trust policy accepts the intended GitHub organization, repository, branch or environment. Grant only the ECS and task-definition permissions required by the workflow. Do not use a wildcard repository subject for convenience.
03
Map an Axiom environment
In the desktop app, create or select an environment and configure its AWS region, ECS cluster, ECS service, and role ARN. The selected environment becomes the deployment target; production context is treated as high risk.
04
Validate before production
Run the workflow against a non-production ECS service first. Confirm repository scope, role trust, task-definition capture, steady-state validation, rollback behavior, and the resulting action record before enabling the production target.
Trust questions
Where does deployment run?
Inside the tenant-owned GitHub Actions workflow.
Where are AWS credentials stored?
The released path uses GitHub Actions OIDC and short-lived role credentials.
Can the Agent deploy immediately?
No. Triggering a deployment is a high-risk proposal that requires administrator approval.
What is selected in Axiom?
Repository, branch, environment, region, cluster, service, and role-backed target.
What proves success?
The workflow waits for the ECS service to reach steady state.
What happens on failure?
The workflow restores the task definition captured before deployment.
Still blocked?
Include the failed step and error. Never send a password, token, or cloud secret.