For a regulated fintech client processing real-time payments in Costa Rica, downtime during deployments was not an inconvenience — it was a compliance violation. We built a blue-green deployment pipeline on Amazon ECS with GitHub Actions that reduced release risk to near zero.
The client’s platform handled interbank transfers governed by SUGEF regulations, which mandate continuous availability during business hours and require auditable deployment records for every production change. Before engaging Gianko, their release process was a Friday-evening ritual: an engineer would SSH into the production server, pull the latest Docker image, restart the service, and monitor logs for fifteen minutes. Rollbacks meant reverting the image tag and restarting again — a manual process that took an average of eight minutes, during which the API returned 503 errors. In one quarter, three deployments caused downtime events that triggered regulatory incident reports. The CTO’s brief to us was direct: eliminate deployment risk without slowing the release cadence.
The architecture we designed centers on ECS services running behind an Application Load Balancer with two target groups — blue and green. At any given moment, the ALB routes 100% of traffic to the active target group. A deployment creates a new ECS task definition revision, registers new tasks in the inactive target group, waits for health checks to pass, then shifts traffic at the ALB level. The critical detail is the health check contract: each service exposes a /health endpoint that verifies database connectivity, Redis availability, and the integrity of the encryption keys used for transaction signing. Only when all three checks return 200 for thirty consecutive seconds does the pipeline proceed with the traffic shift. If any check fails, the pipeline halts, the new tasks are drained, and a Slack notification fires with the failure reason and a direct link to the CloudWatch log group.
The GitHub Actions workflow orchestrates the entire process across four jobs. Job one runs the test suite — 312 unit tests and 47 integration tests against a containerized PostgreSQL instance — and blocks the pipeline on any failure. Job two builds the Docker image, tags it with the short SHA and a semantic version, pushes it to ECR, and scans the image with Trivy for critical CVEs. Job three executes the blue-green swap using a custom composite action we wrote that wraps the AWS CLI calls for updating the ECS service, polling task health, and modifying the ALB listener rules. Job four runs a post-deployment smoke test that hits five critical API endpoints from a Lambda function in a separate VPC — simulating an external client — and validates response schemas against an OpenAPI spec. The entire pipeline completes in under seven minutes, and every artifact — test results, image scan report, deployment timestamp, rollback instructions — is persisted as a GitHub Actions artifact linked to the commit SHA for audit compliance.
Since deploying this pipeline nine months ago, the client has shipped 127 production releases with zero downtime events. Mean time to deploy dropped from 45 minutes of manual coordination to 6 minutes and 40 seconds of automated pipeline execution. The rollback mechanism has been triggered twice — both times by a failing health check that caught a misconfigured environment variable before any user traffic reached the new code. The regulatory team now receives an automated deployment report after every release, formatted as a PDF generated by a final pipeline step, which satisfies the SUGEF audit trail requirement without any manual documentation. For the Gianko DevOps practice, this project became the reference architecture we now adapt for every client running containerized workloads on AWS.
