I rebuilt 50% of n8n Business plan from scratch saving $30K/year

Some businesses could easily run 150K workflow executions per month. On n8n pricing, that adds up to around $30K/year. At that volume, pricing becomes huge, so I built the parts that mattered most from the Business plan: multi-stage environments (dev, staging, prod) and Git versioning.

The problem

If workflows are running in production, you cannot keep editing production directly. The normal software loop is needed: dev, staging, prod with backups.

The cost pressure

At the current public pricing, 40K executions is about $940/month. A 500K execution tier is about $5.9K/month. The exact savings depend on the number of executions, billing terms, exchange rate, and whether you negotiate.

At that usage level, the avoided cost is around $30K/year. That is what made this worth doing. It was not engineering for the sake of engineering.

The architecture

The setup has three environments: dev, staging, and production. Dev is where workflows are edited. Git is the source of truth between environments. Staging and production are deployed from branches, not manually edited from the UI.

Promotion flow

Dev Build, test, export workflows and credentials.

GitHub Review changes through branches and pull requests.

Staging / Prod Import, verify, activate workflows through scripts.

The runtime stack is Docker Compose: n8n, PostgreSQL, Redis, Caddy, workers, and a local MCP service. n8n stays the workflow runtime. The platform around it handles delivery and operations.

Git versioning without pretending JSON is beautiful

n8n workflows are exported as JSON. JSON diffs are not as nice as reviewing normal code, but they are still better than "trust me, I changed something in the UI."

The export script pulls workflows from dev, splits encrypted credentials by ID, commits the changes, and pushes them to the dev branch. From there, staging and production move through pull requests.

This gives the team a real history of changes and a review point before production. It is not perfect. It is much better than screenshots, Slack messages, or memory.

Credentials were the tricky part

Workflows are easy to move. Credentials are where people make dangerous mistakes.

The system keeps encrypted credentials in Git, split into one file per credential ID. On deployment, the script compares credential IDs in the repo with IDs already present in the target environment. It imports only new ones.

That means staging and production can keep their own credential values. A dev export does not overwrite production secrets by accident.

This is not a full external secrets system. It is a practical credential portability layer for this setup. If a client needs Vault, AWS Secrets Manager, or stricter separation, I would design for that from the start.

Deployments are boring on purpose

Staging deploys when the staging branch changes. Production deploys from main, with approval. The scripts pull the repo, start the right Docker profile, import missing credentials, upsert workflows, normalize export formats, and activate workflows marked active.

Deployment script responsibilities

Pull Checkout branch and fast-forward the server repo.

Import Add only new credentials, then upsert workflows.

Activate Use the n8n API for workflows marked active.

Verify Count exported workflows and credentials after import.

The point is not cleverness. The point is repeatability. If production is special, production will eventually be broken by a special manual step.

Scaling is an operations problem, not a pricing checkbox

The platform runs n8n in queue mode with Redis and workers. Workers have concurrency settings and memory limits. Different environments use different worker counts based on available RAM.

There is also resource-management documentation: binary data mode, payload limits, early OOM protection, Docker memory limits, and a future plan for autoscaled worker pools.

This is the part people skip when they self-host. They get n8n running, then production load teaches them what they forgot.

The business-plan alternative angle

n8n has paid features around source control, environments, workflow history, secrets, and operational visibility. I would not claim I rebuilt the entire Business plan. I did not.

But for us, maybe half of the value of Business was concentrated in the platform pieces: different environments, version control using Git, scaling options, and a safer release process. Those are exactly the parts I cared about and built around the open self-hosted version.

This platform replaced these outcomes for a specific internal deployment:

Git-backed workflow promotion instead of UI-only editing
Pull request review before staging and production
Basic workflow history through Git commits
Environment-specific credential protection through import rules
Queue workers and resource controls for heavier execution load
Runbooks for developers and operators

I would not sell this as "n8n Enterprise, but cheaper." That is sloppy and probably creates the wrong expectations. I would sell it as: I build the internal platform around n8n so your team gets the delivery process, security posture, and operational control you actually need.

I built this while working at Paraito.