The procurement email came through on a Friday afternoon and I almost missed what it actually said. A fintech client, mid-sized, regulated, the kind of company that has a dedicated person whose entire job is answering questions from auditors, had been running their customer onboarding automation on n8n Cloud for about eight months. The email was from their compliance lead. It was not asking whether n8n was reliable or whether the workflows could be extended. It was asking a single question: where, physically, does the data go when a webhook fires and a customer record moves through that workflow. Not approximately. Precisely.
That question ended the n8n Cloud conversation and started a different one.
I have had versions of that conversation four times in the past eighteen months, each time with a different company, each time arriving at the same place. The trigger is never performance and it is never cost, at least not at first. It is always data. Specifically, it is the moment when someone in legal, compliance, or security asks a question about automation infrastructure that a SaaS vendor’s terms of service cannot fully answer in the way a regulator will accept. Zapier’s answer to that question is a privacy policy and a data processing agreement. n8n Cloud’s answer is similar. The self-hosted answer is: your server, your network, your jurisdiction, your audit log, your answer.
The documentation for self-hosting n8n is better than it was two years ago but it still has a particular blind spot that I ran into personally and have watched other people run into since. When you follow the official Docker Compose setup on EC2, the WEBHOOK_URL environment variable defaults to localhost in a way that the docs describe as something you simply need to update to your external domain. What the docs do not tell you, not in the main setup guide, is that if you are running behind an Nginx reverse proxy and you have not explicitly set the X-Forwarded-Proto header to pass through correctly, your webhook URLs will be constructed over HTTP even when the incoming request arrived over HTTPS, and certain external services will refuse to send payloads to an HTTP endpoint. I found this at 11pm on a Sunday with a client’s Stripe webhook silently failing, every single event going into Stripe’s failed delivery queue, nothing in the n8n execution log because the request was never reaching the trigger. The fix was two lines in the Nginx config. The path to finding those two lines was about three hours.
The large companies doing this at scale are not self-hosting because they read a blog post. They are self-hosting because their security teams ran a threat model and their legal teams ran a data flow analysis and the conclusion was that putting production automation infrastructure on a third-party SaaS platform, where every credential, every payload, every intermediate data state passes through someone else’s compute, was not a risk profile they could sign off on. Zapier and Make.com are not bad products. They are products whose architecture makes certain compliance conversations impossible to close, and for companies operating under GDPR, HIPAA, SOC 2, or financial services regulation, impossible to close is the same as no.
The thing I did not anticipate when I started doing more enterprise work was how quickly the self-hosting conversation shifts from infrastructure to process. Getting n8n running on EC2 with proper SSL, a reverse proxy, and a mounted volume is a half-day job if you know what you are doing and a two-day job if you are learning it for the first time. That is not the hard part. The hard part is building the operational layer around it: the backup strategy for the n8n SQLite database or Postgres if you have migrated off SQLite, the process for rotating API credentials stored in the credential manager without breaking live workflows, the access control model for who can create and edit workflows versus who can only view executions, the alerting setup for when workflows fail silently in the way that Docker-hosted processes sometimes do when a container restarts and the volume is not mounted correctly and nobody notices for six hours because there is no external monitor watching the execution cadence.
LangChain gets talked about in the same breath as n8n when people discuss AI-powered automation infrastructure, and I want to be direct about this: LangChain is a framework for people who want to build agents in Python and are comfortable debugging chain execution traces. It is not an operational automation platform. I have used it. The abstractions are genuinely interesting and the things it makes easy are things that would take real time to build from scratch. The things it makes hard are understanding why something failed in production, because when a LangChain agent breaks mid-execution the error surfaces at the orchestration layer and the actual cause is often buried two abstraction levels down in a tool call that returned something the chain did not expect. Self-hosted n8n with an HTTP Request node calling the OpenAI API directly is less elegant and more debuggable, and debuggability is the thing that matters when a workflow fails at 2am and you need to know what happened.
The companies that have figured this out are not publishing blog posts about it. They are running automation infrastructure that they own, on compute they control, with credentials that never leave their network perimeter, and their compliance teams are sleeping better than yours.
Infrastructure you own fails in ways you can see and fix. Infrastructure you rent fails in ways you have to wait for someone else to explain.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.