MariaDB Galera
3-node synchronous multi-primary MySQL-family HA on the official image - every node writes, any node can die.
One-click deploy, from $25/mo on a Miget plan.
MySQL-family high availability got harder to ship in 2025 when Broadcom paywalled the Bitnami images everyone’s tutorials used. The good news, verified by actually running clusters: the OFFICIAL mariadb image carries the Galera library, and a 3-node multi-primary cluster forms from pure command-line flags plus one env var.
Galera is synchronous: every node accepts writes, every commit lands on the quorum, and a node loss costs availability nothing. The traps are operational, and this template handles each one found in testing - the bootstrap flag fires only on a genuinely first boot (a permanent flag crash-loops on restart), stop_grace_period is 2 minutes (the 10-second default SIGKILLs mariadbd and poisons cluster state), and the cold-start recovery procedure is documented rather than discovered at 3am.
An app database and user replicate to all nodes at bootstrap. Apps connect to any node - list all three for driver-level failover.
Upstream project: MariaDB 11.8 LTS + Galera
#what you get
- Synchronous multi-primary: write to any node, lose any node
- Official mariadb:11.8 LTS image - no forks, no paywalled registries
- Flag-driven clustering; bootstrap-once wrapper (tested) on node 1
- stop_grace_period and recovery runbook handled, not hand-waved
- App database/user replicated cluster-wide at bootstrap
- Per-node volumes; healthchecks via the image’s --galera_online
#topology
| Service | Role | Public |
|---|---|---|
| galera-1 | node + bootstrap-once wrapper (:3306) | no |
| galera-2, galera-3 | nodes (join via SST/IST) | no |
#miget sizing
// this stack needs
3 GiB RAM · 15 GB disk · 3 services
Nodes idle near 135 MiB with default buffer pools - 1 GiB each leaves real working-set room. Three nodes is the quorum minimum; scale by adding blocks to the gcomm list.
Hobby - recommended fit
$25/mo
2 vCPU · 4 GiB · 80 GiB disk
Headroom for your own apps: 8 GiB at $49/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. other PaaS
Estimated monthly cost of running this exact stack (3 GiB RAM, 15 GB disk, 3 containers) elsewhere, from published June 2026 rates.
| Platform | Est. monthly | Notes |
|---|---|---|
| Miget ★ | $25 flat | compose stacks first-class: one deploy, dedicated vCPU, managed Postgres/Valkey, volumes and TLS all included in the plan |
| Heroku | ~$150 | no volumes; nothing between 1 GB ($50) and 2.5 GB ($250) dynos - 2 GB containers cost far more than shown |
| Render | ~$41 | per-service instances (0.5 GB $7, 2 GB $25) - every container is its own paid service |
| DO App Platform | ~$41 | no persistent volumes - stateful containers need managed DBs/Spaces (base $5 Spaces included here) |
| Railway | ~$32 | usage-based ($10/GB RAM-mo); vCPU billed separately at $20/vCPU-mo on top |
| Fly.io | ~$20 | 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-galera -
Set the required variables:
MARIADB_ROOT_PASSWORD, root on all nodesMARIADB_APP_PASSWORD, the replicated app user/database
- 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-galera
docker compose up -dSame files, same behavior. The template README covers connection strings and scaling notes.
#faq
Why not the managed MySQL?
The managed MySQL is the right default for a single instance. This template exists for the HA case - synchronous multi-primary across three nodes - which managed single-instance offerings do not provide. Different reliability class, same project network.
What happened to the Bitnami images everyone used?
Broadcom moved Bitnami to paid “Secure Images” in late 2025; the free mariadb-galera images are frozen without security updates. This template needs none of that: the official mariadb image has shipped the Galera library all along, configured via flags.
What does the bootstrap wrapper actually solve?
Galera’s classic foot-gun: --wsrep-new-cluster must run exactly once, on the first node’s first boot. Left in the command permanently, the safe_to_bootstrap guard crash-loops the node on every restart - verified by testing. The wrapper checks for grastate.dat and adds the flag only when the datadir is genuinely new.
What if the whole cluster stops uncleanly?
Galera refuses to guess which node has the newest data - by design. The README gives the two-step recovery (pick the highest-seqno node, flip safe_to_bootstrap, start it first). It is a documented 2-minute procedure, not an outage mystery.
Ship MariaDB Galera today
One compose stack, 3 GiB of RAM, from $25/month flat, and it runs on your laptop with the same files.