This guide walks through deploying a containerized application (like a Rails, Node, or Go app) from scratch using Opsitron.
Prerequisites
Before deploying a container app, you need:
- A SharedServices account with ECR repository provisioned
- A workload account (e.g., AcmeDev) linked and validated
- DNS configured for the workload account (service discovery zone + certificate)
- A GitHub repository for your application code with a Dockerfile
Step 1: Create the Application
In the Opsitron portal, navigate to your client and create a new Application:
- Name: Your app name (e.g., “web-app”)
- Deployment Type: Container
- Tech Stack: Rails, Node, Go, etc.
Step 2: Provision ECR Repository
Click “Provision ECR” on the application page. This creates a request to add your app’s ECR repository to the SharedServices account. The repository is named {namespace}/{app-slug} (e.g., 123456789012-acme/web-app).
Step 3: Scaffold the Application Repository
Link your GitHub repository and click Scaffold. This:
- Creates a
build.ymlworkflow that builds your Docker image and pushes to ECR - Sets GitHub Actions variables (
ECR_REPOSITORY_URI,AWS_REGION, etc.) - Configures OIDC authentication for AWS access (no stored credentials)
Step 4: Deploy Infrastructure
Create a Module Deploy request targeting your application and dev1 environment. The AI agent will:
- Read the
ecs-webappmodule’s variables and outputs - Generate Terraform files at
apps/{app-slug}/dev1/ - Run
tofu planto validate - Create a pull request
The infrastructure workflow runs plan, shows cost estimate, and applies after approval. This creates:
- ECS cluster and Fargate service
- Application Load Balancer with HTTPS
- Aurora Serverless database (or standard RDS for dev)
- Security groups, IAM roles, CloudWatch log groups
- SSM parameters for deploy workflow discovery
- DNS record pointing to the ALB
Step 5: Push Code and Deploy
Push to your app’s main branch. The build workflow:
- Builds the Docker image
- Pushes to ECR with tag
sha-{short-sha} - Notifies Opsitron
Opsitron auto-deploys to dev1:
- Dispatches the container deploy workflow
- Workflow reads ECS config from SSM parameters
- Registers a new ECS task definition with the updated image
- Updates the ECS service
- Waits for stability
Your app is live. Subsequent pushes auto-deploy to dev.
Step 6: Promote to Staging and Production
Create environments for stage1 and prod1 (each in their own AWS account). Submit Module Deploy requests for each. Once infrastructure is provisioned, deployments promote automatically through the pipeline:
Push to main → Build → Auto-deploy to dev1 → Approve → Deploy to stage1 → Client approves → Deploy to prod1
What Gets Created
| Resource | Purpose |
|---|---|
| ECS Cluster | Container orchestration |
| ECS Service + Task Definition | Your app running on Fargate |
| ALB + Target Group | HTTPS load balancing |
| Aurora Serverless / RDS | PostgreSQL database |
| Security Groups | Network access control |
| IAM Roles | ECS execution and task roles |
| CloudWatch Log Groups | Application and cluster logs |
| SSM Parameters | Deploy workflow configuration |
| Route53 A Record | DNS pointing to ALB |
| ACM Certificate | HTTPS for your domain |