TopolearnEditing production directly is risky; environments let teams test changes before they go live.
Inside one instance, version history already lets you restore and compare versions (n8n can show a visual diff of two versions on the canvas). For teams this isn't enough: you want to try changes on a development instance and promote them to production only when tested. Each separate n8n instance is called an environment.
n8n connects instances through Git, the standard system for tracking changes to files. A Git repository (a shared, versioned folder, often on GitHub or GitLab) sits between the instances. Typically each environment is linked to its own branch (a separate line of changes in the repository).
What gets pushed to Git:
- Workflows you choose, with their tags.
- Credential stubs: only the name, type and ID, never the secret values. You create the real credentials separately on each instance, under the same names.
- Variable stubs (names only), tags, folders, projects and data table structures (not their rows).
Recommended flow is one direction: build on dev, push to Git, pull on production. Don't push and pull on the same instance. n8n can't detect conflicting edits to a workflow, so a pull can overwrite local changes.
Pushing sends the saved version, not the published one. After pulling on production, publish the workflows there.
Permissions: instance owners, admins and project admins can push; owners and admins can pull. Source control is a feature of the paid self-hosted and enterprise plans. You can also automate promotion through n8n's API.
Remember
- Environments are separate instances linked through a Git repository
- Credentials travel only as stubs; secrets are created per instance
- Promote one way (dev to Git to prod), then publish on production
Watch out for
- Pushing and pulling on the same instance and overwriting someone's unpushed changes.