Whenever you deploy, restart, configure, scale, etc. your App, a new set of Containers will be launched to replace the existing ones for each of your App’s Services.

This set of Containers is referred to as a Release. The Containers themselves are referred to as Release Containers, as opposed to the ephemeral containers created by e.g. before_release commands or Ephemeral SSH Sessions.

📘 Each one of your App’s Services gets a new Release when you deploy, etc. In other words, Releases are Scoped to Services, not Apps. This isn’t very important, but it’ll help you better understand how certain Aptible Metadata variables work.


Aptible will adopt a deployment strategy on a Service-by-Service basis.

The exact deployment strategy Aptible chooses for a given Service depends on whether the Service has any Endpoints associated with it:

📘 In any cases, new Containers are always launched after before_release commands have completed.

Services without Endpoints

Services without Endpoints (also known as Background Services) are deployed with zero overlap: the existing Containers are stopped before new Containers are launched.

Services with Endpoints

Services with Endpoints (also known as Foreground Services) are deployed with minimal (for TLS Endpoints and TCP Endpoints) or zero downtime (for HTTP(S) Endpoints): new Containers are launched and start accepting traffic before the existing Containers are shut down.

Specifically, the process is:

  1. Launch new Containers.
  2. Wait for the new Containers to pass Health Checks (only for HTTP(S) Endpoints).
  3. Register the new Containers with the Endpoint’s load balancer. Wait for registration to complete.
  4. Deregister the old Containers from the Endpoint’s load balancer. Wait for deregistration to complete (in-flight requests are given 15 seconds to complete).
  5. Shutdown the old Containers.

Concurrent Releases

❗️ An important implication of zero-downtime deployments is that you’ll have Containers from two different releases accepting traffic at the same time, so make sure you design your apps accordingly!

For example, if you are running database migrations as part of your deploy, you need to design your migrations so that your existing Containers will be able to continue working with the database structure that results from running migrations.

Often, this means you might need to apply complex migrations in multiple steps.