Skip to main content
Looking for Kubernetes? This guide covers ECS (Elastic Container Service) deployment. For Kubernetes/EKS deployment, see the EKS + Terraform guide.

Overview

Deploy Runlayer on AWS ECS (Elastic Container Service) with Fargate using Terraform. This provides a serverless container deployment without managing Kubernetes clusters. Choose between minimal configuration (5 required parameters) or enterprise configuration (full customization). Infrastructure Repository: runlayer/runlayer-infra
This deployment creates AWS resources that incur costs. Typical costs range from $100-400/month depending on configuration.

Quick Start

Step 1: Get the infrastructure code

Configuration Options

Minimal Configuration

Required:
Smart production-ready defaults include:
  • Database: Aurora PostgreSQL 16.6, 2-16 ACUs, private subnets, 7-day backups
  • Security: Public ALB with internet access, private database/cache
  • SSL: Automatic wildcard certificate lookup (e.g., *.staging.runlayer.com); set enable_acm_dns_validation = true to create a new certificate instead
  • Scaling: 2 backend + 2 frontend containers, auto-scale to 10 max
  • Resources: Backend 512 CPU/1024 MB, Frontend 512 CPU/1024 MB
  • Resources: Backend 2048 CPU/4096 MB, Frontend 512 CPU/1024 MB
  • Network: 3-AZ VPC with /16 CIDR, public/private subnets
  • Monitoring: CloudWatch logs for all services

Enterprise Configuration

All minimal options plus 160+ customizable parameters:
Skip Aurora and/or ElastiCache when you operate PostgreSQL and Redis/Valkey yourself. Postgres and Redis can be configured independently.
ECS tasks receive POSTGRES_* env vars and Secrets Manager entries for PLATFORM_DB_PASSWORD and REDIS_URL. Ensure private subnets can reach your endpoints. See also Helm external database configuration.
Use Case:
  • Public access required (e.g., ChatGPT, external integrations)
  • Private network access for internal services (stays within VPC/peering)
  • Single domain name (runlayer.example.com) resolves differently based on network context
How it works:
  • Public DNS → Public ALB (internet traffic)
  • Private DNS → Internal ALB (VPC/peered traffic)
  • ECS services register with both ALBs
  • WAF applies only to public ALB
Security Note: VPC peering connections require peer_owner_id to be specified for all connections. This validation ensures you only accept connections from known and trusted AWS accounts. Connections are automatically accepted after validation.
Enable VPC peering to allow traffic between the Runlayer VPC and other VPCs (for example, a customer’s existing VPC or internal services VPC).
Security Features:
  • Required peer validation - All connections must specify peer_owner_id
  • Automatic acceptance after validation - Validation is the security control
  • Automatic routing - Routes configured only for validated connections
  • Security group integration - Backend allows traffic from validated peer CIDRs
Prerequisites:
  1. The peer VPC must initiate the peering connection first
  2. You need the peering connection ID (pcx-xxxxx)
  3. You need the peer VPC’s CIDR block
  4. You MUST provide the peer AWS account ID for security validation
Use Cases:
  • Connecting to a customer’s existing VPC for internal API access
  • Multi-VPC architectures with centralized services
  • Hybrid cloud setups with on-premises connectivity
VPC peering only works when the module creates the VPC (not with existing_vpc_id).
Automatic CloudWatch alarms created for:
  • ECS Services: CPU utilization (80%), Memory utilization (85%)
  • RDS Database: CPU utilization (80%), Connection count (50), Freeable Memory, Disk Queue Depth, Read/Write IOPS, Free Storage Space
  • Redis Cache: CPU utilization (80%), Memory utilization (85%)
  • Load Balancer: Response time (5s), Unhealthy targets, 5XX error count
  • VPC: Flow logs for network traffic analysis and security monitoring
Enhanced monitoring capabilities include:
  • Configurable alarm thresholds for all RDS metrics
  • 365-day log retention for ECS services and prestart containers
  • VPC Flow Logs with customizable traffic type monitoring
  • ALB 5XX error tracking with configurable thresholds
CloudWatch monitoring - comprehensive monitoring with configurable alarms for all infrastructure components.Advanced RDS monitoring configuration:
By default, Agent Sandbox routes LLM calls through the backend Anthropic proxy. To use OpenAI or an OpenAI-compatible gateway, add a provider in Settings → AI Providers (no Terraform change needed). The Agent model dropdown then shows models from all configured providers.

Prerequisites

1

Install Tools

2

AWS Requirements

  • AWS account with sufficient permissions
  • Domain name you control (for DNS records and SSL)
  • Adequate service quotas (VPC, RDS, ECS)
By default, the module looks up an existing wildcard ACM certificate (e.g., *.staging.runlayer.com). If no wildcard certificate exists, set enable_acm_dns_validation = true to create one automatically with DNS validation.
3

SSL Certificate (Enterprise Only)

Deployment

1. Get Infrastructure Code

2. Configure

3. Deploy

Deployment takes 15-20 minutes. SSL certificate validation may add 5-10 minutes.

4. Automated Database Setup

Database initialization is completely automated: What happens automatically:
  • Database Connection: Prestart container waits for Aurora PostgreSQL to be ready
  • Schema Migration: Runs alembic upgrade head to apply latest database schema
  • Logging: All setup activity logged to CloudWatch under prestart-logs-[environment]
  • Error Handling: Backend won’t start if database setup fails
Secrets are automatically generated:
  • Database password and secret keys are created securely

5. Update Application Secrets (Optional)

6. Verify Deployment

Architecture

Cost Estimation

Costs vary by region and usage. Use AWS Pricing Calculator for precise estimates.

Common Use Cases

Private Enterprise Deployment

High Availability Production

Development Environment

Production with Monitoring

Troubleshooting

Wildcard lookup fails (default behavior):
DNS validation fails (when enable_acm_dns_validation = true):
Solution: Check security groups and target health:
Solution: Optimize resource sizing:
  • Use environment = "development" for testing
  • Reduce database min_capacity and max_capacity
  • Lower service desired_count and CPU/memory
  • Set shorter backup_retention periods
Solution: Check CloudWatch alarm configuration:
Common issues:
  • CloudWatch alarm thresholds too high
  • Alarm actions disabled
  • Missing CloudWatch permissions

ECS vs EKS: Which to Choose?

Next Steps

EKS + Terraform

Deploy on Kubernetes using EKS with Terraform for more advanced scenarios

Helm + Kubernetes

Deploy application using Helm charts (after provisioning EKS infrastructure)