Get Started

Databases

Many plugins and mods need a database: LuckPerms, CoreProtect, Oxide plugins, stats and ban lists. A customer creates a MySQL or PostgreSQL database with one click on their server's page and immediately gets the address, name, user and password. The panel creates the databases itself, on database servers you've connected or deployed.

For customers to be able to create databases you need two things: at least one host (a database server) and at least one rule that says which host a new database lands on. Both live in Infrastructure → Databases.

Hosts

A host is a MySQL, MariaDB or PostgreSQL server the panel creates customer databases on. You can deploy one straight from the panel or connect one that's already running.

Deploy a database server

The simplest option: the panel runs a database server in a container on one of your nodes. Click Deploy database server:

  1. What and where — Name, Node, Engine and version (MySQL 8.4 or 8.0, MariaDB 11.4 or 10.11, PostgreSQL 17 or 16), Memory, MB (1024 by default, at least 256) and CPU, cores (empty — no limit).
  2. Network — Node address for port: the node's game servers reach the database at this address. The internal address is selected by default. If you pick a public address or all interfaces, the database port is reachable from the internet — close it with a firewall unless customers need to connect to the database from outside. Port — empty means a free one from 33100–33999. Address for clients — what the customer sees in the connection string; empty — the node address.
  3. Rule — the New databases for servers on node … go here checkbox creates a "this node → this server" rule right away.

The panel generates the root password and stores it encrypted. The first start, with the image download, can take a few minutes. The host's status: Starting, Running, Stopped or Error with the reason. If the container disappears or stops on its own, the panel starts it again.

In the host's menu:

  • Stop the server / Start the server. While the server isn't running or its node is offline, no new databases are created on it.
  • Container logs — the latest lines of the database server's output.
  • Recreate container... — recreate the container with the same image and limits if it broke. Data is kept.
  • Edit... — the Container section: Version, memory and CPU. On save the node recreates the container on the same data; databases are unavailable until it's back up. The version can only go up within the same server: MySQL 8.0 → 8.4, MariaDB 10.11 → 11.4. You can't go back to an older version or switch MySQL to MariaDB. PostgreSQL's major version doesn't change — to move from 16 to 17, deploy a new server and move the databases through server backups.

A deployed database server's port is taken from the node's shared port pool, so game servers won't get it. It's shown on the Ports page.

The database server's data lives on a single node. The server itself isn't backed up as a whole, but customer databases go into their game servers' backups, see below.

Connect an external one

If you already have a database server, click Connect external:

  • Name, Engine — MySQL/MariaDB or PostgreSQL 13+. The engine can't change after creation.
  • Connect via — directly from the panel or via node agent. The second is for a host on an internal network that a node can see but the panel can't: SQL is then run by the chosen node's agent, and you enter the address and port as the node sees them.
  • Address, Port — how the panel (or the node) reaches the host.
  • User, Password — an admin account. For MySQL it needs CREATE/DROP DATABASE, CREATE USER and GRANT OPTION; for PostgreSQL a superuser or a role with CREATEDB and CREATEROLE. The password is stored encrypted and never shown; when editing the host, an empty field keeps the old one.
  • Address for clients — what the customer sees in the connection string. Empty — the same address.
  • Max databases — a full host is skipped. Empty — no limit.

Check connection in the host's menu tries to log in with this account and shows the error if it fails.

If the panel connects to the host directly, it must be able to reach it over the network. Game servers and customers connect at the address for clients — make sure the nodes can reach it.

For PostgreSQL, where customers may connect from is decided by pg_hba.conf on the server itself, so PostgreSQL databases don't have the Allow connections from field.

Change and delete

  • Disable (no new databases) — the host stops getting new databases; existing ones keep working.
  • While a host has databases, its address and port can't change. The account and password can.
  • A host can be deleted only when it has no databases and no rule refers to it. For an external host only the connection is removed; the database server itself isn't touched. For a deployed one the container is deleted along with its data and the port is freed. If the node doesn't respond, the panel offers to forget the server — then remove the container and its volume on the node by hand.
  • A node running a deployed database server, or a node used to reach a host, can't be deleted.

