TL;DR: I needed to expose MySQL on the internet without getting scanned into oblivion within 48 hours. I stacked HAProxy in front of ProxySQL in front of MySQL. It works. I also spent six hours fighting a proxy that reads its config file once in its life, then pretends it never met you.

The problem (or: why I didn't just buy an $80/month RDS)

I'm building DockSky, an indie SaaS, solo, on an 8 GB OVH VPS for about €14/month. No ops team. No "managed database" budget. Just me, Docker, and optimism.

Except DockSky isn't just a REST API with Postgres behind it. The product is managed multi-tenant MySQL: each customer gets their own MySQL user, their own credentials, real isolation. Not a tenant_id column and a prayer.

For that to work, I need external MySQL access on port 6033, without leaving MySQL wide open on the internet like a vending machine at 3 a.m.

Before ProxySQL, I already had HAProxy forwarding traffic to MySQL. It worked. In the sense that nobody had tried SELECT * FROM users WHERE 1=1 on me yet.

What I was missing:

• Rate limiting at the network layer (a bot opening 500 connections is trivial)
• Connection pooling (my VPS has 8 GB of RAM, not a datacenter)
• A layer to route multi-tenant users without hand-editing MySQL every time someone signs up

So: a network gateway and a SQL gateway. Two tools, two jobs. Like a bouncer at the club door and another at the VIP bar. Except nobody's paying cover yet. Still in beta.

The architecture (Post-it edition)

Internet (port 6033, the only MySQL port open in UFW)
    ↓
HAProxy          → "Be nice, but not too many connections"
    ↓
ProxySQL         → "Does your user exist? Is this query acceptable?"
    ↓
MySQL 8.x        → localhost only, like a well-behaved introvert

On the side, Traefik handles HTTPS for admin interfaces:

• haproxy-stats.docksky.fr to see if everything's green
• proxysql-admin.docksky.fr to stare at tables I only half understand

I created the subdomains via the OVH DNS API. Because clicking 40 times in the OVH panel is the kind of task that makes me want to quit software and open a food truck.

What I actually deployed

1. Lock down MySQL (finally)

MySQL only listens locally:

ports:
  - "127.0.0.1:3306:3306"

Want my data? Get in line. Like the post office, but with rate limiting.

2. HAProxy: friendly but firm bouncer

Frontend on *:6033, backend to proxysql:6032:

stick-table type ip size 100k expire 30s store conn_cur,conn_rate(3s)
tcp-request connection track-sc0 src
tcp-request connection track-sc1 src
tcp-request connection reject if { sc0_conn_cur ge 5 }
tcp-request connection reject if { sc1_conn_rate ge 10 }

Human translation: 5 simultaneous connections max per IP, 10 new connections max every 3 seconds. Enough for an honest client. Not enough for a script kiddie with a for loop and too much free time.

3. ProxySQL: the six-hour side quest

Docker service with:

• a template proxysql.cnf.template (no secrets in git, I learned that lesson earlier)
• a custom entrypoint that generates config at startup
• tmpfs on /var/lib/proxysql (more on that, it's the plot twist)
• beta user sync from MySQL into ProxySQL at boot (otherwise every new DockSky customer means a manual intervention, and I don't have a support team)

The entrypoint waits for ProxySQL to be ready, then syncs users. Because ProxySQL takes 25 to 30 seconds to wake up. Like me, but without coffee.

4. Version everything before the VPS explodes

I spun up a docksky-infra repo with a full disaster recovery procedure. Because one day the VPS will die (Murphy's Law, Docker edition) and I don't want to rebuild this from memory on a Sunday night.

What broke (the part Dev.to loves)

Issue #1: Docker Compose 1.29.2

Symptom: KeyError: 'ContainerConfig'. Couldn't recreate containers.

My reaction: "It's not me, it's Docker." (Spoiler: it was Docker.)

Fix: upgrade to Docker Compose v2. docker compose, no hyphen. Like switching from a bike to a car, except the car costs fewer nerves.

Issue #2: ProxySQL and the ghost config file

The trap that ate six hours.

Official docs, one killer sentence:

"After first startup the DB file is used instead of the config file"

ProxySQL creates an internal SQLite database on first boot. Then it ignores your .cnf like an ex ignoring your texts.

I tried:

• --initial → nope
• deleting the volume → the DB comes back, poltergeist style
• native env vars → ProxySQL doesn't care

What actually works:

1. tmpfs on /var/lib/proxysql. SQLite dies on every restart, ProxySQL is forced to reread the template
2. custom entrypoint generates /etc/proxysql.cnf with real passwords (sed first, then perl when sed started giving me side-eye)
3. wait 30 seconds before testing. Otherwise you think it's broken when it's just slow

Trade-off: any live change in ProxySQL (INSERT INTO mysql_users, etc.) vanishes on restart. Source of truth is the template. Not the moody SQLite database.

Issue #3: HAProxy declares ProxySQL dead

Logs: Access denied for user 'monitor'

I'd set option mysql-check user monitor. Except in ProxySQL, monitor is for watching MySQL backends, not for saying "hey, you alive?" to the proxy itself.

Fix:

option tcp-check

Port open? It's UP. Stoic philosophy for healthchecks.

Issue #4: Two stick-tables, one angry HAProxy

Symptom: crash loop, stick-table name 'mysql-in' conflicts

I'd declared two separate tables. HAProxy doesn't share well. One table, two counters. Like a Paris studio, but for IPs.

Issue #5: envsubst doesn't exist in Alpine

Logs: envsubst: command not found

The ProxySQL image is minimal. I'd copied a 2019 Stack Overflow tutorial. Classic.

Fix: sed, then perl. The current wrapper uses perl. At some point you stop fighting sed and accept defeat with dignity.

Issue #6: The silent restart (a few weeks later)

ProxySQL refused connections after a restart. No noise. No email. No "sorry boss."

I caught it in metrics within 5 minutes. Fixed in 30. That's exactly why I have healthchecks and a dashboard. Not to look good on a "our stack" slide.

What's running today

UFW: only 6033 is open for MySQL. Everything else goes through Traefik or stays on localhost. My security policy is "paranoid, but not paranoid enough to shut everything down and work from a Raspberry Pi in a closet."

Is it worth it for a solo SaaS?

Honestly: it depends.

Yes if:

• you want multi-tenant MySQL without paying €80/month for managed DB
• you'll read the docs when things break (and they will)
• you document everything, because future you remembers nothing

No if:

• you want to sleep without thinking about ProxySQL
• you have 50 customers and no monitoring
• you hate proxies with a SQLite personality disorder

For DockSky today, it's the right trade-off. A €14 VPS, a stack I understand layer by layer, and an infra repo I can rebuild from scratch if OVH decides on a Tuesday that my server has lived its best life.

What I learned

1. Upgrade your tooling before adding a critical service. Docker Compose v2 saved me before ProxySQL even showed up.
2. Read the official docs. The SQLite sentence was there. I just took 4 hours to find it.
3. Simple healthchecks beat clever ones. TCP check is ugly but works.
4. Wait 30 seconds. ProxySQL isn't lazy. It's… deliberate.
5. Version everything. Shout-out to my dated docker-compose.yml backup from November 17, 2025.
6. Monitor. A proxy that dies quietly is a proxy you discover when a customer DMs you.

The punchline

Here's the part that still makes me laugh.

The original project this stack was built for? I abandoned it. Dead. RIP. Somewhere in a folder with a name I try not to open.

But HAProxy, ProxySQL, the OVH VPS, the disaster recovery repo, the "wait 30 seconds or you'll think it's broken" wisdom? All of that got recycled into DockSky. Same infrastructure, different dream. Like keeping the engine from a car you totaled and dropping it into something that actually runs.

So no, I wouldn't recommend building this stack just to abandon the product. But if you're a solo dev who's already paid the tuition in broken healthchecks and angry SQLite databases, you might as well reuse the homework.

Questions? I'm at docksky.fr. Contact form. No Telegram bot that replies "have you tried turning it off and on again."

Stack: OVH VPS 8 GB · Debian · Docker Compose v2 · Traefik · HAProxy 2.8 · ProxySQL 2.7 · MySQL 8.4 · lots of logs