7. Source control: Community vs Enterprise, with honesty

Description

By the end of this lesson you will know, unambiguously, which version control and environment features n8n gives you for free and which ones only come in the paid plans, and you will have a clear criterion for deciding when it's worth paying. You'll be able to locate in the n8n 2.0 interface where the export/import you already know lives, and where the integrated source control surface shows up —locked or available depending on your plan. And, most importantly, you'll come away certain that everything this guide teaches can be done at zero cost with n8n Community.

This matters because there's a lot of confusion, and confusion costs money or costs opportunities. Some people believe "n8n doesn't version" and abandon the tool (the forum complaint from lesson 3). Others believe they need Enterprise to version and pay for it when they don't need to, or give up thinking they don't have the budget. Both beliefs are false. The truth has a nuance this lesson gives you in full: the built-in source control feature is paid, but the capability of versioning is free and is exactly what you're going to learn. Knowing how to tell the feature apart from the capability is what lets you decide with your wallet and not with fear.

Connection to the module: the previous lessons built up the problem (3, 4, 5) and the model that solves it (6). This lesson puts a price tag on that model: every piece of the edit → export → commit → review → promote cycle exists in two versions, a free one you do with your own hands and a paid one the tool does for you. It's also the lesson that defines the whole guide's default path —self-hosted Community at zero cost— and explains why that path is a pedagogical and economic decision, not a limitation. Lesson 8's project is done entirely in Community, without paying anything, like everything that follows.

Automatic or manual: the same capability, two forms

Think of the difference between a manual-transmission car and an automatic one.

Both do exactly the same thing: move the car, change gears as needed. In the manual, you operate the clutch and the stick: you decide when to shift, you do it with your hands and feet, you have total control, and the car costs less. In the automatic, the car shifts gears on its own: you press the gas and the machine handles the rest. It's more comfortable, smoother, and costs more —both to buy and to maintain.

Nobody would say a manual car "can't shift gears." It shifts perfectly; you're the one shifting it. The automatic transmission doesn't add a new capability —both cars make the same gear changes— it adds convenience: it does for you what you do by hand in the manual.

n8n and version control work the same way. The capability of versioning your workflows with Git exists in both editions. The difference is who operates the shifter:

• In Community (free), you operate the shifter: you export with the CLI, you make commits with Git, you manage environments with Docker. Total control, zero cost, a bit more manual work. It's the "manual." It's what this guide teaches.
• In Enterprise/Business (paid), n8n operates the shifter: there are buttons in the interface that push and pull to Git, that create environments, that sync everything. More comfortable, smoother, costs a monthly subscription. It's the "automatic."

Hold on to this distinction, because it's the one that dissolves all the confusion: the built-in source control feature is paid; the capability of versioning is free. When someone says "n8n doesn't have version control in Community," what they're really saying is "the car doesn't have an automatic transmission" —which is true and doesn't mean the car can't shift gears.

What Community does NOT give you (and what each absence means)

Let's be precise about which features live behind the paywall, because each one has a different story and a different consequence for this guide. With the usual warning: plans and their limits change, so confirm the current state on n8n's pricing page before making a money decision.

Paid feature	What it does	What we use instead (free)
Built-in source control (Git)	UI buttons for push/pull to a Git repo, environments per branch	n8n's CLI + Git by hand (Modules 2 and 3)
Native environments	dev/staging/prod managed by the tool	A Docker Compose per environment (Module 4)
External secrets	Reading secrets from an external manager (Vault, AWS, etc.)	Environment variables and .env files per environment (Module 4)
Variables	Project variables configurable from the UI	Environment variables via Docker (Module 4)
Multi-user and sharing	Several users on one instance, sharing workflows/credentials	The shared Git repo coordinates the team (Modules 2 and 3)

Let's go one by one, because understanding the absence is understanding why the free alternative works.

Built-in source control. This is the star feature and the one the lesson is named after. On the paid plans, n8n connects your instance to a Git repository and gives you buttons to send (push) your workflows to the repo and bring them (pull) back, all from the interface. What gets sent to the repo, according to the documentation, is the workflows, the tags, and stubs —empty skeletons— of credentials and variables; the real secrets don't travel to the repo, same as in the manual export. In Community, this automatic bridge doesn't exist, but you can build the same bridge by hand: you export with the CLI and commit with Git. The result in the repo is equivalent; what changes is that you press the buttons yourself. It's available on the Business and Enterprise plans.

