---
title: "Porting the n8n Frontend From Vue to Next.js: Don't (And What to Do Instead)"
description: "n8n's editor is a large Vue 3 application under the Sustainable Use License, and that licence decides this question before the architecture does. Here is what the frontend actually is, why a port is rarely the answer, and the four things people really want — each with a simpler route."
canonical: "https://www.razi.pro/blog/porting-n8n-frontend-vue-to-nextjs"
date: "2026-09-07"
tags: ["n8n", "Next.js", "Vue", "Architecture", "Automation"]
source: "razi.pro"
---

# Porting the n8n Frontend From Vue to Next.js: Don't (And What to Do Instead)

Before you read on: what stops you forking n8n's workflow editor into your React product?

Most people answer "it is a lot of Vue". That is true and it is not the real obstacle. The real obstacle is in the first ten lines of the package manifest, and it decides the question before you have looked at a single component.

I will put the verdict at the top so you get it for free: a full port is almost never worth attempting, and for a commercial product it is usually not permitted. Here is the reasoning, and then the four things people actually want when they ask this.

## What n8n's frontend actually is

The editor lives at `packages/frontend/editor-ui` in the n8n monorepo, as the package `n8n-editor-ui`. It is a Vue 3 application: `vue`, `pinia` for state and `vue-router`, all resolved through the monorepo's dependency catalog.

The canvas — the part you actually want — is not bespoke. It is built on Vue Flow, which appears as an explicit set of dependencies:

    @vue-flow/core          1.48.0
    @vue-flow/background    1.3.2
    @vue-flow/controls      1.1.3
    @vue-flow/minimap       1.5.4
    @vue-flow/node-resizer  1.5.0

(Versions as of writing; check the manifest for current ones.)

That detail matters more than it first appears, and I will come back to it.

The rest of the application is the part that is genuinely hard to move: the node type registry, credential handling, the expression editor, execution and run data views, and a large surface of state that couples tightly to n8n's REST API. The canvas is the visible 10%. The other 90% is why a fork stops being fun in week two.

## The licence decides this before the architecture does

Here is the thing almost every discussion of this question skips.

`n8n-editor-ui` declares its licence as `LicenseRef-n8n-sustainable-use`. That is n8n's Sustainable Use License, not MIT and not Apache. It reads, in the repository's own LICENSE.md:

> You may use or modify the software only for your own internal business purposes or for non-commercial or personal use.

And:

> You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.

Read those two sentences against what you were planning. If the plan is "fork the editor, rebrand it, ship it inside the product we sell", the licence does not permit that, and no amount of rewriting Vue into React changes the fact — a React rewrite of a Sustainable-Use-licensed codebase is a derivative work of it.

There is a third clause worth knowing even for internal use:

> If you modify the software, you must include in any modified copies of the software a prominent notice stating that you have modified the software.

So the honest decision tree is short. Internal tooling for your own company: permitted, and now you can weigh the engineering on its merits. A product you sell: this is a licensing conversation with n8n, not a porting project.

> **The sanctioned route, and its catch.**
> n8n does sell this. OEM deployment is a paid commercial offering, separate from Enterprise, that lets your customers "create, edit, run, and manage their own workflows from inside your product". The catch is explicit in n8n's own description: "n8n branding remains visible in the editor... they will see it as n8n, not as a fully rebranded experience." So if your motivation for porting was white-labelling, note that the supported path does not give you that either. Worth knowing before you spend a quarter discovering it.

## The four things people actually want

Nearly everyone who asks about porting wants one of four things, and three of them do not need the editor at all.

**"I want to trigger n8n workflows from my Next.js app."** You want a route handler and a webhook. Your app calls n8n; n8n does the work. No frontend involved. This is the common case and it is covered in [the n8n and Next.js integration guide](https://www.razi.pro/blog/n8n-nextjs-integration-guide). If the workflow is slow, you also want [responding to a webhook without waiting for the workflow](https://www.razi.pro/blog/n8n-respond-to-webhook-without-waiting), because the default behaviour will hold your request open.

**"I want to show workflow status in my own UI."** You want the executions REST API, polled or pushed into your own components. You are rendering your data in your design system, which is better than embedding someone else's view anyway.

**"I want users to pick from workflows I built."** You want a template picker over your own table: a list of workflow IDs with names and descriptions you control, and a button that fires the matching webhook. This is an afternoon, not a port, and the UI is yours.

**"I want users to build arbitrary workflows inside my product."** This is the only one that genuinely needs a canvas — and it is the one the OEM licence exists for. If you build it yourself instead, understand the actual scope: a canvas is the easy part, and you are signing up to write an execution engine, a node registry, credential storage and an expression language.

If you are embedding rather than porting, [how to embed n8n in a Next.js app](https://www.razi.pro/blog/how-to-embed-n8n-in-nextjs) covers the practical route.

## If you are porting anyway

Assume you have cleared the licence question, and it is internal tooling.

Do not rewrite the editor. Mount it. Serve the existing Vue application and wrap it, communicating across the boundary with postMessage rather than shared state. You keep upstream's bug fixes; a rewrite forks you off the update path on day one and the editor is under active development.

Where that arrangement rubs:

- **Auth.** Two apps, one session. Easiest if both sit on the same origin so the cookie is simply shared; cross-origin means passing tokens over postMessage and refreshing them on both sides.
- **Routing.** Both frameworks want to own the URL. Pick one owner — the outer app — and keep the inner one on a hash or an internal route that never touches the browser history.
- **Theming.** The editor's styles are its own. You are matching your product to it, not the reverse.

And remember the Vue Flow detail from earlier. If you truly need a workflow canvas in React and the goal is your own product rather than n8n's editor specifically, the React ecosystem has React Flow, which occupies the same niche. Building a canvas on that is a clean-room project with no licence entanglement — a different, more honest undertaking than porting n8n. It is also a much bigger one than it looks, because the canvas was never the hard part.

## Running Vue inside a Next.js App Router page

If you do mount the Vue app directly rather than in an iframe, three concrete things bite.

Vue must not run during server rendering. In the App Router that means a client component and a dynamic import with SSR disabled, so the mount only happens in the browser:

    const Editor = dynamic(() => import("./VueEditor"), { ssr: false });

You are shipping two frameworks. Both runtimes end up in the bundle for any route that loads the editor, so keep that route isolated and never import it from shared layout code — otherwise Vue lands in the bundle for pages that have nothing to do with the editor.

And mount into a DOM node React does not manage. Give Vue an empty div with a ref, mount into it on the client, and unmount on cleanup. Two frameworks reconciling the same subtree is the one failure here that produces genuinely confusing bugs.

Honestly, though: if you have read this far and the answer to the licence question was "we are selling this", the useful next step is an email to n8n's sales team, not a branch. That is a less satisfying conclusion than an architecture diagram, and it is the one that saves the quarter.