The full n8n source lives in the open on GitHub and GitHub itself plugs straight back into n8n. This guide covers the repository, installing from source, Docker, self-hosting, the GitHub node integration, building GitHub AI agents, backing up your workflows, and the best community templates.
The canonical repository is github.com/n8n-io/n8n. It holds the complete product editor, server, node library, and the AI stack and it's one of the most-starred automation projects on all of GitHub, with well over 100,000 stars and an extremely active contributor base.
n8n is distributed as fair-code under the Sustainable Use License. In everyday terms: you can read every line, run the whole thing on your own hardware for free with unlimited workflows and executions, modify it, and use it commercially inside your own organization. The one boundary is that you can't repackage it and resell it as your own hosted automation service. For solo builders, startups, agencies, and internal platform teams, that's effectively unrestricted.
n8n ships as a monorepo managed with pnpm workspaces. Rather than one giant codebase, it's split into focused packages the workflow editor front end, the core execution engine, the CLI, and the enormous nodes-base package that contains the integration nodes. That structure is what lets thousands of contributors add or improve individual nodes without touching the engine.
Building from source is the right path when you want to contribute, develop custom nodes, or run unreleased code. For everyday use, the npm package or Docker image (both produced from this same repo) are faster pick a tab below.
Source builds need Node.js LTS, Git, and pnpm. The npm and Docker tabs are the quick routes.
Choose your route
Once you've cloned the repo, the monorepo handles the rest with a few pnpm commands. Install Node.js (v18, 20, or 22) and the pnpm package manager first, then:
# 1 clone the repository git clone https://github.com/n8n-io/n8n.git cd n8n # 2 install all workspace dependencies pnpm install # 3 build every package pnpm build # 4 start n8n pnpm start
When it boots, the editor is served at http://localhost:5678. If you intend to develop, use pnpm dev instead of start to get live rebuilds while you edit.
Don't need source? The simplest install is npm install n8n -g then n8n start, or a no-install trial with npx n8n. Both pull the package that's published from this exact repository.
The Docker image is built from the GitHub repo and published as docker.n8n.io/n8nio/n8n (mirrored on Docker Hub). Docker is the single most popular way to run n8n because it's portable, isolated, and repeatable.
Create a named volume so your workflows and encryption key survive restarts, then launch:
docker volume create n8n_data docker run -it --rm --name n8n -p 5678:5678 \ -v n8n_data:/home/node/.n8n \ docker.n8n.io/n8nio/n8n
Open http://localhost:5678 and create your owner account. The workflow data is stored in an SQLite database inside the mounted volume.
Critical for Docker users: the encryption key lives in /home/node/.n8n. If that volume is lost, stored credentials can no longer be decrypted always mount a persistent volume and back it up.
When you outgrow a single container and SQLite, Docker Compose lets you describe a full stack: n8n plus PostgreSQL for durable storage, and optionally Redis to enable queue mode for scaling across multiple worker processes. A production deployment typically adds a reverse proxy (Caddy or Nginx) for HTTPS and sets environment variables for the database connection, the public webhook URL, and authentication.
If your goal is AI, clone n8n's purpose-built repo, github.com/n8n-io/self-hosted-ai-starter-kit. It's a Docker Compose template that stands up a complete local AI environment in one command, bundling self-hosted n8n, Ollama (local LLMs), Qdrant (vector store), and PostgreSQL:
git clone https://github.com/n8n-io/self-hosted-ai-starter-kit.git cd self-hosted-ai-starter-kit docker compose --profile gpu-nvidia up
There are alternate profiles for CPU-only and Apple Silicon machines, so it runs on almost any hardware with everything kept private to your own box.
Because the whole project is on GitHub under a fair-code license, self-hosting is free and gives you total control of your data, infrastructure, and logic. Here's what a robust self-hosted setup involves.
Most self-hosters run the Docker image on a small Linux VPS providers like DigitalOcean, Hetzner, and Contabo all work well, and n8n's modest requirements mean even a low-tier instance is plenty to start. From there you can move to Docker Compose with PostgreSQL and queue mode as your volume grows. Running directly from a source build is also possible and is the norm for contributors and custom-node developers.
~/.n8n and migrate to PostgreSQL for durability at scale.WEBHOOK_URL so inbound webhooks resolve to your public domain.--restart unless-stopped (or the Compose equivalent) so n8n recovers after reboots.Cloud vs self-host: if you'd rather not manage servers, updates, and backups, n8n Cloud is the official managed option on a subscription. The common 2026 pattern is to start managed to learn, then self-host once data-residency needs or execution volume make ownership worthwhile.
Beyond hosting the code, GitHub is also a first-class integration inside n8n. Two built-in nodes let your workflows both react to and act on GitHub.
Automate work in GitHub: create, update, delete and edit files, repositories, issues, releases, and users and integrate GitHub with your other apps.
Start workflows from repository events via webhooks: pushes, issues, pull requests, releases, commit comments, check runs, and a wildcard "any event."
Need an endpoint the node doesn't cover? Reuse your GitHub credential in the generic HTTP Request node and call any part of GitHub's REST API.
The GitHub action node maps to common GitHub operations. It can create or edit files in a repo (handy for committing generated content), open and update issues, manage releases, fetch repository data, and more. When a particular API endpoint isn't exposed as a built-in operation, you fall back to the HTTP Request node using the same stored credential so nothing in the GitHub API is truly out of reach.
The trigger node registers a webhook on your repository (or organization) and fires your workflow when something happens. Supported events include code pushes, branch and tag creation, issues and issue comments, pull requests, releases, commit comments, and check runs and check suites. There's also a wildcard option that fires on any event, plus organization-level hooks for team changes. This is what powers automations like "label every new issue," "notify Slack on release," or "kick off CI-adjacent tasks on push."
Authentication uses a GitHub personal access token or OAuth2. n8n recommends a classic personal access token, since GitHub's fine-grained tokens are still in beta and can't reach every endpoint. OAuth2 works with the GitHub and GitHub Trigger nodes (but not the GitHub Document Loader, which is token-only). To create one, verify your email with GitHub, open Settings → Developer settings → Personal access tokens, generate a token with the right scopes (for example repo), and paste it into the n8n credential.
| Node | Direction | Auth | Typical use |
|---|---|---|---|
| GitHub | n8n → GitHub (action) | PAT or OAuth2 | Commit files, manage issues/releases |
| GitHub Trigger | GitHub → n8n (event) | PAT or OAuth2 | React to pushes, PRs, issues |
| GitHub Document Loader | GitHub → AI (read) | Token only | Feed repo content to an AI agent (RAG) |
| HTTP Request | n8n ↔ GitHub API | Predefined credential | Any uncovered endpoint |
This is where n8n shines: the GitHub node can be attached to an AI Agent node as a tool, letting a language model decide when and how to act on your repositories. The result is an autonomous assistant that reasons over GitHub events and takes real actions.
n8n's AI subsystem is built on the LangChain framework, with the AI Agent node at the center. The agent connects to sub-nodes that give it capabilities: a language model (OpenAI, Anthropic, a local model via Ollama, and others), conversation memory, and tools. Crucially, the GitHub node is documented as usable as an AI tool when wired this way, many of its parameters can be filled in automatically or driven by the model, so the agent can choose which repo to write to, which issue to comment on, or what release notes to publish.
For accurate, cite-able answers about a codebase, retrieval-augmented generation is the technique to reach for. Instead of fine-tuning a model, you load repository content into a vector database; when someone asks a question, the agent retrieves the most relevant files or passages, augments the prompt with them, and generates an answer grounded in your real source. This dramatically reduces hallucinations and keeps the agent current as the repo changes.
Tip: resist the urge to use an agent for everything. Use the AI Agent node when you genuinely need reasoning and dynamic tool selection (like triage). For fixed logic "on release, post to Slack" a plain GitHub Trigger plus a Slack node is faster, cheaper, and more predictable.
“n8n GitHub tool” can mean two related things, and both are worth knowing.
In an AI workflow, the GitHub node is literally a tool you hand to an agent. You connect it to the AI Agent node's tool input, and from then on the model can invoke GitHub operations on demand reading a file, opening an issue, creating a commit choosing parameters based on the conversation. This is the mechanism behind every example in the AI Agent section above.
Separately, the community has published open-source tooling on GitHub that wraps n8n's REST API for things the core product handles differently. Examples include CLI utilities that export, version, and sync workflows, credentials, and folder structures with Git, and browser extensions that add push/pull version control to the editor. These live in their own repositories and are independent of the official project vet them as you would any third-party tool, especially around credential handling.
Security note: never commit raw credentials, .env files, or your encryption key to a Git repository. n8n's own source-control feature pushes credential stubs, not secrets, for exactly this reason.
Your workflows are code JSON that encodes real business logic and can break like anything else. Treating them as code means versioning them, and GitHub is the natural home. There are three approaches, from official to do-it-yourself.
n8n includes Git-based source control that links your instance to a Git repository (such as GitHub) to support multiple environments backed by Git branches. You push to send workflows, tags, and credential/variable stubs to Git, and pull to load them back into an instance. This is the cleanest path for teams running development, staging, and production, and it's part of n8n's higher-tier (Enterprise) offering. Because it stores stubs rather than secrets, your sensitive credentials stay protected.
The most accessible approach and one that works on n8n Cloud too is to build a workflow that backs itself up. A scheduled trigger runs daily, the n8n node (or REST API) exports all workflows as JSON, the workflow checks GitHub for existing backup files, then creates new files or updates changed ones via the GitHub node. Mature versions store files in a tidy structure (for example YYYY/MM/ID.json), detect changes to avoid duplicate commits, and even send a Slack notification on success or failure. Ready-made versions of this exist as official templates.
On a self-hosted box you can script it directly with n8n's CLI. Export every workflow to separate JSON files, commit, and push then schedule it with cron:
# export all workflows as separate JSON files n8n export:workflow --all --separate --output=/path/to/n8n-workflows # commit & push to GitHub git add . && git commit -m "Daily backup: $(date +'%Y-%m-%d')" && git push origin main
Inside Docker, run the export through docker exec against your container. Schedule the script with a cron entry (for example, 2 AM daily) and you get a versioned, auditable history of every change. Never commit .env files or secrets alongside the workflows.
One-directional vs two-way: a basic backup only goes n8n → Git. Adding the reverse direction (pull/import) gives you true disaster recovery and lets you sync multiple instances from a single source of truth.
You rarely need to start from a blank canvas. Between n8n's official template gallery and community collections on GitHub, there are thousands of ready-to-import workflows including many for GitHub itself.
Every template is just JSON. To use one, copy its JSON (or download the file), open n8n, and use the editor's import option to paste or load it onto the canvas. Then wire up the credentials it needs a GitHub personal access token, an n8n API key, an LLM provider key, and so on and adjust any configuration nodes (repository owner, repo name, schedule). A typical GitHub-backup template takes about ten to fifteen minutes to configure once your credentials are ready.
Vet before you run: community templates and third-party repos are contributed by many authors. Read what a workflow does before importing it, and be especially careful with anything that touches credentials or makes outbound requests.
github.com/n8n-io/n8n. It contains the full product as a pnpm monorepo and is distributed as fair-code under the Sustainable Use License.pnpm install, pnpm build, and pnpm start. For everyday use, the npm package (npm install n8n -g) or the Docker image are quicker both are built from the same source.n8n export:workflow --all --separate) committed via cron. Never commit secrets or .env files.