How to Build an Auto-Expiring Preview Environment Pipeline Using Docker Compose and AWS EC2

Testing new features before deploying them to production is essential for modern web development. However, maintaining separate testing environments for every feature branch can increase infrastructure costs and create unnecessary management work.

An auto-expiring preview environment pipeline using Docker Compose and AWS EC2 offers a practical solution. It automatically creates temporary environments for testing new changes and removes them after a predefined period.

In this guide, we’ll explore how to build a simple, cost-conscious preview environment pipeline using Docker Compose, AWS EC2, and automated cleanup.

What Is an Auto-Expiring Preview Environment?

A preview environment is a temporary version of an application where developers, testers, and clients can review changes before they reach production.

For example, when a developer creates a new feature branch, the pipeline can deploy that version to a temporary URL. Once testing is complete—or the environment reaches its expiration time—the system automatically removes it.

This approach is useful for development teams working on websites, web applications, APIs, and client projects.

Why Use Docker Compose and AWS EC2?

Docker Compose simplifies running applications and their dependencies in containers, while AWS EC2 provides the virtual server needed to host them.

Together, they offer a flexible way to create isolated preview environments without requiring a complex Kubernetes setup.

Key benefits include:

• Lower infrastructure overhead: Run multiple temporary environments on a shared EC2 instance.
• Faster testing: Let clients and QA teams review changes before production deployment.
• Better isolation: Use separate containers and configurations for individual previews.
• Automated cleanup: Remove expired environments to reduce unnecessary resource usage.
• Simpler management: Use familiar Docker commands and automation scripts.

How the Preview Environment Pipeline Works

A typical workflow looks like this:

1. A developer pushes code to a feature branch.
2. A CI/CD pipeline builds the application’s Docker image.
3. The deployment process creates a dedicated Docker Compose environment.
4. A unique preview URL becomes available for testing.
5. The environment receives an expiration timestamp.
6. A scheduled cleanup job removes expired containers, networks, and related resources.

For example, a preview deployment might be available at preview-feature-123.example.com for 24 hours before automatic removal.

Step 1: Prepare Your AWS EC2 Instance

Create an EC2 instance with a supported Linux operating system, such as Ubuntu. Install Docker Engine and the Docker Compose plugin.

Configure the security group to allow only the ports required for your application, HTTPS traffic, and authorized administration. Avoid exposing application containers directly to the public internet when a reverse proxy can handle incoming traffic.

For production-like deployments, use an HTTPS-enabled reverse proxy such as NGINX or Traefik to route requests to individual preview environments.

Step 2: Create a Docker Compose Configuration

Create a compose.yaml file that defines your application and its dependencies.

For example:

services:
  app:
    image: ${APP_IMAGE}
    restart: unless-stopped
    environment:
      NODE_ENV: development
    networks:
      - preview

networks:
  preview:
    driver: bridge

This configuration defines a basic application service. The pipeline can supply a different image and project name for each preview deployment.

Use a unique Compose project name for every environment to prevent containers and networks from conflicting with one another.

Step 3: Automate Preview Deployments

When a feature branch is pushed, your CI/CD workflow should build the Docker image, publish it to a container registry, and connect to the EC2 deployment process.

The deployment script can launch an isolated environment using a command such as:

docker compose \
  -p "preview-feature-123" \
  --env-file preview.env \
  up -d

Here, the project name identifies the preview environment, while the environment file supplies its image and configuration.

Your pipeline should also register the environment’s creation time, expiration time, branch name, and associated resources in a small metadata file or database.

Important: Validate branch names before using them in shell commands, and never expose cloud credentials or sensitive environment variables in public preview deployments.

Step 4: Assign an Expiration Time

Each preview environment needs a clear lifetime. For example, you might allow environments to remain active for 24 hours after creation.

Store an expiration timestamp when deploying the environment. A scheduled cleanup process can periodically check which previews have expired.

A metadata record might contain:

{
  "environment": "preview-feature-123",
  "created_at": "2026-10-21T10:00:00Z",
  "expires_at": "2026-10-22T10:00:00Z"
}

The timestamps are illustrative. Your pipeline should generate them automatically and use a consistent timezone, preferably UTC.

Step 5: Automatically Remove Expired Environments

On the EC2 instance, configure a scheduled job using a systemd timer or cron to run a cleanup script at regular intervals.

The script should:

• Find environments whose expiration times have passed.
• Verify that each environment is managed by the preview pipeline.
• Stop and remove its containers and dedicated networks.
• Delete temporary volumes and files when safe to do so.
• Remove associated routing or DNS records if they were created dynamically.
• Record the cleanup result for troubleshooting.

Use explicit resource labels or a trusted environment registry to identify preview resources. Do not indiscriminately remove all stopped containers or unused Docker resources, because they may belong to other applications.

Step 6: Connect the Pipeline to CI/CD

You can integrate the workflow with GitHub Actions or another CI/CD platform.

A practical pipeline should automate these tasks:

1. Build and test the application.
2. Publish a uniquely tagged Docker image.
3. Deploy the preview environment to EC2.
4. Configure its routing and HTTPS access.
5. Record its expiration time.
6. Trigger cleanup when the pull request closes or the environment expires.

Removing an environment when a pull request closes is a useful additional safeguard, while scheduled expiration provides a fallback if an event is missed.

Best Practices for Secure and Reliable Preview Environments

Before using this approach for client projects, follow a few important practices:

• Protect preview URLs: Require authentication for private projects.
• Separate test data: Avoid copying real patient, customer, or other sensitive production data into previews.
• Limit AWS permissions: Give deployment automation only the access it needs.
• Set resource limits: Control CPU, memory, disk usage, and the number of active previews.
• Monitor expiration jobs: Log failures and alert the team when cleanup does not complete.
• Manage shared services carefully: Do not delete shared databases, networks, or storage when removing an individual preview.
• Review AWS costs: An expiring container environment does not automatically terminate the EC2 instance itself.

For stronger isolation, use separate instances or other dedicated infrastructure for previews that handle untrusted code.

Conclusion

Building an auto-expiring preview environment pipeline with Docker Compose and AWS EC2 can make application testing faster, more consistent, and easier to manage. By combining containerized deployments, unique environment names, automated expiration tracking, and scheduled cleanup, development teams can give every feature branch a temporary testing environment without maintaining it indefinitely.

Start with one application and a simple expiration policy, then add CI/CD automation, secure preview URLs, monitoring, and resource controls as your requirements grow.

For businesses building modern web applications, this approach can improve development workflows while helping prevent unnecessary infrastructure usage.