Skip to main content
Learn how to deploy Infisical on Amazon Web Services using Elastic Container Service (ECS) with Fargate. This guide covers setting up Infisical in a production-ready AWS environment using Amazon RDS (PostgreSQL) for the database, Amazon ElastiCache (Redis) for caching, and an Application Load Balancer (ALB) for routing traffic.

Prerequisites

  • An AWS account with permissions to create VPCs, ECS clusters, RDS, ElastiCache, and ALB resources
  • Basic knowledge of AWS networking (VPC, subnets, security groups) and ECS concepts
  • AWS CLI installed and configured (optional, for CLI examples)
  • An Infisical Docker image tag from Docker Hub
Do not use the latest tag in production. Always pin to a specific version to avoid unexpected changes during upgrades.

System Requirements

The following are minimum requirements for running Infisical on AWS ECS: For production deployments with many users or secrets, increase these values accordingly.

Deployment Steps

1

Set up network infrastructure (VPC, subnets, security groups)

Create an AWS Virtual Private Cloud (VPC) network for hosting Infisical:VPC and Subnets:
  • Create a VPC spanning at least two Availability Zones
  • In each AZ, create one public subnet (for the ALB) and one private subnet (for ECS tasks, RDS, and Redis)
  • Configure route tables: public subnets route to an Internet Gateway, private subnets route to a NAT Gateway
NAT Gateway:
  • Deploy a NAT Gateway in a public subnet to allow outbound internet access from private subnets
  • This is required for pulling container images and sending emails
Security Groups: Create the following security groups:
For additional security, consider placing CloudFront in front of the ALB, using AWS WAF for web application firewall protection, or restricting the ALB security group to specific IP ranges if your users access Infisical from known networks.
Verify: After creating the VPC, confirm you have:
  • At least 2 public subnets and 2 private subnets across different AZs
  • A NAT Gateway with an Elastic IP
  • Security groups with the rules described above
2

Provision the database (PostgreSQL) and cache (Redis)

Set up the persistence layers for Infisical:Amazon RDS (PostgreSQL):
  • Create a PostgreSQL 14+ database instance in the private subnets
  • Enable Multi-AZ deployment for high availability
  • Disable public accessibility
  • Enable automated backups with at least 7-day retention
  • Use the RDS security group created earlier
Amazon ElastiCache (Redis):
  • Create a Redis replication group in the private subnets
  • Enable Multi-AZ with automatic failover
  • Enable encryption in-transit and at-rest
  • Use the Redis security group created earlier
Verify: Wait for both services to become available:
Note the connection endpoints:
  • Database URI: postgresql://infisical:<password>@<rds-endpoint>:5432/infisical
  • Redis URI: redis://<elasticache-endpoint>:6379
3

Securely store Infisical secrets and configuration

Generate and store the required secrets using AWS Systems Manager Parameter Store or Secrets Manager:Generate secrets:
Store your ENCRYPTION_KEY securely outside of AWS as well. Without this key, you cannot decrypt your secrets even if you restore the database.
Verify: Confirm secrets are stored:
4

Set up IAM roles for ECS

Create IAM roles with the necessary permissions for ECS tasks:Task Execution Role (for ECS agent operations):Create a file named ecs-task-execution-trust-policy.json:
Create the role and attach policies:
Task Role (for application access to AWS services):Create a file named infisical-task-policy.json:
For production environments, scope down the KMS Resource to specific key ARNs used by SSM Parameter Store in your account instead of using "*". You can find your KMS key ARN in the AWS KMS console or by running aws kms list-keys.
Create the task role:
Enable ECS Exec (for container debugging):Add the following to the task role policy to enable aws ecs execute-command:
Verify: Confirm roles are created:
5

Create the ECS cluster and task definition

Create ECS Cluster:
Create Task Definition:Create a file named infisical-task-definition.json:
Register the task definition:
Verify: Confirm task definition is registered:
6

Create the Application Load Balancer

Create ALB:
Create Target Group:
Create HTTP Listener:
Verify: Check ALB is active:
Note the ALB DNS name for accessing Infisical:
7

Deploy the ECS service

Create the ECS service with the ALB integration:
Verify deployment:
Once tasks are running and healthy, access Infisical via the ALB DNS name:
For production, run at least 2 Infisical tasks spread across different Availability Zones for high availability and zero-downtime deployments.
After completing the above steps, your Infisical instance should be running on AWS. Visit http://<alb-dns-name> to access the Infisical web interface and create your admin account. self-hosted sign up

Additional Configuration

