Zero-downtime deploys on Scalingo with Preboot and Postgres connection budgeting

Your Scalingo deploy finishes cleanly, the build succeeds, and then users hit 502s for the first 20-40 seconds while the new containers warm up. That is the classic slow-start problem on a container PaaS: the release is marked ready before the app can actually serve traffic, and if the app also opens database connections on boot, the first requests compete with connection pool initialization.

The practical takeaway is to pair Scalingo's Preboot deployment mode with explicit connection budgeting for managed add-ons. Preboot starts the new release alongside the current one, waits for health checks, and only then switches traffic. With a Postgres add-on provisioned as a first-class resource, connection details are injected via environment variables, which makes it possible to size pools per container and avoid exhausting the database during the overlap window.

Why slow starts bite on Scalingo

Scalingo runs apps as containerized processes built from buildpacks or custom Docker images. Each app has per-app environment variables and config vars for configuration. A new release creates new containers with the new image, and without Preboot traffic is cut over as soon as the containers report up.

For apps that do runtime initialization — loading models, running a quick migration check, warming a cache, or establishing a connection pool to a managed Postgres or Redis add-on — the container can be "up" but not ready. The result is errors during the cutover and, with horizontal scaling, a burst of new connections to the add-on at the same time.

Preboot and data service isolation

Preboot is a supported deployment mode that starts new containers before cutting traffic. The platform keeps the old containers serving while the new set boots, runs health checks, and only switches routing once the new set is considered healthy. This reduces downtime for apps with slow startup.

Managed add-ons such as Postgres and Redis are offered as first-class resources with provisioning through the platform, automatic backups, and connection details exposed via environment variables. Because the add-on lives outside the app containers and is reached over the platform network, the engineering decision becomes about isolation and limits rather than host access.

Horizontal scaling is achieved by increasing container count, vertical scaling by selecting memory and CPU profiles. During a Preboot release the container count is temporarily doubled, which matters for any shared limit, most visibly the Postgres max connections.

Worked example: Node.js app with Postgres pool sizing

Consider a Node.js app using a Postgres add-on. The add-on connection string is provided as an environment variable, typically DATABASE_URL — confirm the exact variable name in your app's environment settings. The app uses a connection pool.

A conservative sizing rule is to keep total potential connections below the add-on limit. With Preboot enabled, the worst case is old containers plus new containers simultaneously holding pools.

// example pool configuration, not tested
const { Pool } = require('pg');
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10, // per container
  idleTimeoutMillis: 30000
});

With 2 containers running and Preboot enabled, the peak is 2 old + 2 new containers. At max 10 per container that is 40 potential connections. If the Postgres add-on limit is lower, reduce per-container max or container count.

Health check configuration directly affects Preboot effectiveness. The app should expose a readiness endpoint that returns success only after the pool has at least one successful connection and any required warm-up is complete. Slow initialization can still cause errors if warm-up is insufficient.

Trade-offs and limits

Preboot trades brief resource doubling for smoother releases. The overlap increases memory and CPU usage for the duration of the boot and health check window, and it increases connection demand on managed add-ons. Feature availability and limits for Preboot, autoscaling and add-ons are version and plan sensitive and may differ across regions and account tiers, so verify the options shown for your app before relying on them.

Managed add-on backup retention and point-in-time recovery capabilities vary by service and plan, so assumptions about recovery windows should be validated. Pricing and resource quotas for containers and add-ons change over time, so cost-related engineering decisions require current confirmation.

How to check it in practice

• Check the app settings in the Scalingo dashboard for deployment options and whether Preboot is enabled for a given app.
• Inspect environment variables for add-on connection strings to confirm provisioning and network reachability from the app containers.
• Review container count and resource profile settings in the dashboard and observe deployment logs for new container start and traffic switch events.
• Test scaling behavior in a non-production app by adjusting container count and monitoring response times and logs to validate warm-up assumptions.

Immutable releases and rollback support are provided by the unified control plane for logs, metrics and deployments. Keeping releases immutable makes it safe to compare old and new container behavior during the Preboot window.