Native environments. On the paid plans, the tool manages dev/staging/prod backed by Git branches: you switch environments and n8n syncs. In Community, you set up each environment as a separate instance with its own Docker Compose (Module 4). It's more manual —you spin up containers— but it gives you total, real isolation between environments, and it costs nothing. In fact, for learning, the manual path teaches you more: you actually see what an isolated environment is instead of the tool hiding it from you.

External secrets. This is the most exclusive one: reading secrets from a professional external manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and others) is available only on Enterprise, not even on the intermediate plans. It's a security convenience for large organizations that already have a corporate secrets manager. In this guide we handle secrets with environment variables and per-environment files, which is the free standard and perfectly solid for almost every case (Module 4).

Variables. Project variables configurable from the interface are paid. Instead we use environment variables via Docker, which do the same job —giving the workflow configuration values that change per environment— at no cost. n8n 2.0's restriction on how the Code node accesses environment variables is a separate topic covered in Module 4; for now it's enough to know there's a free path.

Multi-user and sharing. Community is, essentially, single-user: having several users on one instance and sharing workflows or credentials between them is paid. There's an important nuance here that the lesson 6 model resolves: you don't need multi-user on the instance to collaborate, because collaboration lives in the repository, not the instance. Two people can work on order-triage sharing the cumbre-automations repo on GitHub —that's free and it's where Git shines— each with their own dev instance. Coordination goes through the repo (source), not the instance (runtime), exactly as the model says. The paid multi-user feature is a convenience for teams that want to share the same instance; the shared repo solves collaboration without it.

Notice the pattern across all five: in no case does the absence of the paid feature stop you from doing the thing. In every case, there's a free path that does the same thing with more manual work. That's what it means for Community to give you "almost all of n8n": what's missing are conveniences and features for large organizations, not the capability to version, isolate environments, and test.

What you CAN do for free: everything in this guide

Let's flip the table around, because this is the message that matters. With n8n Community, free, self-hosted on your machine, you can do the system owner's entire cycle:

• Version your workflows with Git, with complete history, diff-based review, and rollback (Modules 2 and 3).
• Structure a documented repository, with credentials kept out and the JSON normalized for clean diffs (Module 3).
• Isolate real dev/staging/prod environments, each with its own credentials and encryption key (Module 4).
• Test in a sandbox with synthetic data, test credentials, dry runs, and assertions, even testing workflows with AI Agent nodes at zero cost with local models (Module 5).
• Promote across environments and roll back with a runbook, plus an automated check that validates the JSON on every change with free GitHub Actions (Module 6).

That's the guide's final project, the portfolio artifact from lesson 2, and it's produced entirely without paying for a subscription. The only "account" you're going to open is GitHub's, which is free for repositories like this one, and optionally an AI provider's for the AI Agent node —and in Module 5 we see how to test even that at zero cost with local models.

That's why this guide's default path is self-hosted Community at zero cost, and it isn't a concession for someone without a budget: it's the right decision for learning. The manual path forces you to understand each piece —what a commit is, what an isolated environment is, what a per-environment credential is— instead of pressing a button that hides it. When you finish, you won't just be able to do it for free; you'll understand what the paid version automates, which is exactly what makes you capable of evaluating it.

A free step worth taking: the registered Community edition

There's a nuance within "free" worth knowing about. n8n offers, at no cost, a registered Community edition: you still don't pay, but registering your instance with an email unlocks a few conveniences that plain Community doesn't include. As of this guide's writing, those conveniences include folders (for organizing your workflows), debugging capabilities in the editor, and custom execution data tracking —all useful, all free.

It's a step worth taking because it costs nothing and improves the experience, especially the folders once the number of workflows grows. To be clear, so there's no confusion: the registered Community edition still doesn't include built-in source control, native environments, or external secrets —those remain paid. It doesn't change anything this guide teaches; it just makes your free instance a bit more comfortable. Check what the registered Community edition includes in your version, because, like everything else, the list evolves.

Where all this lives in the n8n 2.0 interface

Let's locate the pieces on screen, so you know what you're looking at. With the usual warning: n8n's interface changes between versions; verify the exact locations and labels on your own instance.

The export/import you already know lives in the three-dot menu (⋯) of the open workflow, at the top right: that's where Download, Import from File, and Import from URL are (lesson 3). This is the free door through which you get the JSON out, and it's the one you're going to use in lesson 8's project. It doesn't depend on the plan; it's in Community.

