The webhook stopped responding at 11pm on a Tuesday, midway through a client demo I had scheduled for 9am the next morning. The n8n instance was up, the workflow showed active, but POST requests were coming back with 502s and the logs were showing nothing, which is the worst possible combination because it means the problem is upstream of n8n rather than inside it. Turned out my nginx config had a proxy_read_timeout set to 60 seconds and the AI summarisation step was taking 75. One line. One missing line in a config file that the n8n self-hosting documentation does not mention, because the documentation assumes you have your reverse proxy set up correctly, which is a significant assumption.
I fixed it at 1am, tested it, went to sleep, and woke up to a message saying SAP had made a strategic investment in n8n.
I sat with that for a while.
SAP is not a company that makes speculative bets on developer tooling for fun. SAP is a company that has spent forty years building the infrastructure that runs procurement, HR, finance, and supply chain for most of the large enterprises on earth, and when SAP puts money into something, it is because someone inside that organisation has looked at their own product roadmap and decided that whatever they currently offer in that category is not going to be sufficient. That is what this investment is. It is SAP looking at the gap between what their automation tooling does and what their customers are starting to ask for, and deciding that the answer is not to build it internally.
That should concern every Workato and MuleSoft sales team that has a renewal coming up.
The enterprise automation market has been running on a particular model for about fifteen years. You sell a platform. The platform has connectors. The connectors are pre-built and certified and they cost money per connection and more money per task and significantly more money when you need to do something the connector was not designed for. The logic layer is visual but limited, and when a workflow gets genuinely complex, you hit a ceiling that the vendor will tell you to solve by upgrading your plan. I have been on the receiving end of that conversation on behalf of clients, and I have watched them sign the upgrade because the alternative was rebuilding months of automation work from scratch on something else.

n8n breaks that model in a specific way that matters at enterprise scale. The Code node is the obvious one, the ability to write actual JavaScript inside a workflow when the visual logic is not enough, but the deeper thing is the HTTP Request node and what it enables. Any API, any authentication pattern, any response structure you can handle with a bit of JavaScript in a Function node downstream. I have connected n8n to internal systems that had no official integration, that were not on any connector marketplace, by reading the API documentation and building the request manually. That is not possible in Zapier. It is technically possible in Make.com but the error handling gets messy fast and the execution logs are not granular enough when something goes wrong at step twelve of a fifteen-step scenario.
I migrated a client from Make.com to n8n eighteen months ago and the thing that nobody tells you about Make.com is that the Iterator module, which is how you loop over arrays in Make, has a fundamentally different execution model from how n8n handles items natively. In n8n, if a node returns five items, the next node runs five times automatically. In Make, you explicitly iterate. When you migrate, you do not just rebuild the workflow, you rethink the logic, and the places where you had an Iterator plus an Array Aggregator in Make become a single node in n8n and you have to trust that the item handling is doing what you think it is, which early in the migration you do not fully trust, because the documentation describes the behaviour but does not always show you what the data structure looks like at each stage. I spent an afternoon mapping the output of a Split In Batches node because the docs showed the concept but not the actual JSON schema that came through on the other side.
The SAP investment is interesting to me specifically because n8n has until now been a tool built from the perspective of someone who knows what an API is. The self-hosted deployment process, the webhook URL configuration, the credential management, these are not things that a non-technical user at a Fortune 500 company handles themselves. SAP’s interest suggests that n8n is going to need to become legible to a different kind of buyer, and that is the tension I am watching. The tool’s power comes directly from its technical flexibility. If the next eighteen months of product development are driven by what enterprise procurement teams want to see in a demo, the Code node does not go away, but it starts getting buried under layers of abstraction designed to make the platform feel safe to people who find the Code node threatening.
That is what happened to every other automation platform that took enterprise money and enterprise customers. The developers who made the platform good became a secondary audience.
n8n is the best workflow automation tool I have used for building things that are actually complex. Whether it stays that way now that SAP is at the table is the only question that matters.

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.

