External database notes

Connect apps to third-party databases via Variables and network paths; compare to first-party database Services on dFlow compute.

Written By Charan

Last updated 3 days ago

Managed database services in dFlow provision the engine on your environment’s compute and show credentials on the service Overview. This page covers the opposite case: the database already exists outside that flow—for example Amazon RDS, Google Cloud SQL, Azure Database, PlanetScale, Neon, Supabase, or a server your company operates.

You still use dFlow Applications, environments, and services; you simply point an app or Docker service at the external endpoint with environment variables instead of using {{ my-db.POSTGRES_URI }} from a dFlow database service.

When an external database makes sense

Consider keeping the database outside dFlow when:

  • Your organisation mandates a central DBA or approved cloud database product.

  • You need cross-region replicas, built-in PITR, or compliance features tied to that provider.

  • You are migrating an existing system and cannot move data yet.

Consider a dFlow database service when:

  • You want one place to create, back up (per current product limits), expose, and restart the database next to the app.

  • You want reference variables without maintaining connection strings by hand.

How to connect an app on dFlow to an external database

  1. Collect the provider’s hostname, port, database name, username, and password (or IAM/auth token if applicable).

  2. Open your app or Docker service in the same environment where the app runs.

  3. Open the Variables tab.

  4. Add variables your framework expects, for example:

    • DATABASE_URL — full URL if your ORM supports it.

    • Or separate DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD.

Use static values typed or pasted into the value fields, or your provider’s secret manager integration if you use one outside dFlow. Reference variables only resolve to other dFlow services in the workspace; they do not fetch AWS Secrets Manager or similar automatically.

  1. Redeploy or restart the app so new variables take effect.

Networking and reachability

Your app container must be able to open a TCP connection (or provider-specific protocol) to the database host.

Checklist:

  • Firewall / security groups: allow the outbound app and inbound database rules to match (correct ports, source IPs or VPC peering).

  • Private networking: if the database is only on a private network, your dFlow compute must have a route there (VPN, peering, Tailscale, and so on—depends on your hosting model).

  • TLS: enable SSL mode in your connection string if the provider requires it (often ?sslmode=require for Postgres or the equivalent for MySQL).

If connections timeout, the issue is usually network path, not dFlow variable substitution. See Database troubleshooting.

Using a Docker service as a database client or proxy

Sometimes teams run a small Docker service in dFlow that:

  • Runs migration tools.

  • Hosts a SSH tunnel or proxy container.

  • Connects to an internal corporate database through a bastion.

That pattern is advanced; you maintain the image, env vars, and health of that container. dFlow database Expose docs do not apply to arbitrary Docker images—use the image’s own port and domain settings.

Credentials rotation on external databases

When the provider rotates passwords:

  1. Update the variables on the app (or Docker) service in dFlow.

  2. Redeploy or restart every service that caches the old password.

There is no automatic sync between external providers and dFlow variable fields.

Mixed setups (some services in dFlow, some external)

It is normal to run:

  • Postgres in dFlow for a new microservice, and

  • Legacy MySQL external until migration completes.

Use reference variables only for the dFlow-managed database; use plain env vars for the external one. Document which service uses which in your runbook so operators do not Expose the wrong tier.

Summary

  • External database = you supply host/port/credentials on the app or Docker service Variables tab.

  • Networking must allow your dFlow compute to reach the provider; dFlow cannot fix security-group mistakes.

  • Managed dFlow databases are simpler for greenfield apps on the same environment; external is for policy, legacy, or provider-specific features.

Related