The built-in source control surface shows up in the instance settings, not in the workflow menu. On a paid instance with the feature turned on, you'll see a Source Control section where you connect the Git repository and the push and pull buttons appear. In Community, that section either doesn't show up, or shows up as a locked feature inviting you to upgrade your plan. Seeing it locked isn't a problem: it just means you're looking at the "automatic" you're not going to use, because you're going to do the same thing with the CLI and Git.

Variables and native environments, when they exist (paid plans), also live in the instance settings and in project management. In Community you won't find them there, and that's fine: yours are going to live in your Docker Compose and .env files (Module 4), outside the n8n interface, which is where the source/runtime model says they should live anyway.

The conclusion of this tour: the only interface surface you need for this guide is the export/import menu, which is free. Everything else —commits, environments, secrets— you handle outside n8n, with free tools (Git, Docker), which is precisely what gives you the control and portability that a built-in button would take away.

Worked example: two teams, the same result

Let's compare two teams that achieve exactly the same thing —a versioned order-triage, with three environments and sandbox testing— through different paths.

Team Automatic (Business/Enterprise). They pay for a subscription. They connect their instance to GitHub from the Source Control section. To version a change, they press "push" and n8n sends the workflow to the repo. To promote, they switch environments in the interface and n8n syncs from the corresponding branch. They read their secrets from their corporate Vault with external secrets. What they get: convenience, fewer manual steps, and large-organization features (multi-user, RBAC). What they pay: the monthly subscription, which scales with the team.

Team Manual (Community). They pay nothing. To version a change, they export with n8n's CLI and run git commit (Modules 2 and 3). For environments, they have three Docker Compose folders —dev, staging, prod— each spinning up its own isolated instance (Module 4). Secrets live in per-environment .env files. They coordinate by sharing the cumbre-automations repo on GitHub. What they get: exactly the same result —versioned workflow, isolated environments, sandbox testing, rollback— plus a deep understanding of every piece. What they pay: nothing, in exchange for operating the shifter by hand.

What to expect if you compare the two GitHub repositories at the end: they're practically indistinguishable. Both have the versioned JSON, the commit history, the documented structure. An evaluator who opens either one sees a system owner. The difference isn't in the artifact; it's in how much convenience you bought to produce it. And for learning —and for a portfolio— the manual path isn't inferior: it's superior, because it proves you understand what the button automates.

The criterion: when it's worth paying

Let's close with what you actually need to decide. Paying for the edition with built-in source control, native environments, and external secrets makes sense in specific situations, and not in others. Here's the honest criterion.

It's worth paying when:

• The team is large and needs to share the same instance with multiple users, roles, and permissions (RBAC). Repo-based coordination works, but at a certain scale built-in access management saves real friction.
• The organization already has a corporate secrets manager (Vault, AWS Secrets Manager) and a policy requiring its use. There, external secrets isn't a convenience, it's compliance.
• The cost of manual time exceeds the cost of the subscription. If your team does dozens of promotions a day and every manual step costs expensive minutes, automating with the built-in feature can end up cheaper than doing it by hand.
• You need commercial support and guarantees that only come with a paid contract.

It's not worth paying when:

• You're learning. The manual path teaches more and costs nothing.
• You work alone or on a small team that can coordinate through a shared repo.
• Your secrets fit comfortably in .env files per environment, which is the case for the vast majority of projects.
• You want a portfolio artifact. The hand-built repo proves more capability than one generated by buttons.

The underlying rule: pay for convenience and for scale, not for capability. The capability —versioning, isolating, testing, promoting— you have for free. If you ever do pay, let it be a decision of "this saves me time" or "my organization requires it," made with your eyes open because you already know how to do by hand what the button does. Never pay out of fear that "you can't do it without paying," because you can, and this guide proves it to you module by module.

There's an advantage to the manual path that rarely gets named and is worth keeping in mind: portability. When you version with Git and the CLI, your repository and your knowledge don't depend on n8n. Git is the industry standard and works with any tool; Docker Compose spins up environments for anything, not just n8n. If your project migrates to another platform tomorrow, or if you work on a team that uses several, everything you learned transfers. The paid built-in feature, on the other hand, ties you a bit more to the way n8n does things: it's more convenient while you're on n8n, and less transferable the day you're not. This isn't an argument for never paying —the convenience is real— it's one more factor to weigh, and another reason why, for learning, the manual path is a better investment of your time.

