Zero-downtime
What happens during a deploy
A deploy never mutates a running container. Instead, a new copy of your app is started alongside the old one:
- The new container image is pulled and started as a new task.
- Tapitalee waits for it to pass its health checks, so it is only considered ready once it can actually serve requests.
- Incoming traffic is switched over to the new copy.
- The old copy is drained and stopped.
The interesting part is step 3. Between “the new copy is ready” and “all clients are talking to the new copy” there is a window where traffic may still be heading towards the copy that is about to disappear. How large that window is depends entirely on how traffic finds your app.
Standard deploys: very close to zero downtime
By default, traffic reaches your default process by DNS. When the new copy becomes healthy, the DNS record is updated to point at it.
DNS changeover is not instant. Records take time to propagate, and clients, resolvers and browsers cache them for their own periods — sometimes ignoring the TTL entirely. That caching is on the client side and out of our control, so a standard deploy usually produces a small blip rather than being perfectly seamless.
In practice this is fine for:
- personal and hobby sites
- private or internal apps
- specialist API servers, where clients retry
If a few seconds of failed or slow requests during a deploy is acceptable, standard deploys need no extra configuration.
Achieving true zero downtime
To remove the blip entirely, put something long-lived in front of your app so that traffic is switched at the connection level instead of by DNS. Choose one of the following.
SecureProxy add-on (simplest)
The SecureProxy add-on is the simplest option and the one we recommend for most production apps. It provides a managed Traefik load balancer with automated HTTPS certificates, running as its own independent service. Because it is not restarted by your deploys, it can move traffic from the old copy to the new one immediately, with no DNS changeover involved.
Cloudflare Tunnel add-on
If your domain is already configured and protected by Cloudflare, the Cloudflare add-on can serve traffic over a Cloudflare Tunnel. Cloudflare holds the public entry point and connects through to your app, so the switch to the new copy happens behind a stable public endpoint.
AWS Application Load Balancer
Tapitalee can configure an ALB with target groups for your app, so registration and draining of the old and new copies is handled for you. With this option you must supply and configure your own Domain and HTTPS certificates.
Large web apps: use a CDN
Even with a zero-downtime proxy, there is a second class of interruption that is worth planning for.
While a deploy is in progress, a page may be served by one copy of your app while referencing assets — JavaScript, CSS, images — belonging to the other. Users whose browsers have already loaded and cached the old assets can end up requesting files that the new copy no longer has, breaking the page until they reload.
A CDN solves this by allowing the old and new asset sets to be served simultaneously, so requests for either version continue to succeed throughout the deploy. The Tapitalee CloudFront add-on is the straightforward way to put one in front of your assets.
For Rails apps, add a rake assets:sync pre-deploy step using the asset_sync gem, so compiled assets are uploaded to your asset store and served via the CDN rather than only from the container being replaced.