Scalingo private PostgreSQL: minimal single-region architecture note

Problem and takeaway

You need a web app on Scalingo that can read and write PostgreSQL without exposing the database to the public internet. The smallest safe pattern is a single Scalingo region with one app container group and one managed PostgreSQL add-on connected over the platform private network, with TLS enforced in the app and secrets injected via environment variables. That gives network isolation without managing your own virtual private cloud.

Requirements

Database access must stay inside the platform. The add-on must be in the same Scalingo region as the app so private DNS resolution works. Application configuration must enforce SSL/TLS for data in transit even on a private network. Secrets must not be stored in code; use Scalingo environment variables. Connection pooling, a cache of reusable database connections, must be sized to app concurrency to avoid exhausting the managed instance.

Assumption: private networking for the chosen add-on is available in the target region. Behavior is region and add-on version sensitive and should be verified in the region you deploy to.

Smallest suitable design

App tier: one Scalingo app with a container group running the web process. Healthcheck endpoint exposed on HTTP for the platform router.

Data tier: one managed PostgreSQL add-on provisioned in the same region. Connect via the private host name provided by Scalingo, not the public endpoint.

Configuration:

# Provided by Scalingo on add-on creation
DATABASE_URL=postgres://user:password@private-host:5432/dbname?sslmode=require
# Or individual vars
DB_HOST=private-host
DB_PORT=5432
DB_NAME=dbname
DB_USER=user
DB_PASSWORD=...

Set sslmode=require or verify-full in the client library. Use a connection pooler in the app sized to the number of web containers times workers, with a max below the add-on connection limit.

Deployment notes: run the app and add-on in the same Scalingo region, for example Paris. Do not open a public IP for the add-on. Inject credentials only via Scalingo environment variables.

Trust and data boundaries

Network boundary: platform-managed private network between app containers and the add-on. The platform controls isolation; you do not manage routes or security groups.

Runtime trust: the app container is an untrusted runtime. It must use a least-privilege database user and validate all input. Private networking does not prevent application-level data leakage.

Data at rest: managed by Scalingo for the add-on. You do not control disk encryption keys.

Data in transit: encrypted with TLS, Transport Layer Security, between app and add-on. Enforce TLS in the client even inside the private network.

Operational checks

App health: platform healthcheck endpoint returns 2xx under normal load.

DB connectivity: from inside the app container test resolution and TLS handshake to the private host. Run with Scalingo CLI as the app owner.

scalingo run --app <app-name> -- psql "$DATABASE_URL" -c "SELECT 1;"

Expected check: command succeeds with TLS, and the connection does not use a public IP. Risk: running commands requires app deploy permission and briefly consumes a container.

Metrics to watch: DB connection latency and error rate from app logs, add-on CPU and I/O saturation from Scalingo dashboard, TLS certificate validation failures on reconnect.

Backups: verify existence and age of managed backups in the add-on console. Managed backups are operator controlled; restore time depends on add-on size and region load and is not instantaneous.

Failure modes

Region outage: both app and DB are in the same region, so a regional failure causes total unavailability.

Add-on failover: managed PostgreSQL failover, an automatic switch to a standby instance, can cause brief connection loss. Connection pools must support reconnect with backoff.

Network partition: platform network partition between app and add-on results in connection errors. Healthchecks should fail fast and the router should stop sending traffic.

Secret rotation: rotating DB_PASSWORD without pool reconnect causes errors. Test rotation in staging and ensure the client pool discards stale connections.

Verification steps

• Connectivity test from inside the app container to the private DB host and confirm TLS handshake succeeds and no public IP is used.
• Inspect app environment for private DB host and port values and confirm they resolve only within the platform network, not from an external client.
• Periodically test restore from a managed backup to a staging add-on and measure time to recover and application reconnect behavior.
• Simulate credential rotation and observe connection pool reconnect and error handling without manual app restart.

When to change the design

Change triggers: need for multi-region availability, read scaling beyond a single primary, compliance requiring customer-managed encryption keys or data residency guarantees, or latency requirements that force app and DB into different regions.

Limitations: private networking availability is region sensitive. Private networking does not replace application-level access control. Restore objectives are not instantaneous and depend on add-on size and region load.