AWS Fargate N8N

Has anyone had any luck deploying on ECS Fargate with n8n using the an ALB. we are having issues with database connections being maintained. The webui is slow to load. The ui is not always updating when exacuting and its generally a fustrating time overall. Right now, I have the fargate configured for 1vcpu and 4Gibs. This does not seem to be helping. We are running N8Ns with less resources and they are not having issues. The common ground here is AWS. The ALB is configured for sticky with 60 seconds being the time. I have done everything I Can think of and have thrown about all the different envirnment variables that I can to make this faster. Nothing seems to be helping. I am completely out of ideas. I have followed the self hosting guide in the docs to the letter. That has not helped. Just looking for things that maybe I am missing or tips that has helped others. Directions on a better platform.

Information on your n8n setup

  • n8n version: 2.4.8
  • Database (default: SQLite): postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker ECS
  • Operating system: fargate

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.

We have similar setup and it’s working fine

ALB + ECS (Fargate)

We’re using Postgres RDS for the database and EFS for the needed persistence

Maybe it’s the connection between your ECS and database?

This is almost certainly a WebSocket issue with your ALB, the UI symptoms you’re describing (slow updates, not reflecting execution status) are classic signs of WebSocket connections getting killed. Bump your ALB idle timeout way up from 60s to something like 3600, set N8N_PROXY_HOPS=1, and also drop EXECUTIONS_PROCESS=own since that setting was removed back in n8n 1.0.