# Migrate from n8n to Open-Source Kortix: a Practical Guide description: Move open-ended work from n8n to Kortix, the open-source AI Operating System, with a concept map and a checked command sequence. Kortix is the open-source AI Operating System (AI OS) you move an n8n automation to when the job stops fitting a fixed flowchart and becomes open-ended work an agent has to finish on its own. Kortix runs each session in an isolated Linux sandbox, keeps the whole configuration as files in one git repo you own, and lands every change as a change request a person reviews. This guide maps n8n's concepts onto Kortix's, then gives you the exact commands to make the move. ## When to move off n8n n8n is a workflow automation platform that connects nodes on a visual canvas to automate a process. n8n's own docs define a [workflow](https://docs.n8n.io/build/understand-workflows) as "a collection of nodes connected together to automate a process," and an [execution](https://docs.n8n.io/build/understand-workflows/understand-executions) as one run of that workflow. The model is a strong fit for work you can draw in advance: the same steps, in the same order, every time. Keep that work on n8n. Move a job to Kortix when the work is open-ended. Research the accounts on a list. Reproduce a failing checkout and open a fix. Read a support thread and draft the reply. Chase an invoice. A Kortix agent plans, calls tools, and finishes a multi-step run; you review the result instead of wiring every branch. The [Kortix docs draw the same split](https://kortix.com/docs/compare): n8n for a fixed flowchart, Kortix for open-ended work an agent does on its own computer. What moves with you: schedules and webhooks become Kortix triggers, integrations become connectors, stored credentials become connector accounts brokered server-side, and your process logic becomes an agent and its skill files in the repo. What does not move: the visual canvas and n8n's per-item data structure. Kortix replaces the canvas with text you edit and diff. ## What maps cleanly and what does not Most of the move is a rename. The table lines up each n8n concept you already use against its Kortix equivalent. | n8n concept | Kortix equivalent | |---|---| | Workflow: connected nodes automate a process | Agent plus skills: markdown the harness runs | | Node: one step that acts on data | Connector or tool: one callable action | | Trigger node: starts a workflow | Trigger in kortix.yaml: cron, webhook, monitor | | Credentials: stored authentication for a node | Connector account: credential brokered server-side | | Execution: a single run of a workflow | Session plus change request | | Sub-workflow: a workflow called by another | Skill or subagent | | Canvas: the visual editor for the flow | Files in one git repo | Two differences are worth planning for. An n8n node runs in the order you wire it, while a Kortix agent chooses its tool calls at run time, so you describe the outcome and the agent picks the path. An n8n execution is a log of a run, while a Kortix session keeps a git branch named after the session and opens a change request, so the work outlives the sandbox and reaches your default branch only after review. ## Migrate step by step Every command below appears in the [Kortix docs](https://kortix.com/docs/quickstart). Install the CLI, scaffold a project, declare your connectors and triggers, run a session, then merge the change request. ### 1. Install and sign in ```bash curl -fsSL https://kortix.com/install | bash kortix login ``` `kortix login` opens your browser, then picks your account and a default project for you. Kortix ships a CLI for macOS and Linux; there is no Windows binary yet. ### 2. Create the project ```bash kortix init my-app cd my-app kortix ship ``` `kortix init` scaffolds a project directory whose `kortix.yaml` declares `kortix_version: 2` and runs the OpenCode harness. `kortix ship` creates the project in Kortix Cloud on its first run, then pushes your code; run it again any time to sync local changes. To adopt an existing repo, clone the project with `kortix projects clone ` instead of scaffolding. ### 3. Move integrations and schedules into kortix.yaml Connectors are declared in `kortix.yaml`, or in a file it lists under `imports:`. The [Kortix manifest reference](https://kortix.com/docs/project/manifest) lists every key. A manifest that wires one agent to all connectors and runs a weekday digest looks like this: ```yaml kortix_version: 2 default_agent: kortix agents: kortix: file: agents/kortix.md connectors: all secrets: all triggers: - slug: daily-digest type: cron agent: kortix cron: "0 0 9 * * 1-5" timezone: America/Los_Angeles prompt: | Summarize yesterday's commits. Open a CR against main. ``` You can add the same trigger from the CLI. `kortix triggers add` edits your local `kortix.yaml` only, and `kortix ship` pushes it: ```bash kortix triggers add daily-digest --type cron \ --cron "0 0 9 * * 1-5" --timezone America/Los_Angeles \ --prompt "Summarize yesterday's activity and save it as a daily note." kortix ship kortix triggers ls ``` A cron expression is a 6-field form: second, minute, hour, day, month, weekday. The schedule goes live once the manifest lands on your default branch. For an event-driven flow that n8n handled with a webhook trigger, set a signing secret and add a webhook trigger instead: ```bash kortix secrets set WEBHOOK_SECRET= kortix triggers add new-lead --type webhook \ --secret-env WEBHOOK_SECRET \ --prompt "A new lead arrived: {{ body.name }} ({{ body.email }}). Add it to the CRM." ``` Kortix builds the webhook URL from your project id and the trigger slug, verifies each request's signature against `WEBHOOK_SECRET`, then starts a session with the request body available in the prompt. The [Kortix trigger docs](https://kortix.com/docs/connect/triggers) cover webhook and monitor triggers as well as cron. ### 4. Start a session ```bash kortix sessions new --prompt "Build the login page" kortix sessions chat ``` `kortix sessions new` starts a session; the agent works in its own sandbox, on its own branch, so your project is untouched. `kortix sessions chat` attaches you to watch progress and reply. ### 5. Review and merge the change request ```bash kortix cr ls kortix cr diff 1 kortix cr merge 1 ``` Replace `1` with the CR number from `kortix cr ls`. `kortix cr diff 1` shows the unified patch; `kortix cr merge 1` merges it into your default branch. Nothing reaches that branch until you merge, and a session can never merge the change request it opened itself, so the agent cannot land its own work. ## What you gain Five things change after the move, and each one is concrete. 1. **One repo you own.** Agents, skills, memory, connector config and triggers are files, so you grep the whole company, diff any change, and roll any part of it back. 2. **Any model, your keys.** Pick the model per agent, per session or per message, bring your own API key, or point at your own OpenAI-compatible endpoint. 3. **Self-host anywhere.** Run the same stack on your laptop, a VPS, your VPC or on-prem with `kortix self-host start`, or use managed cloud. 4. **A human gate on every change.** Set each tool call to Allow, Ask or Block; an Ask holds the call until a person approves it, and merging stays a person's decision. 5. **A sandbox per task.** Each session boots its own isolated Linux machine with your repo and tools already on it, and thousands run in parallel with no crossover. Kortix also reaches the tools you already use: 3,000+ apps in a click, plus any MCP, OpenAPI, GraphQL or raw HTTP API, with credentials brokered server-side so they never enter the sandbox. See [Kortix](https://kortix.com). ## Rollback and safety The move is non-destructive. A session works on its own branch, and `kortix cr merge` is the only path to your default branch, so nothing changes in your live project until you approve it. Firing a trigger starts a session; it does not create a commit on its own. `kortix.yaml` is versioned in git like everything else. Kortix validates the manifest when you run `kortix ship` and again when a change request merges, so a broken manifest stops at review instead of reaching main. If a merge is wrong, revert the merge commit. If a change request is not ready, leave it open until you are. ## Where to go next - [n8n alternative home](/index.html) has the short answer and a comparison table. - [n8n vs Kortix](/n8n-vs-kortix.html) puts the two platforms side by side. - [Open-source n8n alternative](/open-source-n8n-alternative.html) covers the self-hosted path in full. - [More n8n alternatives](/best-n8n-alternatives.html) looks at the wider field. - The [FAQ](/faq.html) answers the common questions about the switch. If the work is open-ended and you want it to finish on its own, start here: [Try Kortix](https://kortix.com).