I was scrolling through the n8n community forum at an hour that I cannot justify professionally when I saw the Mercedes-Benz slide. Someone had posted a screenshot from a conference deck, the kind of deck that gets photographed by three people in the front row and circulated in Slack channels for a week before anyone writes about it properly. The slide said that Mercedes-Benz was rolling out n8n across their global operations. Not piloting. Not evaluating. Rolling out. I read it twice, put my phone down, picked it back up, and read it again. Because if you have spent any real time inside n8n, not the demo, not the cloud trial, but actually running it in production with real data and real failure modes, the first thing that sentence produces is not excitement. It is a very specific technical question, which is: how.
Not how in the dismissive sense. How in the genuine sense of wanting to understand what an enterprise automation stack at that scale actually requires, because the gap between a self-hosted n8n instance running ten client workflows on a t3.medium and a global deployment supporting an organisation with a hundred and fifty thousand employees and manufacturing operations across three continents is not a gap you close by upgrading your EC2 instance size.
I have run n8n hard enough to know where it starts to show pressure. The execution queue gets interesting when you have high-volume concurrent workflows all trying to write to the same database tables. The credential management system, which is fine at the scale of one person or a small team, becomes a governance problem the moment you have multiple departments with different access requirements and someone from compliance asking you to produce an audit trail of which workflows accessed which credentials and when. The webhook handling is solid until you are processing thousands of inbound events per minute and you need to think seriously about queue depth, execution timeout tuning, and what happens to your database when a downstream API goes down and forty thousand queued executions start retrying simultaneously.
None of those problems are unsolvable. They are just not problems that the documentation addresses, because the documentation is written for the person setting up their first instance, not for the person designing a deployment that needs to survive a production incident at 2am in Stuttgart while the European shift is running and the American shift is about to start.
What Mercedes-Benz is almost certainly running is not the Docker Compose setup from the quickstart guide. Enterprise n8n deployments at that scale mean a queue-mode configuration with a Redis broker handling execution distribution, multiple worker instances so that no single process is a single point of failure, an external PostgreSQL instance that is actually managed and backed up rather than running in a container alongside everything else, and a deployment pipeline that can update n8n across multiple instances without taking the whole thing down. The n8n documentation covers queue mode. It covers it in a way that is technically accurate and practically incomplete, which is the specific combination that costs you a day when you are trying to implement it for the first time. The part it does not adequately explain is how to handle the transition of existing workflows from regular mode to queue mode without losing execution history, and what happens to long-running workflows that are mid-execution when you restart the workers. I found the answers to both of those questions in GitHub issues rather than docs.
The thing that makes n8n the credible choice for an organisation like Mercedes-Benz is not the node library or the AI integrations, though both matter. It is the self-hosting model. When I was migrating a client from Make.com, the conversation that eventually ended Make.com’s involvement was about data residency. The client had contractual obligations about where certain data could be processed and stored, and Make.com’s answer to that question was essentially that their infrastructure was in specific AWS regions and here is the documentation. That is fine for a lot of use cases. It is not fine when your legal team is asking which jurisdiction the data traverses during processing, because the answer with any SaaS automation tool is complicated and usually involves more regions than the marketing page implies. With self-hosted n8n, the data stays where you put it. That is the sentence that closed the conversation.
Mercedes-Benz running n8n globally also means they have almost certainly built internal tooling around it that does not exist in the public community. Custom nodes for internal systems. Deployment automation that manages workflow versioning across environments. Probably a wrapper around the n8n API for programmatic workflow management that their platform team built because the native options were not quite what they needed. This is what enterprise adoption of an open source tool actually looks like. The tool is the foundation, not the finished product.
CrewAI released a blog post last month about enterprise AI agent deployments that I read carefully and came away from feeling like it had been written by someone who had not personally tried to explain to a client why their multi-agent workflow had produced a confidently wrong output and then retried itself six times before anyone noticed. LangChain has the same problem at a different layer of the stack. n8n is not an AI agent framework. It is a workflow orchestration tool that can call AI APIs, which is a more honest description of what most production AI automations actually are.
Mercedes-Benz choosing n8n is not a signal that n8n is easy. It is a signal that the alternative was handing your automation infrastructure to a vendor whose pricing, data handling, and feature roadmap you do not control.
At that scale, that trade-off is not even close.
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.