← Back
3 May, 2026

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. If you run 500K executions per month, you are looking at roughly $74K/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 technical part

From here, it gets more technical. The high-level idea is simple though: use dev for changes, staging for testing, prod for real execution, and Git as the source of truth between them.

The architecture

The setup has three environments: dev, staging, and production. Dev is where workflows are modified. Staging is only for testing before production. Production is never edited directly. GitHub sits between them as the promotion and deployment mechanism, but the environment flow is dev -> staging -> prod.

Promotion flow
Dev Build, test, export workflows and credentials.
->
Staging Test imported workflows before they reach production. Do not edit here.
->
Prod Deploy only after staging is verified. Never edit directly.

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

Git versioning

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

Git is the source of truth and the promotion mechanism. The JSON diffs mostly exist to detect that a workflow changed, not because people are supposed to review workflow JSON by hand.

Credentials were the tricky part

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.

Deployments

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, and normalize export formats.

One annoying n8n detail: when workflows are exported from dev and imported into staging or production, n8n deactivates them. So the deployment needs to detect which workflows were marked active in the export, then use the n8n API to activate them again after import.

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 to reactivate workflows marked active in the export.
->
Verify Count exported workflows and credentials after import.
Follow on