In dFlow, a database is just another service in your application.

It runs on the same environment as your apps, gets a connection string when it’s ready, and can stay private to your stack, or be opened to the internet only if you choose.

Behind the scenes, dFlow provisions the database on your environment’s compute and fills in connection details for you. You don’t install anything on the server yourself; that happens automatically when you Deploy.

This guide matches the Applications experience: App → Environment → Services.

Add a database (quick steps)

1. Open Applications and pick your app.
2. Open an Environment (this is where your compute runs).
3. Use Add New → Add service (same entry point as apps or Docker services).
4. Choose Database, pick an engine (Postgres, MySQL, and so on), give the service a name, and click Create Service.
5. Open the new database service and click Deploy. Wait until it finishes successfully.

After that, stay on the service’s Overview tab (the default): you’ll see Internal credentials (connection URL and related fields). Public credentials only appear if you use Expose (explained below).

Engines you can pick today

Need a different engine or a custom image? Create a Docker service instead. You configure the image, env vars, and storage yourself.

Create vs Deploy (why two steps?)

Create Service saves your database service in dFlow (name and engine). Nothing is running yet.

Deploy is when dFlow actually provisions the database on your environment’s compute and writes your connection details into the dashboard.

Private vs public access

Internal credentials (recommended for apps)

By default, use Internal credentials on the database Overview. Share them only with other services in the same environment (your app, workers, Docker services). Traffic stays on your internal network and doesn’t need the public internet.

Reference variables (fewer copy-paste mistakes)

For app and Docker services, open the Variables tab (in the URL this is often tab=environment). Next to a value field, use the { } Reference variables menu to insert placeholders like: {{ your-db-name.POSTGRES_URI }}

…using the exact name of your database service and the right prefix for the engine (POSTGRES, MYSQL, MONGO, and so on; each engine guide lists them).

After you Expose a database, you can also reference public host, port, and URL. Those options stay grayed out until the database is deployed and exposed.

Expose and Unexpose (internet access)

Use Expose only when something outside your dFlow environment must connect (for example a CI job, your laptop, or a partner system). dFlow assigns port(s) on the server and routes traffic through dFlow’s database gateway (or the public address shown for your compute, when applicable).

• Most engines use one public port.
• MongoDB and ClickHouse use more than one public port behind the scenes. You still use a single Expose / Unexpose action. On Overview, Public credentials mainly surface the first public port and a matching public URL, enough for typical clients; advanced setups may rely on the full port list from the deployment flow if needed.

Unexpose turns off public access. You must Unexpose before Stop if the database was exposed. The dashboard will remind you.

Before you deploy

The create form can show a resource check (CPU, memory, disk). It’s a sanity check, not a hard block; if you’re tight on resources, plan before adding heavy databases.

Database services don’t use the CPU / memory sliders you see for App and Docker services; those sliders are for application containers.

Where things live in the dashboard

A database service only shows the tabs that apply to databases: Overview, Logs, Deployments, Backups, and Settings. You do not get Variables, Scaling, Domains, Volumes, or Proxy on the database (those are for apps and Docker services). To inject connection values into an app, use that app’s Variables tab and Reference variables, as described above.

Overview shows the service name, a status badge, internal (and optional public) credentials, and the action buttons. Logs streams live lines from the server. Deployments lists each provisioning run with status and full logs. Backups is covered in the Backups and restore guide. Settings may show Switch project (legacy naming) when the service is still tied to an unmigrated legacy Project server binding, plus Delete service in the danger zone. Prefer Applications under Applications in the sidebar and Migrate from legacy Projects to Applications under Migration and Release Notes in the sidebar when you are standardising on the current model.

The same Deploy, Expose / Unexpose, Restart, and Stop buttons appear in the header on Overview, Logs, Deployments, and Settings (the Backups tab has backup controls instead).

What each action does

• Deploy – Starts provisioning on your compute. When a run finishes successfully, connection fields appear on Overview. After at least one successful deployment, the dashboard hides Deploy for database services. There is no Redeploy dialog for databases like there is for apps; treat the first successful deploy as the main provisioning path in the UI today.
• Expose / Unexpose – Shown only after a successful deploy. They queue work on the server to open or close public access. While a job runs, the label may read Exposing or Un-exposing.
• Restart – Queues a restart of the database on the server. You must have at least one deployment first; otherwise the UI asks you to deploy. The button can stay disabled briefly while related updates are applied.
• Stop – Queues a stop of the database. If the database is still exposed, the UI blocks stop and asks you to Unexpose first. You also need a prior deployment, same as restart.

Templates

Templates can include databases alongside apps. Use Add New → Deploy from template when you want to start from a template. The same ideas for deploy, credentials, and Expose apply.

Logs, deployments, and backups (recap)

• Deployments and Logs are where you confirm provisioning succeeded and read server output.
• Backups is where you create internal dumps, restore, and remove dump files on the server. Details, permissions, and roadmap items are in Backups and restore.
• If a tab or button is missing, your workspace or plan may not expose it yet.

Database guides

Each engine has its own page, and every page follows the same outline so you always know what to expect:

1. Who it’s for: when this engine is a good fit.
2. Set it up: clicks in Applications from create through deploy.
3. Your connection details: what appears on Overview and how to use it.
4. Link your app: Variables tab, reference variables, and the exact token prefix for that engine.
5. Internet access: how Expose works for that engine (including single vs multiple ports).
6. Day-to-day: tabs, Deploy / Expose / Restart / Stop, and how they behave in the dashboard.
7. Useful links: official project and source where helpful.

Pick your engine:

• PostgreSQL (labeled “Postgres” in the app)
• MySQL
• MariaDB
• MongoDB
• Redis
• ClickHouse

Summary

• Applications → Environment → Add service → Database → name it → Deploy.
• Internal credentials are the default for apps on dFlow; Expose only when the open internet must reach the database.
• Reference variables on app and Docker services save you from hand-copying URLs and passwords (databases have no Variables tab).
• After the first successful deploy, Deploy disappears for databases; use Restart, Stop, and Expose / Unexpose from Overview or other tabs as needed.
• For connection strings, tokens, and Expose quirks, open the matching engine guide.

Related

• [Services overview](/docs/services/services-overview) and [Database services](/docs/services/database-services) for databases in the Services model.
• [Create a database service](/docs/databases/create-a-database-service)
• [Database credentials and connections](/docs/databases/database-credentials-and-connections)
• [Database troubleshooting](/docs/databases/database-troubleshooting) and [Deployment issues](/docs/troubleshooting/deployment-issues)
• [Service settings](/docs/services/service-settings) (reference variables for apps)