Here’s What I Learned So YOU Don’t Have To
For the last 24 hours, I’ve been on one of the wildest DevOps rollercoasters of my life — all because I tried to enable a single feature inside n8n, the open-source automation tool that I’ve been self-hosting.
As someone who self-hosts multiple WordPress sites, databases, automation tools, and Docker stacks… I thought I had seen it all.I hadn’t. 😅
If you self-host n8n or run Docker containers behind a reverse proxy, please read this. It might save your night, your websites, and your sanity.
🚀 How It Started: “Just Add This One Line…”
I wanted to enable n8n’s new “Text-to-Workflow” AI feature — a really cool shortcut for building automations faster.
The instructions online were simple:
“Just add a couple environment variables to your docker-compose.yml.”
Easy.
Harmless.
Nothing to worry about.
Right?
Wrong. So wrong.
Within minutes of restarting the n8n container… the dominoes started falling.
💥 The First Sign of Trouble: 502 Bad Gateway
After editing my docker-compose and spinning n8n back up, I visited:
n8n.my-domain.com
and got:
❌ 502 Bad Gateway
Okay. Not great, but also not unusual for a container restart.But then I checked my main website and got:
❌ Error Establishing a Database Connection
My stomach dropped. Then my second site went down. Then my uptime workflow in n8n began emailing me telling me that everything was down.
My automation tool was literally snitching on itself.
🤦♂️
🔍 What Actually Happened (The Real Culprit)
Here’s the part that took hours to unravel:
🧩 1. n8n launched with Caddy, which grabbed ports 80/443
Even though my system already had a reverse proxy (Nginx Proxy Manager) managing those ports perfectly, Caddy started up and claimed:
• Port 80 (HTTP)
• Port 443 (HTTPS)
That single action:
👉 Broke all domain routing
👉 Hijacked SSL
👉 Disconnected multiple services
👉 Caused WordPress containers to lose access to their databases
👉 Split Docker networks into isolated “islands”
It’s the kind of issue that only happens when the stars align in the worst possible way.
🧩 2. My n8n container switched networks
After editing the compose file, n8n ended up on a different Docker network than my proxy — meaning the reverse proxy could no longer reach n8n at all.
From the outside it looked like n8n was “up”…
…but totally unreachable.
🧩 3. Two database containers were no longer running
Here’s the kicker:
My WordPress sites rely on two separate database containers.
Both of them had been running fine for days…
…but they didn’t have a –restart=always policy.
So when the proxy chaos hit and other containers restarted, the databases stayed OFF.
That’s why the error appeared:
❌ Error establishing a database connection
Not because the data was gone —
just because the container wasn’t running anymore.
🧩 4. One WordPress DB container disappeared from docker ps entirely
When you don’t see your DB container in docker ps?
Your heart stops.
You imagine the worst.
You start mentally drafting your resignation letter to yourself.
But the truth was:
• The DB container had exited gracefully
• The data volume was intact
• The container just needed to be restarted
Crisis averted…
after about 20 minutes of thinking I’d lost everything.
🛠️ How I Recovered the Entire Server
Here’s the short version of a very long night:
✔ Stopped Caddy entirely
No more port conflicts.
Nginx Proxy Manager took back control.
✔ Put n8n back onto the correct Docker network
Once n8n could talk to NPM again → 502 errors vanished instantly.
✔ Restarted the missing database container
That alone brought my main site back online.
✔ Enabled restart policies for all critical containers
Everything now survives a VPS reboot or container hiccup.
✔ Verified volumes
All WordPress and DB data were safe.
✔ Rebuilt n8n without Caddy
Now it sits comfortably behind NPM where it belongs.
✔ Confirmed my AI API key was working
(And confirmed that “Text-to-Workflow” is an Enterprise-only paid feature — I had no idea 🤦♂️)
🔥 Hard-Won Lessons for Anyone Self-Hosting n8n or WordPress in Docker
These are the takeaways I wish someone had told me yesterday:
1️⃣ Never let two reverse proxies fight over ports 80/443
One proxy only.
Full stop.
2️⃣ Every app behind a proxy MUST be on the same network
If your proxy doesn’t know where the container lives → instant 502.
3️⃣ Always set database containers to restart automatically
A simple missed flag caused hours of chaos.
4️⃣ Don’t panic when a container vanishes — check volumes first
The data is almost always still safe.
5️⃣ n8n will happily let you enter an AI API key
…but AI workflow generation is Enterprise only.
The UI does NOT explain this well.
6️⃣ Uptime monitors will save your butt
Ironically, n8n’s own workflow alerted me when everything died.
Which is… poetic?
Traumatic?
Both?
❤️ The Good News
Every website is back.
All data is intact.
n8n is running beautifully again.
Nothing was lost.
And now I have one heck of a story to share.
🧠 If you self-host, save this story.
And remember:
“It’s always the one line in a YAML file you didn’t think would matter.”