Common mistakes

Believing "you can't version without Enterprise" and giving up (conceptual). What happens: someone reads that n8n's source control is paid, concludes versioning workflows requires a budget they don't have, and doesn't version anything. They stay on the builder's side because of a false belief. Why it happens: n8n's messaging —reasonably— highlights the built-in feature, and it's easy to confuse "the built-in feature is paid" with "the capability is paid." How to spot it: if your reason for not versioning is "I don't have Enterprise," you hold this belief. How to fix it: separate the feature from the capability. The capability of versioning is Git plus your exported workflows, and both things are free. The paid feature only saves you from pressing the buttons by hand. This entire guide is done in Community, for free; the mistake is not having known that.

Paying for Enterprise to get versioning when you don't need it (practical). What happens: the opposite mistake. A small team pays for an expensive subscription "to be able to version," when a free GitHub repo and the CLI gave them the exact same thing. Why it happens: it's easier to buy convenience than to learn the manual path, and the subscription feels like "doing it right." How to spot it: if you're about to pay for source control and your team fits in a small room, check whether you actually need the convenience or just need to learn how to do it by hand. How to fix it: learn the free path first (this guide). If, after knowing how to do it by hand, you conclude the convenience is worth the price for your scale, then it's an informed decision. Paying before knowing is paying out of fear.

Confusing "secrets don't travel to the repo" with "I don't need to worry about secrets" (conceptual and security-related). What happens: someone reads that source control (built-in or manual) only sends credential and variable stubs to the repo, not the secrets, and concludes secret management is solved on its own. But the secrets have to exist in every environment, and managing them —creating them, rotating them, keeping them different between dev and prod— is real work the repo doesn't do for you. Why it happens: "the secrets aren't in the repo" sounds like "the secrets are handled." How to spot it: if your plan for secrets is "the repo doesn't upload them, so it's done," you're missing the other half. How to fix it: understand that separating the secrets from the repo is only the first step; the second is managing them per environment, which is all of Module 4, whether you pay or not.

Treating this lesson's plans as fixed (practical). What happens: someone memorizes "source control is Business and Enterprise, external secrets is Enterprise-only" and repeats it as permanent truth, when n8n reorganizes its plans periodically. Why it happens: it's natural to treat a pricing table as stable. How to spot it: if you're about to make a money decision based only on what this lesson says, stop. How to fix it: n8n's pricing page is the source of truth about which feature is on which plan, and it changes. Use this lesson to understand the structure —paid feature versus free capability, convenience versus scale— which is stable, and verify the plan details against the official source before paying.

Exercises

Exercise 1 — Separate feature from capability. For each statement, say whether it's true or false and correct it if needed: (a) "In n8n Community you can't version workflows." (b) "n8n's built-in source control sends your secrets to the repository." (c) "To have dev/staging/prod environments you have to pay for Enterprise." (d) "External secrets is a convenience for organizations with a corporate secrets manager."

See solution

(a) False. Community doesn't have the built-in feature for source control, but the capability of versioning is there: it's done with n8n's CLI and Git, for free. It's the heart of this guide.

(b) False. Source control (built-in or manual) sends the repo the workflows, the tags, and empty stubs of credentials and variables —not the real secrets— which travel only as references, same as in the manual export (lesson 4).

(c) False. Native environments managed by the tool are paid, but you can have real isolated environments, for free, with a Docker Compose per environment (Module 4). "Paying" gives you convenience, not the capability.

(d) True. External secrets (Enterprise) lets you read secrets from managers like Vault or AWS Secrets Manager; it's useful when the organization already has that infrastructure and a policy requiring it. For most people, per-environment .env files are enough.

Why it works: all four statements are the most common confusions, and all of them dissolve with the same distinction —paid feature versus free capability. If you corrected them correctly, you're no longer going to give up believing "you can't without paying" or pay out of fear.

Exercise 2 — Decide for two scenarios. For each team, decide whether you'd recommend paying for the edition with built-in source control or staying on Community, and justify it in two or three sentences: (a) A person automating for their own business who wants a portfolio. (b) A company of 40 people with an 8-person automation team, that already uses HashiCorp Vault for all its corporate secrets and deploys several times a day.

See solution

