The Series B announcement landed in my feed between a cold outreach LinkedIn message and a GitHub notification about a dependency I had been meaning to update for six weeks. Two hundred and eighty million dollars. Valuation north of four billion. Lead investors including names that do not usually attach themselves to developer tooling unless someone has run a very convincing model showing them what the TAM looks like when every operations team in every mid-market company eventually needs workflow automation infrastructure. I read the numbers, closed the tab, opened it again, and then went and checked whether my self-hosted instance was still running, which is the automation builder’s version of touching wood.
Jan Oberhauser built n8n in Berlin. He has not moved to California. This fact is mentioned in every profile written about him with a slightly breathless quality, as though the continued existence of a successful technical company in Europe is a phenomenon that requires explanation. It does not require explanation. What it does is make the VC interest more interesting, because the money flowing into n8n from Sand Hill Road is not flowing because Silicon Valley has suddenly developed a warm feeling toward European software development culture. It is flowing because the numbers make the geography irrelevant, and understanding why the numbers look the way they do tells you something useful about where automation infrastructure is actually going.
I want to explain what n8n looks like from inside the machine, because the funding coverage does not. I have a client whose workflow stack I migrated from Make.com to n8n fourteen months ago. The migration took three weeks longer than I told them it would, partly because Make’s iterator module has no direct n8n equivalent and I had to rebuild that logic using a Code node with a manual loop and a Set node to maintain state across iterations, and partly because two of their Make scenarios were using the built-in Make data store in ways that assumed persistence between executions that n8n does not handle the same way. Those were solvable problems. They were not documented problems. I solved them by reading source code and asking in the Discord server, which is not a migration methodology I would recommend to anyone but which reflects the actual state of documentation for edge cases in both tools.
What that client is paying now, compared to what they were paying Make.com, is about thirty percent of the previous cost. The workflows are more complex than what they had before. The execution volume is higher. The cost went down because self-hosted n8n does not charge per operation, and their operation count, which Make was billing against, had been growing at a rate that was starting to produce awkward conversations in their finance reviews. That thirty percent figure is why VCs are interested. Multiply it across a few thousand companies making the same calculation and the revenue potential is obvious.
The open source model is the part that takes some investors longer to get comfortable with. The code is there, anyone can run it, so where does the money come from. The answer is the same answer that has worked for GitLab, HashiCorp, and Elasticsearch, which is that running software and operating software are different things, and the gap between them is wide enough that most organisations will pay for someone else to mind it. n8n Cloud is the managed version. The enterprise tier adds SSO, audit logging, and the kind of access control that a compliance team requires before they will allow a workflow tool to touch production systems. I have set up the self-hosted version enough times to tell you that the managed offering is not lazy money. Running n8n at scale with proper queue configuration, worker management, and database maintenance is real infrastructure work, and the organisations buying the enterprise tier are not buying it because they could not figure out the Docker Compose file. They are buying it because they have calculated that their engineering time costs more than the subscription.
LangChain raised a hundred million dollars at a billion dollar valuation on the back of demos that showed agents doing impressive things in controlled conditions. I have tried to put LangChain agents into production workflows twice. Both times the failure mode was the same, which is that the agent reasoning loop is opaque enough that when something goes wrong, and something always goes wrong, the debugging experience is reading a chain of LLM outputs trying to reconstruct what decision was made and why. In n8n, when a workflow fails, the execution log shows me exactly which node failed, what the input was, what the output was, and what the error message said. That is not a philosophical advantage. That is the difference between a two-minute fix and a two-hour debugging session.
The Berlin thing matters in one specific way that the funding profiles do not quite capture. n8n was built by someone who was not optimising for a Series A timeline. The early architecture decisions, the ones that made self-hosting viable and the open source version genuinely capable rather than deliberately crippled, were made by someone who was trying to build a tool that worked rather than a tool that demonstrated traction. Those decisions are expensive to reverse. They are also why the tool is now worth four billion dollars, because the organisations willing to pay enterprise pricing for automation infrastructure want something that works at the foundation, not something that was designed around a pitch deck.
The money will not change what n8n is. The question worth watching is whether it changes what n8n decides it needs to become.
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.