Rules

A rule says which host a new database lands on. Set the conditions — Location, Node, Plan, Game — and tick hosts under Where. An empty condition means "any".

For a new database the panel takes the most specific matching rule — the one with the most conditions set. On a tie, the rule with the higher Priority wins, then the newer one. Of the rule's hosts, the one that's enabled, not full, and has the fewest databases is used. If none fits (all disabled, full, of another engine, or their node is offline), the next rule is tried.

  • In the Plan field you can pick a plan group instead of a single plan — all plans with one label, such as "all with the label «premium»". The label is set in the plan form, see Plans.
  • Rules with the same conditions and priority are marked Conflict — the newer one wins.
  • To start, one rule without conditions is enough. If there are rules but none without conditions, the panel warns you: servers no rule matched won't be able to create a database.

Example: premium plans get databases on a dedicated server, everything else on a shared one.

| Plan | Where | Priority | |---|---|---| | all with the label «premium» | mysql-premium | 0 | | any | mysql-shared-1, mysql-shared-2 | 0 |

Check for a server below the rule list shows which host a new database of the chosen server lands on and why the other rules didn't fit.

Changing rules doesn't move existing databases: each stays on the host where it was created.

A server's databases

The Databases tab on the server's page. It's available to the owner and to co-owners with the Databases permission (see Users and roles).

Create a database:

  • Name — lowercase Latin letters, digits and _, up to 53 characters. The panel prefixes it with the server's tag: luckperms becomes s1a2b3c4d_luckperms.
  • Engine — shown when both MySQL and PostgreSQL hosts are connected.
  • Allow connections from (MySQL only) — the IP or subnet (CIDR) logins are allowed from. Empty — from anywhere.
  • Host — admins only: create the database on a specific host, bypassing the rules.

The user and password are generated by the panel. The database's row shows the connection address and the user. The password is behind Show password; every view is written to the audit log. Change password issues a new one: the old one stops working at once, so update it in your plugin configs.

Deleting a database removes it and its user on the database server, together with all data. If the host doesn't respond, an admin can forget the database in the panel — then it has to be removed on the host by hand.

Bind to parameters

To avoid copying the address and password into configs by hand, a database can be bound to the server's parameters: the panel writes its address, port, name, user and password into the db_host, db_port, db_name, db_user and db_password parameters, and the game gets them as the DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD environment variables.

This works when the game's settings declare those parameters. The easiest way is to add them as a set: in the game form's parameter block, pick the Database: DBHOST, DBPORT, DBNAME, DBUSER, DB_PASSWORD set. db_password in the set is a "secret", so the customer doesn't see it on the server card. How parameters get into the game — see Game catalog.

  • One database per server can be bound. A new database binds itself if the server doesn't have a bound one yet; the Bind to server parameters checkbox in the create form lets you opt out or take the binding over from another database.
  • Bind to parameters / Unbind from parameters — in the database's menu. A running server is recreated with the new variables.
  • Changing a bound database's password updates db_password right away. Deleting or unbinding the database clears all db_*.
  • Without a binding the panel doesn't touch db_*: an admin can point them at an external database by hand.

Plan limits

In the plan, the Databases section: Disallow databases and Max per server (empty — no limit). The tab shows how many databases are used out of the limit. Limits apply to all servers on the plan at once; databases already created stay. Admins aren't limited.

On a suspended server the customer can't create or delete databases but still sees the list and passwords.

Databases in backups

A server backup takes a dump of each of its databases, and a restore can load a dump back — into the same database, a new one, or another database of the server. A safety copy is taken before loading. Details are in Server backups.

Deleting a server

Deleting a server deletes its databases too. Reinstalling the server doesn't touch them.

Database creation and deletion can be received as database.created and database.deleted webhooks, see HTTP API and webhooks.