Database credentials and connections

Read credentials on Overview, prefer internal URLs inside the Environment, and wire apps through Reference variables on App or Docker Services.

Written By Zoro

Last updated 3 days ago

This page explains where connection details live for database Services, when internal vs public values apply, and how App and Docker Services should consume them.

Where credentials appear

After at least one successful Deploy on the database Service, open Overview:

  • Internal credentials list the connection URL (when the engine uses one) and/or separate host, port, username, password, and database name. These target the private network inside your Environment’s compute. Use them for workloads running in the same Environment on dFlow.
  • Public credentials appear only after you click Expose. They include a public host, port, and often a public URL, depending on engine. Use them when something outside that Environment must connect (for example a CI runner, your laptop, or a partner system).

Unexpose before Stop if the database was exposed; the dashboard enforces this.

Prefer internal connections for apps on dFlow

For App and Docker Services in the same Environment as the database, use internal host/URL values, not the public endpoint. Traffic stays on the internal network and avoids exposing the database to the internet.

Reference variables (recommended)

Copy-pasting passwords into static env fields is error-prone. On an App or Docker Service:

  1. Open the Variables tab.
  2. Click the { } Reference variables control next to a value field.
  3. Choose your database Service and the field you need (for example internal URI).

Token names use your database service name and an engine-specific prefix (POSTGRES, MYSQL, MONGO, REDIS, MARIADB, CLICKHOUSE, and similar). Each engine guide documents the exact suffixes (_URI, _HOST, _PUBLIC_URI, and so on).

Public reference options stay disabled until the database is deployed and exposed.

Full detail: Service settings under Services in the sidebar.

Databases hosted outside dFlow

If the database runs on another provider (managed RDS, serverless SQL, and similar), dFlow does not populate Internal credentials on a dFlow database Service. Set connection strings on your App or Docker Service manually or via your secrets workflow. See External database notes.

Engine-specific quirks

  • MongoDB and ClickHouse may use more than one public port when Expose is on; Overview still surfaces what most clients need first. See MongoDB and ClickHouse.
  • MariaDB internal URLs may show a mysql:// style string; that is expected. See MariaDB.

Related