Self-hosting n8n for production AI automations without babysitting a server

A developer outlined a production checklist for self-hosting n8n AI automation workflows, covering a stable HTTPS webhook URL, a reverse proxy with auto-renewing certificates, Postgres instead of SQLite, a fixed N8N_ENCRYPTION_KEY, execution-data pruning, tested backups, planned updates and monitoring. The writeup stresses that AI workflows differ from simple cron jobs because they are triggered externally via webhooks, hold valuable API credentials and are user-facing, so an outage is immediately visible to customers.

You built an n8n workflow that matters. Maybe it is an AI agent that answers customers on Telegram, a pipeline that summarizes every support ticket with Claude, or an automation that turns new leads into enriched CRM records. It works beautifully on your laptop. Then someone asks the obvious question: "Can we turn it on for real?" That is the moment n8n stops being a tool and becomes a service. Services have to be up at 3 AM, reachable from the internet, backed up, patched and watched. This article walks through what production n8n actually needs, then shows the fastest way to get all of it running without turning one engineer into a part time sysadmin. A classic n8n workflow that copies rows between two apps once an hour is forgiving. If it misses a run, it catches up. AI workflows are different in three ways. They are triggered from outside. A Telegram bot, a Slack app, a form or a payment provider calls your n8n through a webhook. That means n8n needs a public HTTPS address that is always reachable. Telegram, for example, only delivers updates to HTTPS endpoints. They hold valuable credentials. Your Anthropic or OpenAI key, your CRM token, your database password. n8n encrypts stored credentials with an encryption key, and anyone with the database and that key can use every one of them. They are user facing. When an AI agent answers customers, a five minute outage is a customer waiting for a reply that never comes. So production n8n is less about n8n and more about everything around it. Webhooks need a stable HTTPS URL, and n8n needs to know that URL so it can register webhooks correctly. You set it with the WEBHOOK URL environment variable: WEBHOOK URL=https://n8n.yourcompany.com/ Behind that you need a reverse proxy, a certificate, and automatic renewal. An expired certificate silently breaks every webhook at once. Out of the box n8n stores everything in SQLite, which is perfect on a laptop. For production, the n8n docs recommend Postgres, so the database can handle concurrent executions and be backed up and restored properly: DB TYPE=postgresdb DB POSTGRESDB HOST=postgres DB POSTGRESDB DATABASE=n8n DB POSTGRESDB USER=n8n DB POSTGRESDB PASSWORD=<strong password n8n generates an encryption key the first time it starts and uses it to encrypt every stored credential. Set it explicitly so it never changes between deployments: N8N ENCRYPTION KEY=<long random value, stored somewhere safe If you lose this key, every saved credential becomes unreadable. If it leaks along with your database, every credential is exposed. It needs to be backed up, but separately and carefully. Every execution stores its input and output data. AI workflows pass large payloads around, full documents, long model responses, so the database grows fast. Turn on pruning: EXECUTIONS DATA PRUNE=true EXECUTIONS DATA MAX AGE=168 That keeps a week of history, enough to debug, without letting the disk quietly fill up. Back up the Postgres database on a schedule, keep copies off the server, and keep the encryption key with them. Then do the part most teams skip: restore a backup onto a fresh instance and check that your workflows and credentials come back. A backup you have never restored is a hope, not a backup. n8n ships updates frequently, with new nodes, AI features and security fixes. Staying current matters, especially for an internet facing service. Each update should be a planned step with a database backup right before it and a way back if something breaks. You want to know when the instance is down, when the disk is close to full, when memory spikes and when executions start failing, before a customer tells you. That means health checks, metrics, alerts and someone who receives them. A firewall that only exposes what's needed, protection against floods of traffic, and OS security patches applied on time. An automation server with your AI keys and CRM credentials is exactly the kind of target worth protecting properly. None of the items above is hard on its own. Together, they are an ongoing job: certificates, Postgres, backups, restore tests, updates, pruning, monitoring, firewall rules, OS patches. And it doesn't end, because n8n, Postgres and the operating system all keep releasing updates. In most teams this lands on whoever set n8n up first. It works until that person is on holiday during an incident, or the one undocumented step gets skipped during an upgrade. The goal is to keep the parts you care about, your workflows, your agents, your data, and hand off everything else. Elestio https://elest.io/ runs exactly that layer. You pick n8n from a catalog of 400+ open source templates , choose where it runs, a major cloud provider and region of your choice, and it deploys onto a dedicated instance that is yours. From there, the production checklist above is already handled: You keep full root access. It's your instance and your data, exportable any time. Billing is a flat fee on top of compute, not per workflow, per execution or per user, so adding more automations and more team members doesn't grow the bill. That last point matters for AI automations in particular. Agents tend to run many executions, and per execution pricing on hosted automation platforms grows quickly as usage takes off. With a dedicated instance, your cost is the instance, however many times your agent runs. If you already built workflows locally, moving them is quick: n8n export:workflow --all --output=workflows.json Activate, send a test message, and your automation is live on infrastructure that is backed up, patched and watched. Pick n8n from the catalog, choose a region, and Elestio provisions it with HTTPS, backups, monitoring, updates and a firewall already configured. No reverse proxy to set up, no backup script to write, no certificate renewal to remember. Most teams have their first app running in under ten minutes. You can also go straight to the n8n template: fully managed n8n on Elestio https://elest.io/open-source/n8n . AI automations are only as good as the server they run on. HTTPS, Postgres, a protected encryption key, pruning, tested backups, updates and monitoring are what turn a working workflow into a service you can rely on. Elestio handles that whole layer from day one, so your time goes into building better workflows and agents, not keeping the server underneath them alive. I'm Amit Shukla, a software engineer working across DevOps, cloud and applied AI. Behind the Stack is where I write up the things I learn the hard way, with working code and honest tradeoffs. If this saved you some time, a reaction or a comment helps more people find it.