Database credentials and connections

Internal vs public credentials, how reference variables resolve, security practices, and when to use Expose.

Written By Charan

Last updated 3 days ago

dFlow generates and displays database credentials for managed database services. You do not type the initial password into the create form; you read it from the service Overview after a successful Deploy. This page explains what each credential means, how apps should consume it, and when public access applies.

For the full product model, start with Databases overview.

Where credentials appear

After Deploy succeeds:

Open Applications → your app → Environment.
Open the database service.
Stay on Overview.

You will see Internal credentials (always, after success). Public credentials appear only after you click Expose and that job completes.

All credential fields on the database service are read-only. You cannot edit the password in the UI; rotation workflows depend on your operational process (for example restore from backup or recreate the service—confirm with your team’s policy).

Internal credentials (use these for apps on dFlow)

Internal hostnames and URLs reach the database from other services in the same environment over the network path dFlow configures. They are the default choice for:

Application servers.
Docker services.
Background workers deployed in that environment.

Why internal is safer: traffic does not need to leave your environment boundary to reach the database, and you avoid exposing database ports on the public internet.

Typical fields:

Field	Role
Connection URL	Single string many drivers accept (`postgres://…`, `mysql://…`, `mongodb://…`, `redis://…`, and so on).
Host	Hostname as seen from sibling services (not your laptop’s `localhost`).
Port	Port the database listens on inside the environment.
Username / Password	Authentication pair created during provisioning.
Database name	Logical database or default DB name where applicable.

Exact labels vary slightly by engine; use your engine guide for nuances (Redis often emphasizes URL/host/port/password; ClickHouse may show analytics-style URLs).

Public credentials (only after Expose)

Expose asks dFlow to open public host/port (and, where shown, a public URL) so clients outside the environment can connect—for example local development tools, CI, or a third-party integration.

Rules of thumb:

Expose only when required; keep databases unexposed by default.
Unexpose when you no longer need external access.
You cannot Stop while exposed without Unexpose first.

Some engines (MongoDB, ClickHouse) may allocate multiple public ports for their protocols. The Overview still gives you the primary connection information; advanced clients may need details from deployment logs or support if you run nonstandard topologies.

Public reference tokens (when enabled in the UI) look like POSTGRES_PUBLIC_URI, MYSQL_PUBLIC_URI, and so on. They stay disabled in the reference-variable menu until the database is deployed and exposed.

Reference variables: exact syntax

On app and Docker services, open Variables and use the { } menu to insert tokens. The platform uses double curly braces, a space after {{, the service name, a dot, the engine type in uppercase, an underscore, and the field name:

{{ service-name.POSTGRES_URI }} {{ service-name.MYSQL_URI }} {{ service-name.MONGO_URI }} {{ service-name.MARIADB_URI }} {{ service-name.REDIS_URI }} {{ service-name.CLICKHOUSE_URI }}

The service name must match the database service name exactly (including hyphens if you used them). The middle part (POSTGRES, MYSQL, …) comes from the database type in the platform, not from what you wish the variable were called.

Common suffixes (private unless noted):

Suffix	Meaning
`_URI`	Full connection URL (internal).
`_NAME`	Database name where applicable.
`_USERNAME`	User.
`_PASSWORD`	Password.
`_HOST`	Internal host.
`_PORT`	Internal port.
`_PUBLIC_HOST`, `_PUBLIC_PORT`, `_PUBLIC_URI`	Available only when exposed.

For engine-specific notes, open the matching guide from Databases overview.

Connecting from your laptop or another network

Internal URLs usually do not work from your laptop: they resolve inside the environment, not on the public internet.

Options:

Expose the database temporarily and connect with public credentials (tighten firewall or IP allowlists at your infrastructure layer if you have them).
Use an SSH tunnel or VPN into the network where the worker runs (common for self-hosted operators).
Run your tool inside dFlow (for example a one-off Docker service or job) so it shares the environment network.

For databases hosted outside dFlow (RDS, PlanetScale, and so on), see External database notes.

Security practices

Treat every credential as secret. Do not commit URLs with passwords to git.
Prefer reference variables over pasting values into variable fields.
Unexpose databases that do not need the open internet.
Limit who in your organisation can Expose or Restore backups (permissions vary by workspace role).
After team members leave, plan credential rotation with your security policy (may require coordinated redeploy or service recreation).

Checklist

[ ] Database Deploy completed successfully.
[ ] App uses internal URL or …_URI reference variable in the same environment.
[ ] Expose is off unless an external client truly needs it.
[ ] App redeployed or restarted after variable changes, if your runtime requires it.