We have recently completed a major frontend migration across Plane’s web applications, from Next.js to React Router (Framework Mode) + Vite.

This early announcement aims to share the what and why with our technical community.

A deeper architectural breakdown (routing structure, build setup, compatibility layers, and migration notes) will be published separately.

Why we made the change

Over the last few releases, Plane’s frontend architecture has naturally evolved toward client-side patterns. At the same time, our tooling and internal workflows were already gravitating toward Vite. At some point, staying on Next.js stopped matching how we actually build and run Plane.

1. The application architecture is client-first

Plane does not use:

• Server-side rendering (SSR)
• Hybrid routing
• Next.js-specific data fetching primitives

Most core functionality occurs on the client side: rich interactions, real‑time updates, and API-driven views. A simpler, predictable client-side router is a better fit for this reality.

React Router (Framework Mode) gives us exactly what we need:

• A battle-tested router, optimized for client apps
• Clear, explicit routing without framework‑specific magic
• Better alignment with how we already structure our screens and layouts

2. Development feedback loops were slow

Before the migration, local changes could take 20–30 seconds to show up during development. That friction adds up quickly when you are iterating all day.

With Vite:

• Hot reloads are effectively instant (milliseconds).
• The dev server startup time is much faster.
• The build system is easier to reason about and tune.

This directly improves productivity for everyone working on Plane — both internally and in the open-source community.

3. Alignment with the existing Vite ecosystem

Our test environment has been Vite-based for a while. That created an unnecessary split:

• Next.js for production builds and dev
• Vite for testing

Standardizing on Vite end‑to‑end lets us

• reduce mental overhead and configuration drift
• share more tooling and helpers between dev, build, and tests
• debug issues in one consistent environment

4. Simplified build pipeline and clearer internals

We still maintain compatibility layers for a few Next.js behaviors and APIs to avoid a disruptive breaking change. But the new stack gives us a clearer path to:

• Gradually remove legacy abstractions
• Simplify the routing and build pipeline
• Better align internal code with how the app actually behaves in production

This migration lays the foundation for future cleanup—not merely a one tooling swap.

What React Router + Vite Enables

Pairing React Router (Framework Mode) with Vite gives us a frontend stack that is:

• Fast – Hot reloads and rebuilds are noticeably quicker.
• Transparent – The build pipeline is easier to inspect, tweak, and debug.
• Predictable – Routing behaves exactly like a client-side app should.
• Consistent – One Vite-based workflow for development, builds, and tests.

Concretely, this means:

• Instant hot reloads while developing Plane
• Finer-grained control over bundling, code splitting, and build output
• Static deployments that match our current architecture and hosting model
• A single, unified toolchain across dev, build, and CI

For Plane users, there is no visual or functional change. The product should look and behave exactly the same — but we can now ship improvements and fixes more quickly and with less friction.

What was the scope of the migration

To give a sense of the scale:

• Over 1,200 files were updated
• More than 20,000 new lines of code were added across three apps
• Three repositories were involved, including:
• Community Edition (makeplane/plane)
• Enterprise / Cloud / self‑hosted (plane-ee)
• Air‑gapped deployment repo

This was not a small “swap the router” change. We refactored routing, build configs, and parts of the app architecture to lean into React Router + Vite correctly rather than patching for the old setup.

We have aggressively tested this across:

• our internal environments
• cloud and self‑hosted setups
• air‑gapped deployments

If you do spot issues, we would love bug reports — but we are confident in the stability of this change.

What this means for the open source community

If you are running Plane from source or contributing code, you should see tangible benefits:

• Faster local setup
  Vite-based dev environments spin up quickly and are easier to reason about.
• Quicker builds and tests
  Shorter feedback cycles when contributing features or debugging issues.
• Cleaner architecture over time
  Gradually retiring compatibility layers will simplify the codebase, making it easier to navigate and modify.
• More flexibility for self-hosting and extensions
  A straightforward, client-first architecture makes it easier to:
• customize Plane
• embed it into your own environments
• maintain air‑gapped or specialized deployments

We will also share more detailed notes for self-hosters and contributors in an upcoming deep dive: configuration changes, migration caveats, and practical tips.

What is next

This post is intentionally early and high-level. Next, we plan to publish a deeper technical breakdown that covers:

• How we structured routing with React Router Framework Mode
• How we organized our Vite setup across repositories
• Lessons learned from updating 1,200+ files without breaking everything

In the meantime, if you are running Plane from source and you hit anything unexpected with the new stack, please open an issue or discussion on GitHub — your feedback helps us refine this transition for everyone.