AWS ECS Fargate Flagsmith Feature Flagging Application Deployment

Context & Pain Points

Flagsmith serves feature flags, which means it sits in the request path of every application that reads one. That puts two demands on the platform at once. It has to answer quickly from wherever the caller is, and it has to keep running while a node, an availability zone or a deploy goes wrong. The previous shape of the environment was EC2 instances someone patched, sized and replaced by hand, so autoscaling reacted late and routine maintenance turned into planned downtime. Security review added its own constraints: no application task on a public subnet, no database credential sitting in a task definition, and an audit trail for anything that reads a secret.

What We Had To Solve

• Letting tasks reach AWS services without a public path. Fargate tasks in private subnets still need ECR, Systems Manager, CloudWatch Logs and KMS, and routing that through the internet gateway would have defeated the point of keeping them off public subnets.
• Rolling deployments without dropping traffic. Target group registration, health check thresholds and connection draining all have to agree with the application's real startup time, or the load balancer starts sending requests to a task that is not ready yet.
• Keeping secrets out of task definitions. Database passwords and API keys had to reach a container at startup without appearing in the definition, in an environment variable dump, or in a CloudWatch log line.
• Proving the multi-AZ story rather than asserting it. A design that only survives a zone failure on paper is worth very little to a service that other applications depend on.

How We Built It

• Placed every application task in private subnets and reached AWS services over VPC endpoints, so ECR pulls, Systems Manager reads and log delivery stay inside the VPC and the NAT gateway carries only genuine outbound traffic.
• Registered the Fargate services against Application Load Balancer target groups with health checks tuned to the application's actual startup, so a rolling deploy brings new tasks into rotation only after they answer, and drains the old ones before stopping them.
• Injected configuration at task startup from AWS Systems Manager Parameter Store using KMS-encrypted SecureString parameters, with the task execution role scoped to only the parameter paths that task needs. No engineer holds the values and every read is attributable.
• Mirrored the full subnet stack in both availability zones and ran RDS Multi-AZ with synchronous replication to the standby, so losing a zone costs a failover rather than an outage. Terraform and Terragrunt keep the two zones defined by the same code rather than by two hand-written copies.
• Wired CloudWatch alarms on task health, target group errors and database metrics through SNS to PagerDuty, and shipped images from Quay.io, so a failing deploy pages someone instead of waiting for a user to report it.

Outcomes That Mattered