Databases - Deploynix Docs

Databases

Create and manage MySQL, MariaDB, and PostgreSQL databases, users, and connections from the dashboard — no SQL required.

Overview

Deploynix installs a database engine at server provisioning time and gives you a Databases tab on every App Server and Database Server. From there you create databases, issue scoped users, copy credentials, and — for Database Servers — accept remote connections from your other servers or from your laptop. Every action runs over SSH against the actual engine, so what you see in the dashboard matches exactly what's on the server.

Supported Engines

You pick the engine once, when you create the server. It cannot be changed after provisioning.

  • MySQL — installed from the system package repository (typically MySQL 8 on modern Ubuntu).
  • MariaDB — installed from the system package repository (typically MariaDB 10.6+).
  • PostgreSQL — installed from the official PostgreSQL apt repository.

New databases are created with sensible defaults: MySQL and MariaDB use utf8mb4 with utf8mb4_unicode_ci collation, PostgreSQL uses UTF-8. There is no version-pinning UI — create a new server if you need a different engine or a different major version.

App Servers vs. Database Servers

Both server types ship with a database engine, but they're configured differently:

Aspect App Server Database Server
Bind address 127.0.0.1 only All interfaces
User host @localhost @% (remote-ready)
Use case Co-located with the app, lowest latency Shared by multiple Web Servers, separate lifecycle, dedicated resources
Backups tab Uses organization-level backups Dedicated Backups tab on the server

Creating a Database

  1. Open the server and go to the Databases tab.
  2. Click Add Database.
  3. Enter a name. It must start with a letter or underscore, may contain letters, digits, and underscores, and is capped at 64 characters.
  4. (Optional) Override the engine if the server has more than one installed. Most servers have one.
  5. Click Create. The database is created asynchronously against the live engine and appears in the list when ready.

Naming Convention

Use lowercase names with underscores, e.g. my_app_production. Avoid hyphens — they force you to quote identifiers in every query.

Database Users

Create a dedicated user for each application. Each user is scoped to a single database with full privileges on that database — no user has ambient access across the server.

Creating a User

  1. Open a database and click Manage UsersAdd User.
  2. Enter a username: letters, digits, and underscores, starting with a letter, up to 32 characters.
  3. A secure 24-character password is generated for you — you don't pick it.
  4. (Optional) Link the user to a site on the same server. If you do, Deploynix writes the connection details into the site's environment variables automatically.
  5. Click Create.

Copy the Password Immediately

The generated password is shown once, right after the user is created. It's encrypted at rest and never re-displayed. Copy it into a password manager now — or skip it entirely and let Deploynix inject it into a linked site's env.

Privileges

New users receive ALL PRIVILEGES on their assigned database. Granular read-only or schema-scoped privileges are not exposed in the UI — if you need them, SSH into the server and GRANT manually, then track the change in your own notes.

Linking a Site to a Database

When you create a site you pick a database option:

  • None — for frontends that don't talk to a database.
  • SQLite — a file-based database stored under the site's shared/ directory so it survives deploys.
  • This server — existing — pick an existing database on the current server and (optionally) an existing user.
  • This server — new — Deploynix creates a new database and user for you.
  • External — supply host, port, database name, username, and password for any database you can reach.

When a site is linked to a database user, these environment variables are populated and synced automatically:

DB_CONNECTION=mysql        # or pgsql
DB_HOST=127.0.0.1          # server IP for external/remote databases
DB_PORT=3306               # 5432 for PostgreSQL
DB_DATABASE=my_app_production
DB_USERNAME=my_app_user
DB_PASSWORD=<auto-generated>

The .env on the server is updated automatically — the next deployment picks up the new values.

Remote Access

Remote access is determined by server type, not by per-database toggles:

  • App Server — the database engine binds to 127.0.0.1. Users are created with host @localhost. Remote clients can't connect, which is exactly what you want when the database is co-located with the app.
  • Database Server — the engine binds to all interfaces and users are created with host @%. Connections from your App / Web / Worker servers work out of the box as long as firewall rules allow the database port (they do by default on fresh Database Servers).

To connect from your laptop with a GUI client like TablePlus or DataGrip, add a Network Rule allowing your IP on the database port (3306 for MySQL/MariaDB, 5432 for PostgreSQL), then use the user you created in the Databases tab.

Running Queries

There is no built-in web SQL editor or phpMyAdmin. Use one of:

  • The server's web terminal with the native CLI (mysql, mariadb, or psql).
  • A local GUI client like TablePlus, DataGrip, or DBeaver — against an App Server via SSH tunnel, or directly against a Database Server.
  • Laravel's php artisan tinker and db:show / db:table commands for quick checks.

Backups & Restoration

Deploynix has a dedicated backup system that covers every database engine:

  • Scheduled backups — daily by default, with retention windows of 7, 14, or 30 days.
  • On-demand backups — trigger a backup from the UI whenever you like.
  • External storage — AWS S3, DigitalOcean Spaces, Wasabi, or any S3-compatible bucket. Credentials are stored encrypted.
  • Restore — pick any completed backup and restore it into the original database or a new one.

Restoration Warning

Restoring a backup overwrites the current database. Take a fresh on-demand backup before you restore, in case you need to return to the most recent state.

Deleting a Database

On the database's row, click Delete. The confirmation modal shows which database users are attached. Users scoped to only this database are deleted with the database; users shared with another database are preserved and flagged in the modal so you don't accidentally break another application.

Best Practices

  • • One database and one user per application — never share credentials between apps.
  • • Never run your apps as the database's root / postgres superuser.
  • • Turn on scheduled backups before your first production deploy, not after.
  • • Test a restore at least once — a backup you've never restored is a backup you don't have.
  • • If you need remote access from the internet, allow only your office / VPN IPs in the server's network rules, not 0.0.0.0/0.