If you need to host MariaDB online, you have two practical options: use managed database hosting or run MariaDB on your own cloud server. The right choice depends on your budget, maintenance skills, backup needs, and how much control your application requires.
A public database is not automatically a usable database. You need controlled network access, separate user accounts, encrypted connections, tested backups, and a clear recovery plan. Start by choosing the hosting model, then build access around the application instead of exposing MariaDB to the entire internet.
Choose managed hosting or self-hosting
Managed MariaDB reduces maintenance
Managed hosting gives you a database server without requiring you to maintain the operating system. The provider usually handles updates, backups, monitoring, storage, and high-availability options.
MariaDB Cloud is the most direct option when you want MariaDB-specific hosting. Its public pricing has listed entry plans from $0.16 per hour, with higher tiers shown at $0.21 per hour. Published features include nightly backups, self-service snapshots, encryption at rest and in transit, IP allowlists, and private connectivity options such as PrivateLink or Private Service Connect.
AWS RDS for MariaDB is another common choice. It fits teams already using AWS networking, IAM, monitoring, and application services. Read the billing details carefully. AWS charges for provisioned storage and backup storage, including some storage costs while an instance is stopped.
Regional providers can also make sense. Danube Data advertises small MariaDB plans starting around €12.99 per month, with daily snapshots, TLS, and encryption at rest. Cloud Temple targets larger European workloads and publishes TLS 1.3, AES-256 encryption, private-network-only access, and plans starting at much higher monthly prices.
Provider prices and supported versions change. Check the live plan, MariaDB version, storage limit, connection limit, backup retention, region, and restore process before you pay.
Self-hosting gives you more control
A VPS gives you full control over the operating system, MariaDB configuration, firewall, backups, and network design. It can cost less for a small application, but you become responsible for every operational task.
You need to manage:
- Operating system security updates
- MariaDB version upgrades
- Firewall rules and private networking
- Database backups and restore testing
- TLS certificates
- Monitoring, disk space, and failed services
Self-hosting is suitable when you have basic Linux command-line skills and a simple workload. It is a poor choice when nobody owns database maintenance. A low monthly server bill does not compensate for an unrecoverable database.
How to host MariaDB online with the right access model
Before creating a server, decide how the application will reach MariaDB.
The safest setup keeps the database on a private network. Your application server connects through an internal address, VPN, private service link, or cloud security group. The database does not need a public IPv4 address.
If the application and database run on the same VPS, bind MariaDB to 127.0.0.1 and connect locally. If they run on separate servers, bind MariaDB to the database server’s private interface.
Avoid binding MariaDB to every network interface unless you have a specific, controlled reason. A setting such as 0.0.0.0 can make the service reachable through every active interface. That creates more exposure than most small applications need.
MariaDB’s remote client access guide covers the three controls you need to configure together:
- The address MariaDB listens on
- The hosts allowed for each database user
- The firewall rules that permit traffic
Changing only one of these controls does not create a safe remote connection.
Create separate users with limited privileges
Never use the MariaDB root account in application code. Root can modify every database, create users, remove tables, and change server settings. A leaked root password turns a database incident into a full server incident.
Create a database and a dedicated runtime user instead:
CREATE DATABASE app_db
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
CREATE USER 'app_user'@'10.10.0.%'
IDENTIFIED BY 'use-a-long-random-password'
REQUIRE SSL;
GRANT SELECT, INSERT, UPDATE, DELETE
ON app_db.*
TO 'app_user'@'10.10.0.%';
FLUSH PRIVILEGES;
Replace 10.10.0.% with the private subnet or exact application host that needs access. Do not use '%' unless you have a documented reason and additional network controls. A wildcard allows the account to authenticate from any source that can reach the server.
The runtime account usually doesn’t need DROP, ALTER, CREATE, or GRANT OPTION. Create a separate migration account for schema changes, then keep that account out of production application configuration.
Review the result:
SHOW GRANTS FOR 'app_user'@'10.10.0.%';
Use a password manager or secret manager for credentials. Never commit database passwords to Git, paste them into public issue trackers, or place them in a frontend JavaScript file.
MariaDB’s security documentation covers initial hardening, user permissions, network controls, and other server security settings.
Deploy MariaDB on a Linux VPS
The exact package name depends on your Linux distribution. On an Ubuntu-based server, a basic installation looks like this:
sudo apt update
sudo apt install mariadb-server
sudo systemctl enable --now mariadb
sudo mariadb-secure-installation
The secure-installation utility helps remove anonymous accounts, restrict test objects, and review administrative settings. Treat it as an initial hardening step, not a complete production configuration.
Check that MariaDB is running:
sudo systemctl status mariadb
mariadb --version
Do not install an old distribution package without checking its supported MariaDB release. For production, use a supported version and a repository with a clear update policy. Test major-version upgrades on a separate instance before changing the live database.
Restrict the listening address
Open the MariaDB server configuration file. On many Debian-based systems, it is located at:
/etc/mysql/mariadb.conf.d/50-server.cnf
Set the address to the database server’s private IP:
[mariadb]
bind-address = 10.10.0.5
Use the actual private address assigned to the server. If the application runs on the same machine, use:
bind-address = 127.0.0.1
Restart MariaDB after the change:
sudo systemctl restart mariadb
sudo ss -lntp | grep 3306
The output should show the intended address. If MariaDB listens on 0.0.0.0:3306, stop and review the configuration before continuing.
Limit port 3306 with a firewall
MariaDB uses TCP port 3306 by default. Do not open that port to every internet address.
For a private application subnet, a UFW rule may look like this:
sudo ufw allow from 10.10.0.0/24 to any port 3306 proto tcp
sudo ufw enable
sudo ufw status numbered
If your cloud provider has security groups or network ACLs, restrict the port there too. The host firewall and cloud firewall should support the same access policy.
MariaDB should not be reachable from the public internet merely because a remote developer wants to connect. Use an SSH tunnel, VPN, or temporary allowlist entry for administration.
Encrypt every connection
A firewall controls who can reach the port. TLS protects the data after a connection is made.
Without encrypted transport, database credentials and query data can be exposed on an untrusted network. This matters when an application server, developer laptop, database server, or private network crosses a provider boundary.
MariaDB’s platform security guidance recommends encryption in transit for client-server communication. Managed providers usually offer TLS certificates as part of the service. Confirm whether certificate verification is required by default.
For self-hosting, configure a certificate issued by a trusted certificate authority. A test certificate can help during development, but it should not be your production trust model.
A typical configuration includes:
[mariadb]
ssl_ca = /etc/mysql/ssl/ca.pem
ssl_cert = /etc/mysql/ssl/server-cert.pem
ssl_key = /etc/mysql/ssl/server-key.pem
require_secure_transport = ON
Protect the private key with restrictive file permissions. The MariaDB service account needs to read it, but ordinary users should not.
Connect with certificate verification enabled:
mariadb
--host=db.example.com
--user=app_user
--password
--ssl-ca=/path/to/ca.pem
--ssl-verify-server-cert
Check the active connection inside MariaDB:
SHOW STATUS LIKE 'Ssl_version';
A populated value confirms that the current session uses TLS. If your client library uses different TLS option names, follow its current documentation and require certificate verification.
Configure the application safely
Your application should read database settings from environment variables or a secret manager:
DB_HOST=db.internal.example
DB_PORT=3306
DB_NAME=app_db
DB_USER=app_user
DB_PASSWORD=stored-in-secret-manager
DB_SSL=true
Do not place production credentials directly in source code. Do not expose them through client-side configuration. The browser should communicate with your application, not directly with MariaDB.
Use a connection pool with sensible limits. Too many open connections can exhaust a small managed plan or VPS. Set connection timeouts so a failed database does not cause every application request to hang.
Test the connection from the application server, not only from your laptop. A successful local test does not prove that private DNS, firewall rules, TLS certificates, or cloud routing work in production.
A useful first test checks:
- DNS resolves to the intended database address
- Port 3306 is reachable only from the application network
- TLS negotiation succeeds
- The runtime user can perform required queries
- The runtime user cannot alter unrelated databases
You can verify permission boundaries with a test query:
SHOW DATABASES;
The application user should see only what its grants allow. If it can access every database, reduce its privileges before launch.
Compare providers before you deploy
Price is only one part of a hosted MariaDB decision. Compare the operational details that affect your application after launch.
| Decision area | Questions to ask |
|---|---|
| MariaDB version | Is your required major version supported and maintained? |
| Backups | Are backups automatic, encrypted, retained, and restorable? |
| Recovery | Can you restore to a new instance without replacing production? |
| Networking | Are private endpoints, IP allowlists, VPNs, or service links available? |
| Security | Is TLS required, and can you verify the provider certificate? |
| Scaling | Can you increase storage, memory, and connections without migration? |
| Location | Does the region meet latency, residency, and compliance needs? |
| Support | Can you get help with failed restores, outages, and version changes? |
A cheap plan with no restore process is not cheap when the database fails. A larger plan may be justified when downtime affects customer orders, payments, or internal operations.
Ask about backup retention and point-in-time recovery. A nightly snapshot can protect against server loss, but it may not recover a table deleted five minutes ago.
Back up the database and test restoration
Managed backups are useful, but they don’t remove your responsibility for recovery. Confirm that backups are enabled, review retention, and perform a test restore.
For a self-hosted database, create an encrypted off-server backup. A basic logical dump is:
mariadb-dump
--single-transaction
--routines
--events
app_db | gzip > app_db-$(date +%F).sql.gz
Store the backup on a separate system or encrypted object-storage bucket. A file on the same VPS does not protect you from disk failure, ransomware, or accidental server deletion.
Restore into a temporary MariaDB instance before trusting the process:
gunzip < app_db-2026-09-05.sql.gz | mariadb app_db
Use the actual backup date in your command. Check row counts, indexes, stored routines, application login, and recent transactions after restoration.
Keep a short recovery record with the backup location, encryption key owner, restore command, retention period, and person responsible for the test.
Avoid these online MariaDB mistakes
The most common failures are configuration decisions made for convenience:
- Opening port 3306 to
0.0.0.0/0 - Allowing the user host to be
% - Running the application as
root - Disabling TLS because the connection works without it
- Saving passwords in source code or shell history
- Assuming provider backups have been tested
- Upgrading MariaDB without checking application compatibility
- Using one account for runtime queries, migrations, and administration
- Putting the database on a public server without firewall monitoring
A remote connection should be narrow by design. Give one application access to one database, through one network path, with one account that has only the permissions it needs.
Conclusion
You can host MariaDB online safely with either managed hosting or a self-managed VPS. Managed services reduce maintenance, while self-hosting provides more control and can lower the starting cost.
The essential setup is consistent: keep MariaDB on a private network where possible, restrict the firewall, create least-privilege users, require TLS, protect credentials, and test restoration before you need it. A database that works from your laptop is only the beginning. A production database must also be difficult to reach, limited when reached, and recoverable when something goes wrong.
