MariaDB Replication
Asynchronous primary/replica MariaDB - a writable primary streaming to a read-only replica.
One-click deploy, from $13/mo on a Miget plan.
This is classic asynchronous MariaDB replication: one primary accepts writes and streams its binary log to a read-only replica. It is the standard topology for read-scaling (send reads to the replica) and for keeping a hot standby copy of your data.
The official MariaDB image wires it from environment variables - the primary creates the replication user automatically, and the replica configures itself against the primary and starts replicating on first boot, so there are no init scripts. The replica is started read-only.
Replication is asynchronous: the replica can lag slightly under load, and a failed primary does not auto-promote (that is a manual or external-tooling step). For synchronous, automatic multi-primary HA, use mariadb-galera.
Upstream project: MariaDB
#what you get
- Writable primary + read-only replica
- Binlog replication wired from environment variables
- No init scripts - the image configures the replica
- Read-scaling and hot-standby topology
- Both nodes internal-only
- GPLv2
#topology
| Service | Role | Public |
|---|---|---|
| mariadb-primary | writable primary (:3306) | no (internal) |
| mariadb-replica | read-only replica (:3306) | no (internal) |
#miget sizing
// this stack needs
2 GiB RAM · 20 GB disk · 2 services
1 GiB per node suits typical workloads. The replica holds a full copy of the data, so size both volumes the same. Asynchronous - expect small replica lag under load.
Hobby - recommended fit
$13/mo
1 vCPU · 2 GiB · 50 GiB disk
Headroom for your own apps: 2 GiB at $19/mo
Professional - production
$43/mo
2 vCPU · 4 GiB · 25 GiB disk
Dedicated resources, production SLOs - plan details
One Miget plan is a fixed pool of compute - the whole stack (managed databases included) deploys inside it, and anything left over runs your other apps. No per-service or per-seat math.
#vs. the managed service
What the hosted equivalents charge, against the flat Miget plan this stack fits on. Prices as of June 2026, sources linked.
| Service | Plan | Monthly | What you get |
|---|---|---|---|
| MariaDB Replication on Miget ★ | 2 GiB plan | $13 | this whole stack, flat - no usage meters, and room left for your own apps |
| AWS RDS | primary + read replica | ~$30 | two smallest instances/mo + storage |
A managed read replica is a second billed instance; here the primary + replica is one flat plan.
#vs. other PaaS
Estimated monthly cost of running this exact stack (2 GiB RAM, 20 GB disk, 2 containers) elsewhere, from published June 2026 rates.
| Platform | Est. monthly | Notes |
|---|---|---|
| Miget ★ | $13 flat | compose stacks first-class: one deploy, dedicated vCPU, managed Postgres/Valkey, volumes and TLS all included in the plan |
| Heroku | ~$100 | no volumes; nothing between 1 GB ($50) and 2.5 GB ($250) dynos - 2 GB containers cost far more than shown |
| Render | ~$30 | per-service instances (0.5 GB $7, 2 GB $25) - every container is its own paid service |
| DO App Platform | ~$29 | no persistent volumes - stateful containers need managed DBs/Spaces (base $5 Spaces included here) |
| Railway | ~$23 | usage-based ($10/GB RAM-mo); vCPU billed separately at $20/vCPU-mo on top |
| Fly.io | ~$15 | cheapest sticker price - but burstable shared CPUs (1/16 core; dedicated vCPUs cost ~2-3×), no compose deploys (one app per container, manual wiring), managed DBs billed extra |
Estimates assume RAM fully allocated at published on-demand rates - and sticker price isn't the whole comparison: the cheaper rows buy burstable shared CPUs, per-service wiring instead of a compose deploy, and managed databases billed separately. Heroku and DO App Platform have no persistent volumes at all - stateful stacks like this one need workarounds there.
#deploy it
On Miget
- Create a Compose Stack in app.miget.com pointing at the templates repository
- Set the stack path to
mariadb-replication -
Set the required variables:
MARIADB_ROOT_PASSWORD, root password (same on both nodes)MARIADB_PASSWORD, app user passwordMARIADB_REPLICATION_PASSWORD, replication account password
- Deploy. Miget layers
compose.miget.yaml(RAM, privacy, volumes, managed services) automatically
Locally first?
Every template is portable, vanilla Docker Compose - the Miget overrides are ignored locally:
git clone https://github.com/deployable-sh/stacks
cd miget-compose-templates/mariadb-replication
docker compose up -dSame files, same behavior. The template README covers connection strings and scaling notes.
#faq
What is this good for?
Read-scaling (route read-heavy queries to the replica to offload the primary) and keeping a hot standby copy of your database. It is the most common MySQL/MariaDB replication setup.
Does it fail over automatically?
No. Asynchronous replication does not auto-promote the replica if the primary dies - promotion is a manual or tooling-driven step. For automatic failover use mariadb-galera (synchronous multi-primary).
How is the replica set up?
Automatically. The official image creates the replication user on the primary and, on the replica, configures replication against MARIADB_MASTER_HOST and starts it on first boot - no scripts to run.
Ship MariaDB Replication today
One compose stack, 2 GiB of RAM, from $13/month flat, and it runs on your laptop with the same files.