Jenkins CI/CD: Blue‑Green Docker Deployments to AWS EC2 with Nginx Reverse Proxy
Practical Jenkins CI/CD pipeline for Dockerized Python apps that automates builds, tests, and zero‑downtime blue/green deployments to AWS EC2 with Nginx.
The Jenkins CI/CD pipeline described here demonstrates a complete, production‑style flow that takes a simple Python web app from source control through automated testing, container build, registry push, and a zero‑downtime blue/green deployment to an AWS EC2 host. Using Jenkins as the orchestrator, Docker for packaging, Docker Hub for image distribution, and an Nginx reverse proxy to switch traffic between two application slots, this approach mirrors patterns used by teams that need predictable releases without relying on cloud‑native deployment services. The result is a repeatable, auditable pipeline that enforces test execution, versioned images, and safe cutovers on a single EC2 instance.
What this Jenkins CI/CD pipeline delivers and why it matters
This pipeline automates the end‑to‑end lifecycle for a small Flask application: automatic builds when developers push code, unit tests via pytest, creation of a versioned Docker image, pushing that image to a container registry, and running a blue/green deployment on EC2. The combination matters because it reduces manual steps, shrinks time to delivery, and minimizes user impact during releases by using an Nginx proxy to flip traffic between two containers. For teams without managed orchestration (ECS, EKS), this pattern provides a pragmatic way to deliver continuous deployment with controlled risk.
Application architecture and containerization strategy
The example application is a lightweight Flask service exposing a health endpoint and a root route that reports a message, host, and APP_VERSION environment variable. For runtime, the image uses a slim Python base and serves the Flask app with Gunicorn. This separation — application code and a minimal WSGI server — is typical for containerized Python services and keeps the image small, reproducible, and suitable for multi‑worker production use.
Building the image follows a simple Dockerfile: install dependencies from requirements.txt, copy the application code into /app, expose the service port, and run Gunicorn with a small number of workers. Tagging images with a build identifier (for example build-
How blue/green works with Nginx and Docker Compose
The deployment model uses two application slots on the EC2 host: blue (host port 8081) and green (host port 8082). An Nginx container listens on port 80 and proxies requests to whichever slot is currently active by changing the proxy_pass target in its configuration. When Jenkins triggers a deployment, the orchestrating script pulls the new image, brings up both containers via Docker Compose, detects the currently active slot in the Nginx config, and directs the new image to the inactive slot. After a health‑check loop verifies the new container, the script edits the Nginx configuration in place and reloads Nginx to perform an instantaneous cutover.
This pattern gives several operational advantages: it isolates new versions during validation, supports immediate rollback by flipping the proxy back, and avoids complex orchestration primitives while still achieving zero‑downtime releases.
Bootstrapping EC2 for container workloads
To host the pipeline target, the EC2 instance is prepared with a bootstrap script that installs Docker and Docker Compose and configures a user in the docker group. The script handles repository keys and package sources for a reliable Docker installation on an Ubuntu AMI. Once the instance has Docker, the runtime pieces (Nginx image, app containers, and the deployment script) can be managed entirely with Docker Compose and standard container tooling, simplifying operations and making the host easy to replace or replicate.
Jenkins pipeline stages and secure credential handling
The Jenkinsfile breaks the end‑to‑end flow into clear stages: checkout, test, build, push, and deploy. After checking out the main branch, Jenkins runs unit tests in a virtual environment using pytest. On success, the pipeline builds a tagged Docker image and authenticates to Docker Hub using credentials stored in Jenkins’ credential store. The image is pushed to the registry under a predictable tag derived from the Jenkins build number.
For the deploy stage, Jenkins uses a stored SSH private key (uploaded as a secret file credential) to securely copy the Docker Compose, Nginx configuration, and deployment script to the EC2 instance, and then executes the blue/green orchestrator remotely. Post steps ensure cleanup (for example docker logout and removal of temporary files) so secrets are not left on the build node.
This split of responsibilities — tests before packaging, immutable images with explicit tags, and secure file transfer for deployment — enforces better release hygiene and keeps secrets out of logs and repositories.
Health checks, rollout verification, and safe cutover
The deploy script contains a simple but effective health‑check loop that polls the candidate slot’s /health endpoint several times with short delays. Only after the health check succeeds does the script swap Nginx’s upstream and reload the proxy. This ensures that traffic is routed to a healthy instance and reduces the chance of exposing failures to users. The deployment process also writes logs (for example the active port) so operators can audit which slot is live and what APP_VERSION is currently serving requests.
Because the strategy runs both containers concurrently during deployment, it supports immediate rollback: if a post‑cutover problem is detected, switching the proxy_pass back to the previous slot returns users to the prior stable version with minimal latency.
Networking, security, and operational hardening
A secure, minimal network configuration is important. The EC2 security group needs SSH (22) for management, HTTP (80) for the public site, and the internal ports used by the two app slots (8081 and 8082) if direct access is required for debugging. For hardened deployments, consider restricting access to ports 8081/8082 to localhost or the VPC only, and ensure Nginx is the only service exposed to the public internet.
On the credential side, SSH private keys are stored in Jenkins credentials as secret files, and Docker Hub credentials use Jenkins’ username/password type bindings so the pipeline can log in without exposing secrets in the build logs. The deployment script runs as a privileged user for certain operations (mv, chmod, docker pull), so minimize the surface area by using least privilege and by auditing scripts that are transferred and executed remotely. Adding automated scanning for images, signing images, or integrating with a secrets manager would further strengthen the chain of trust.
Developer workflow and team implications
For developers, this pattern provides clear guardrails: commits to main trigger a deterministic process that runs tests and builds a container. Because images are tagged with build numbers, developers and QA can pull a specific artifact for debugging or reproduce a production deployment locally via docker-compose. Teams benefit from the visibility Jenkins provides through build logs and artifacts, while operations teams retain control over the EC2 environment and can inspect the Nginx configuration and running containers directly.
This flow works well for small teams, startups, or projects where running a full managed orchestration layer is not warranted. It also serves as an instructional reference for engineering teams learning about continuous deployment, containerization, and release practices before moving to more complex platforms.
Integration points with other tools and ecosystems
Although this example uses Jenkins + Docker + Docker Hub + AWS EC2 + Nginx, the architecture is modular. The image registry could be an ECR repository or another private registry. CI orchestrators like GitHub Actions, GitLab CI, or CircleCI could replace Jenkins with modest changes to the credential passing and remote execution steps. For observability, teams can add Prometheus exporters or application logging to a centralized log platform. For security, adding container scanning tools and a vulnerability scanner into the build stage can catch issues earlier.
In larger organizations, this pipeline can plug into broader developer tooling — artifact repositories, release management dashboards, incident management systems, and automation platforms that coordinate deployments across multiple environments. The deployment script could be adapted to support feature flags or integrated with CD tooling to provide richer rollout controls.
Costs, scaling considerations, and when this pattern is appropriate
Running this pipeline on a single EC2 instance keeps costs predictable and minimal but imposes resource constraints. For modest traffic, a t2.micro (or its modern equivalent) is sufficient for a demo or low‑traffic production service. As load increases, consider scaling out to multiple EC2 instances behind a load balancer or migrating container orchestration to ECS, EKS, or a managed Kubernetes service to gain autoscaling, service discovery, and richer scheduling.
For teams that need the simplicity of self‑managed infrastructure and want explicit control over each deployment step, the blue/green approach on EC2 is an appropriate choice. If you anticipate rapid scaling, multi‑region deployments, or heavy automation requirements, evaluate cloud‑native deployment services or orchestration platforms to reduce operational complexity.
Operational monitoring, observability, and incident response
A robust deployment process should be paired with monitoring. At minimum, instrument health endpoints (as shown), collect container logs, and monitor Nginx metrics. For production systems, integrate with an APM tool or a log aggregation platform and configure alerting on key signals (error rate, latency spikes, container restarts). Documenting rollback procedures — including commands to flip Nginx back to the prior slot — and incorporating them into runbooks reduces mean time to recovery. The pipeline can be extended to automatically notify on-call teams via chat integrations when a deployment succeeds or fails.
How to adapt this example for teams and products
Adapting the pattern for your environment may involve replacing Docker Hub with a private registry, changing the build agent (Linux vs Windows), or altering the testing step to include integration or contract tests. You can parameterize the Jenkins job to deploy to staging or production by passing different environment variables or using Jenkins credentials scoped to environments. For more complex applications, add database migrations as an explicit stage with safety checks and feature toggles to decouple schema changes from application rollouts. Useful internal link phrases for teams: containerization guides, deployment strategies, pipeline security, and monitoring best practices.
Broader implications for software delivery and developer productivity
This project illustrates the tradeoffs between full platform automation and simple, controllable deployment models. Using Jenkins as the central CI/CD engine provides transparency and extensibility but requires maintenance of the Jenkins instance and proper credential hygiene. The blue/green approach reduces blast radius and aligns well with continuous delivery goals by enabling predictable, low‑risk releases. For developer productivity, the biggest gains come from reliable tests, immutable artifacts, and quick feedback loops — all enforced by this pipeline.
Adopting such a pattern encourages teams to think in terms of artifacts and environment parity rather than ad‑hoc releases, which in turn supports better observability, repeatable rollbacks, and clearer audit trails. That discipline is increasingly important as organizations adopt microservices, where small, frequent, and safe deployments are the norm.
The pipeline also surfaces common operational responsibilities — hardening images, rotating credentials, and defining rollback playbooks — that must be owned by engineering or platform teams. As teams scale, these responsibilities often motivate a move toward managed CI/CD platforms or container orchestration to offload boilerplate maintenance.
Looking ahead, organizations that combine this kind of deployment pipeline with feature flagging, service meshes, and automated canary analysis can further reduce risk and accelerate experimentation. Integrations with developer tools, security scanners, and automated observability pipelines will make each deployment a richer source of telemetry and governance data.
As cloud platforms evolve and offer richer managed services, this pattern remains a valuable learning step and a practical production choice for many teams. By treating pipeline artifacts as first‑class citizens, keeping deployment scripts auditable, and enforcing automated testing and health checks, engineering organizations can safely deliver changes faster while keeping operational control.
The next phase for this pipeline could include automating image signing, integrating vulnerability scanning into the build stage, adding canary traffic percentages via Nginx or a load balancer, and connecting deployment events to monitoring dashboards and incident management systems to close the loop between releases and production visibility.