Set up a custom domain with SSL/TLS using AWS Certificate Manager and Route 53:1. Request an SSL Certificate:
2. Validate the certificate by adding the CNAME record to your DNS (Route 53 or external DNS).3. Create HTTPS Listener:
4. Redirect HTTP to HTTPS:
5. Create Route 53 Record:
6. Update SITE_URL in your ECS task definition to use https://infisical.example.com.
Configure AWS SES for sending emails (invitations, password resets, etc.):1. Verify your domain in SES:
2. Create SMTP credentials:
  • Go to AWS SES Console > SMTP Settings > Create SMTP Credentials
  • Note the SMTP username and password
3. Add SMTP environment variables to your ECS task definition:
4. Request production access if you’re in the SES sandbox (limited to verified emails only).
For environments without internet access, configure VPC endpoints to pull container images from ECR:Create VPC Endpoints:
Push Infisical image to ECR:
Update your task definition to use the ECR image URL.
Infisical automatically runs database migrations on startup. For manual migration handling:Check migration status:
Run migrations manually:
Rollback migrations:
Always back up your database before running migrations manually. Take an RDS snapshot before any upgrade.
Use ECS Exec to troubleshoot running containers:Prerequisites:
  • ECS service must have --enable-execute-command flag
  • Task role must have SSM permissions (included in IAM setup above)
  • AWS CLI Session Manager plugin installed locally
Install Session Manager plugin:
Exec into a container:
Common debugging commands:
Database Backups:
  • RDS automated backups are enabled by default (7-day retention recommended)
  • Take manual snapshots before upgrades:
Export to S3 (for cross-region DR):
Encryption Key Backup: Store your ENCRYPTION_KEY in multiple secure locations:
  • AWS Secrets Manager (already done)
  • Offline secure storage (e.g., hardware security module, safe deposit box)
  • Secondary AWS region
Without the ENCRYPTION_KEY, encrypted secrets cannot be recovered even with a database restore.
1. Back up the database:
2. Update the task definition with the new image tag:
3. Update the service:
4. Monitor the deployment:
5. Verify health:
Rollback if needed:
CloudWatch Logs:
  • Logs are automatically sent to /ecs/infisical log group
  • Set retention policy:
CloudWatch Alarms:
Enable Container Insights:
Configure ECS Service Auto Scaling to handle load changes:Register scalable target:
Create scaling policy (target tracking):

Infrastructure as Code

A basic Terraform configuration for deploying Infisical on AWS:
This is a simplified example to get you started. For a complete deployment, you’ll need to add ECS task definitions, services, ALB configuration, and target groups. Consider using community Terraform modules for ECS or adapting this example to your infrastructure standards.
A CloudFormation template for deploying Infisical on AWS:
Deploy the stack:

Troubleshooting

Check task status and stopped reason:
View CloudWatch logs:
Common causes:
  • Secrets not found: Verify SSM parameters exist and task role has permissions
  • Image pull failed: Check ECR permissions or Docker Hub rate limits
  • Insufficient resources: Increase task CPU/memory or check Fargate capacity
  • Network issues: Verify NAT Gateway is working and security groups allow egress
Test connectivity from ECS task:
Check security groups:
  • RDS security group must allow inbound 5432 from ECS tasks security group
  • ECS tasks security group must allow outbound to RDS
Verify connection string:
Check target health:
Verify health check endpoint:
Common causes:
  • Health check path is wrong (should be /api/status)
  • Security group doesn’t allow ALB to reach ECS tasks on port 8080
  • Application is crashing on startup (check logs)
  • Health check timeout is too short (increase to 10 seconds)
Check ALB is accessible:
Verify DNS resolution:
Check ALB security group:
  • Must allow inbound 80/443 from 0.0.0.0/0
Check SITE_URL:
  • Must match the URL you’re accessing (including protocol)
Check SES sending status:
Verify SMTP credentials:
  • Ensure SMTP username/password are correct
  • Check if you’re still in SES sandbox (can only send to verified emails)
Test SMTP connectivity:
Check application logs for email errors:
Check ECS task metrics:
Check RDS metrics:
Solutions:
  • Scale ECS tasks horizontally (increase desired count)
  • Scale RDS vertically (larger instance class)
  • Enable RDS Performance Insights for query analysis
  • Consider connection pooling (PgBouncer)
Verify prerequisites:
Check managed agent status:
Common fixes:
  • Ensure Session Manager plugin is installed locally
  • Verify VPC has route to SSM endpoints (via NAT or VPC endpoint)
  • Redeploy service after enabling execute-command