Hi @JoshuaS
Based on the shared sources, there isn’t a one‑to‑one description of your exact Fargate + ALB setup, but there are a few directly relevant patterns and pitfalls you can check.
1- Make sure Postgres is actually being used (no silent SQLite fallback): If any required DB env var is missing in the n8n container, n8n silently falls back to SQLite, which can cause bad performance and odd behavior under load. [Postgres fallback]
2- Tune DB and HTTP connection settings: Slow UI and “DB connections not being maintained” can be symptoms of connection exhaustion or timeouts. There are recommended env vars for improving stability under load: [HTTP timeouts; DB vars]
3- One user with severe performance issues was running with N8N_RUNNERS_ENABLED=true in a way that wasn’t appropriate for their deployment; disabling that and aligning execution mode with the actual architecture resolved most of their problems. [Runners not for prod]
4- ALB + stickiness: [Sticky sessions]
Key checks:
- Ensure only one “main” n8n instance is behind the ALB if you’re not in a proper multi‑main setup.
- If you do run multiple mains, keep stickiness enabled and consistent; flapping between mains can cause UI weirdness.
5- n8n’s own guidance for highly available AWS setups is:
- Shared Postgres * Shared Redis * One main n8n task (no scaling) for UI, cron, etc. * A scalable pool of workers * A scalable pool of webhook processes [[AWS scaling pattern]
(Best pattern for a highly reliable AWS host?); AWS hosting guide]
If you’re trying to do everything with a single Fargate service (main + all executions) and just scaling that, you may hit limits that look like “DB connections not maintained” or slow UI under load.