Hi folks.
I’m consider running Ghost (the CMS) on Fly. And then I would need a MariaDB as the database.
I could either run the db on Fly or elsewhere (a VM on AWS/DigitalOcean/whatever).
I’m curious to hear your general experiences with running MariaDB on Fly.
Does it work well? Any certain gotchas I should be aware of?
Hi… The biggest one is that the Fly.io Machines platform is hard for databases, in general. Even world-class experts like Turso and Supabase throw in the towel, 
, sometimes.
For experience with MariaDB/MySQL specifically, I’d suggest browsing the mysql tag, here in the forum, where there’s a person who nearly lost an entire database, etc.
(Actually, that happened to the same person twice, as I recall.)
The official doc about the underlying architectural problem is here:
https://fly.io/docs/apps/app-availability/
Individual Fly.io employees have put it more strongly:
(That thread was about Postgres, but ultimately those principles apply equally well to MySQL.)
Consequently, unless you were specifically interested in running a multi-Machine database cluster, the non-Fly options are really the way to go.
(The new Sprites concept may change that balance eventually, but it’s still under heavy development.)
Aside: If you are interested in clusters then Fly.io is really nice, though. One of the main things that I use it for is to experiment with multi-node databases…
This is the way to go, I think. If you’re a solid DBA then self-hosting a cluster is fine, but if you have a business/project to run, self-hosting probably isn’t a good use of your time.
Very useful info!
So, running a VM elsewhere seems like a good option for me.
Then I need to somehow arrange so that the Fly app can talk to MariaDB.
Have I understod it correctly that I can use `flyctl wireguard create` to create a private network for that purpose…?
(Since the VM is running Linux I assume it has WireGuard built-in.)
I use Postgres on Supabase, and that didn’t need any Wireguard setup - I just use the connection string offered by the db platform, including the db name, plus a root password, and that’s about it. All machines have full internet connectivity outwards, so from memory there was nothing else I needed to do.
I see! I was thinking in case I set up MariaDB myself in a virtual machine. I could expose port 3306 to the Internet, but I would prefer access to be more restricted than that.
You don’t need to use Wireguard to do that. Apps within the same organisation can connect to each other on the private IPv6 by default. You’d just remove public IPs, so the db is only available privately.
Per the earlier note:
if you do set up a homemade cluster, if your database is valuable, please set up more than one node! 
It is fine to have one node if you don’t care about your data, or you can easily recreate it, or you do frequent off-site backups and don’t mind outages when you do a manual restore.
I think the WG question was actually for the variant in which MariaDB would be on DigitalOcean, or similar, 
…
(I will look at this more later tonight, but, if I recall correctly, flyctl wireguard create will work ok for this as long as the WG client and the MariaDB server are the exact same external VM.)
Yeah, that does indeed work, although maybe it’s not optimal. That mechanism is more intended for allowing the external VM to call things that are on the Fly.io .internal network, but it does enable Fly.io Machines to connect to listening TCP ports on that particular external VM, if they want. You can use flyctl wireguard create your-org-name arn sealion to give the other side the nice name sealion._peer.internal in DNS.
Where people have run into surprises with this in the past is in trying to access other addresses on the non-Fly.io network. That doesn’t work out of the box, since the default routing rules have no knowledge of what else is over there. They only know how to reach that one VM at the opposite end of the WG tunnel.
Also, it’s been mentioned in the past that these managed WG nodes have limited bandwidth. I don’t know what that ceiling is, though.
Overall, the flyctl wireguard create way should get you rolling initially, but after a certain point it might make more sense to flip the direction around, i.e., make the external VM be the WG server…
Great info, thank you all!
