Install MariaDB on Ubuntu the Production Way

A default apt install of MariaDB on Ubuntu is convenient and incomplete. The package starts the daemon, opens a Unix socket, and leaves bind-address, authentication, the data directory, and a backup path as afterthoughts. Production means those choices are made before the first application connection, not after the first incident.

On a Netbay Ubuntu VPS in Lucknow DC01 you already have Intel Xeon Platinum cores, High-Speed SSD, and L3/L4 DDoS filtering at the edge. MariaDB still needs you to pick a supported package source, lock the listen address, understand how systemd starts the daemon, and prove you can restart without surprise. This is the install path to run before any application is allowed to create tables.

Pin a supported MariaDB series from the official repo

Ubuntu's own mariadb-server package is a snapshot. It is fine for a lab. For a server you will patch for years, pin a long-term series such as 10.11 or 11.4 from MariaDB's apt repository, then hold that major so a later dist-upgrade cannot jump the datadir into an unplanned series.

Import the signing key, add the repo for your Ubuntu release, and install only the server and client packages you need. Skip extra engines and plugins until an application asks for them. A smaller package set is a smaller attack surface and a cleaner upgrade later.

sudo apt-get update
sudo apt-get install -y apt-transport-https curl
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://mariadb.org/mariadb_release_signing_key.asc   | sudo gpg --dearmor -o /etc/apt/keyrings/mariadb.gpg
echo "deb [signed-by=/etc/apt/keyrings/mariadb.gpg] https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/ubuntu noble main"   | sudo tee /etc/apt/sources.list.d/mariadb.list
sudo apt-get update
sudo apt-get install -y mariadb-server mariadb-client
sudo apt-mark hold mariadb-server mariadb-client

Verify the binary you actually run, not the package name you think you installed. Mixing Ubuntu's mariadb-server with the official repo is how you get a half-upgraded datadir and a surprise on the next reboot. If the version string does not match the series you pinned, stop and fix the repo before you create databases.

mariadbd --version
systemctl is-enabled mariadb
systemctl is-active mariadb
ss -lntp | grep 3306

Keep the hold in place until you deliberately plan a minor upgrade. Unattended-upgrades should not be the process that changes your database major.

Bind locally until you have a reason not to

MariaDB should listen on 127.0.0.1 and the Unix socket. Do not bind 0.0.0.0 because an application on another host might need it later. Put the application on the same VPS, reach it over an SSH tunnel, or put it on a second VPS and restrict by source IP after you have users. Opening TCP 3306 to the public internet is never the first step. Edge L3/L4 DDoS filtering protects the instance; it does not make a database protocol safe to expose.

Create a drop-in under /etc/mysql/mariadb.conf.d/ so Ubuntu package upgrades do not clobber your listen policy. Name it with a high prefix so it wins over the packaged defaults.

# /etc/mysql/mariadb.conf.d/90-production.cnf
[mysqld]
bind-address = 127.0.0.1
skip-name-resolve = 1
max_connections = 100
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

Restart and confirm with ss that 3306 is local only. skip-name-resolve avoids DNS lookups on every connect, which matters when you later add host-based grants. utf8mb4 from minute one saves a painful conversion after the first emoji or Hindi string lands in a VARCHAR.

systemd, datadir, and the first-boot checklist

The unit should be enabled, not only started. The datadir should sit on High-Speed SSD with headroom for ibdata, undo, and binary logs. Ubuntu's unix_socket plugin lets the local root operating-system user enter the SQL prompt without a password. That is convenient for bootstrap and a trap if you do not know it exists. Use it to create an application user, then decide whether the root SQL account should have a password at all.

Work the first-boot checklist the same day as the install:

• Confirm mariadb.service is enabled and still active after a reboot, not only after apt returns.
• Confirm bind-address is 127.0.0.1 and that ss shows 3306 on localhost only.
• Remove anonymous users and the test database.
• Create an application user with host localhost and a database-specific GRANT. Never reuse root from the app.
• Put a dump job in place the same day, even if it is a crude mariadb-dump into /var/backups.
• Record the datadir path from SHOW VARIABLES so a later disk move is not a scavenger hunt.
• Confirm the error log path and that journalctl -u mariadb shows a clean InnoDB recovery on start.

A short SQL bootstrap you can paste once, as root via the Unix socket:

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'app'@'localhost' IDENTIFIED BY 'change-me-now';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, INDEX, ALTER ON appdb.* TO 'app'@'localhost';
FLUSH PRIVILEGES;
SHOW VARIABLES WHERE Variable_name IN ('bind_address','datadir','version','character_set_server');

A production MariaDB install is a pinned series, a local bind, a named application user, and a dump job that exists before traffic arrives. Package convenience is not a configuration. When you need a clean Ubuntu 24.04 box to practice this path, spin up an instance on Netbay in Lucknow in under 60 seconds from the dashboard or the API at netbayhosts.in.