Lessons Learned: Self-Hosting n8n for Multiple Clients

As we explore the possibilities of automation in the WebNutch community, it's essential to share our experiences and lessons learned. Recently, I had the opportunity to run n8n self-hosted for six paying clients on a single VPS, and I'd like to highlight some critical issues that arose during this process. One of the main challenges was that workflow executions competed for the same node thread, causing long-running workflows to block other clients' webhooks. To resolve this, I set EXECUTIONS_MODE=queue, ran a separate worker container, and used Redis as a mediator. This change significantly improved performance, with load doubling and latency dropping four times. However, I soon realized that the default n8n setup keeps every execution forever, resulting in a massive 11GB of logs for workflows that were no longer relevant. To mitigate this, I set EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE=72 hours for production, which has helped keep my setup organized. Another important consideration is that webhook URLs silently rotate when the container restarts unless you pin N8N_WEBHOOK_URL to your domain. Unfortunately, I learned this the hard way, losing three days' worth of leads for one client before I caught the issue. It's also crucial to back up the N8N_ENCRYPTION_KEY somewhere safe, as losing it can render all credentials across every workflow useless. When it comes to updates, it's best to avoid using the :latest version in production, as every n8n release can break at least one node. Instead, pin a version and test upgrades in a staging environment. Implementing error workflows has also been a game-changer, allowing me to catch silent failures and push them to a Slack channel for each client. This has saved me from potential disasters, such as Bland timeouts, Stripe signature mismatches, and Google auth expiries. Lastly, be aware that the default HTTP node timeout is 300s, which can cause issues with certain API calls. Bumping this value to 600s has resolved random failures on prompts that worked fine in direct API calls. If you're considering self-hosting n8n for multiple clients, I hope these lessons learned can help you avoid some of the common pitfalls. What are some other essential considerations when self-hosting n8n, and how can we improve our workflows in the WebNutch marketplace?