(a) Community. They work alone, so they don't need multi-user or a shared instance; a GitHub repo gives them all the collaboration and history they need. They want a portfolio, and the hand-built repo proves more capability than one generated by buttons. Paying wouldn't add anything worth the cost. Clear recommendation: stay free and learn the manual path.

(b) Paying makes sense. A team of 8 that deploys several times a day pays expensively for every manual step, so the convenience of built-in source control can end up cheaper than the time. They already have Vault, and an organization that size usually has policies requiring the use of the corporate manager, so external secrets stops being a convenience and becomes compliance. And with 8 people, multi-user and roles (RBAC) save real friction. Here the "scale and convenience" criterion is met on all three fronts.

Why it works: the two scenarios are built to trigger both sides of the criterion. (a) meets none of the "worth paying" conditions; (b) meets three. The decision isn't ideological —"always free" or "paying is always more professional"— it's a calculation of scale, compliance, and time cost. Learning to make that calculation with your eyes open is the point of the lesson.

Exercise 3 — Explain it to your boss. Your boss tells you: "we need version control for the workflows, get a quote for n8n's Enterprise plan." Write the reply you'd give in four or five sentences, honest and without overselling, presenting both options and a recommendation.

See solution

One possible reply:

"We can version the workflows two ways. The expensive one: pay for the plan with built-in source control, which puts buttons in n8n to sync with Git and adds native environments and corporate secret management; it makes sense if we grow, if we need several users with roles, or if we're going to use our Vault. The free one: use Git and n8n's CLI on a GitHub repository, which gives us exactly the same versioning —history, review, rollback— with a bit more manual work and zero license cost. For our current size, my recommendation is to start with the free one: it gives us the full capability right now, it makes us understand the system, and if down the line the manual work starts costing us time, we migrate to the paid one with informed knowledge. Starting free doesn't close the door to paying later; starting by paying costs us something we might not need from the first month."

Why it works: the reply doesn't say "always free" or "we have to pay"; it presents both options with their criteria and recommends based on context, leaving the door open. It's the answer of someone who understands the difference between feature and capability, and who saves the company money without sacrificing capability. It's, again, a system owner's answer: it thinks about total cost, not just convenience.

Summary and next step

In this lesson you separated, once and for all, the paid feature from the free capability, with the transmission image: the manual car (Community) and the automatic one (Enterprise/Business) make the same gear changes; the automatic one just does for you what you do by hand in the manual. You saw which features live behind the paywall —built-in source control, native environments, external secrets, variables, multi-user and sharing— and what you use instead, for free, in every case: n8n's CLI and Git, a Docker Compose per environment, .env files, and the shared repo that solves collaboration without multi-user. You confirmed that everything this guide teaches is done in Community at zero cost, and that this default path isn't a limitation but the best way to learn, because it makes you understand what the paid version automates. You located in the n8n 2.0 interface where the free export/import lives and where the source control surface shows up —locked or not. And you came away with a clear criterion: pay for convenience and scale, not for capability, and never out of fear that "you can't without paying."

Before moving on you should be able to: explain the difference between the built-in source control feature and the capability of versioning; name three things Community doesn't give you and their free alternative; and give a criterion for deciding when it's worth paying.

With this you close the module's conceptual part. You now know what versioning is (1), why the market asks for it (2), why export/import isn't enough (3), what's in the JSON (4), what breaks when you move it (5), the model that organizes it all (6), and what each piece costs (7). All that's left is to put your hands to work: lesson 8 is the module's project. You're going to take order-triage —or any workflow of yours— export it for real from the editor, read its JSON field by field with the eyes lesson 4 gave you, and identify every field that would break when moved, using lesson 5's list. The deliverable —the exported JSON plus a portability risk note— is the first stone of the portfolio artifact, and the foundation the next five modules build on.

Resources

• Compare editions / Community edition features — n8n Docs — the official comparison of what Community gives you for free and what's paid; the source for verifying the current state of each feature.
• Source control and environments — n8n Docs — the paid built-in feature (Business and Enterprise); read it to know exactly what the "automatic path" automates.
• External secrets — n8n Docs — the Enterprise feature for reading secrets from external managers; the criterion for when you really need it is in this lesson.
• Choose how to use n8n — n8n Docs — the official guide for choosing between self-hosted Community, Cloud, and Enterprise; complements this lesson's decision criterion.
• n8n pricing — the pricing page, which is the source of truth about which feature is on which plan; check here before any money decision, because plans change.