SolidStart 2.0: Drop Vinxi, Migrate to Vite 8 Now

SolidStart 2.0 went stable on September 19, 2026 — and within days of shipping, the framework announced it is entering maintenance mode. That’s not a bad release story. It’s actually the right one. After 25+ pre-release builds and more than a year of development, the SolidJS meta-framework completed its ground-up modernization: Vinxi is out, Vite 8’s Environment API is in. The timing of the retirement isn’t a coincidence — Solid 2.0 RC absorbed everything SolidStart used to provide, making the wrapper unnecessary. It shipped its best version precisely so it could bow out cleanly.

What Changed in v2: Vinxi Is Gone

The core architectural shift is the removal of Vinxi, the build-coordination layer that SolidStart 1.x depended on. Vinxi existed because Vite 5 had no native way to manage separate client and server build environments. Vite 8 ships with a native Environment API that solves exactly that problem. The abstraction Vinxi provided is no longer needed.

Replacing Vinxi with direct Vite 8 integration brings concrete wins: better plugin compatibility (Tailwind CSS v4 now works without workarounds), native deployment adapters for Nitro v3, Cloudflare, and Netlify, and Vite 8’s Rolldown-powered toolchain. A long-standing bug — flashes of unstyled content when lazy-loading components during SSR — is fixed as a side effect of the rebuild.

Migration: Four Changes, One Hard Requirement

The migration from SolidStart 1 to 2 is mostly mechanical. The one thing to flag before you start: Node.js 24 is required. If your deployment environment can’t run Node 24, that needs to be sorted first.

Everything else is a find-and-replace operation:

1. Delete app.config.ts, create vite.config.ts — configuration moves into standard Vite config that calls solidStart()
2. Update scripts — vinxi dev, vinxi build, vinxi preview become vite dev, vite build, vite preview
3. Swap TypeScript types — vinxi/types/client to @solidjs/start/env in tsconfig.json
4. Check CSP settings — v2 defaults to JSON serialization (CSP-safe); v1 defaulted to JS format, which requires unsafe-eval. If you were relying on the old behavior, add serialization: { mode: "js" } to your solidStart() call

The resulting vite.config.ts looks like this:

import { defineConfig } from 'vite'
import solidStart from '@solidjs/start/vite'
import nitro from 'nitro'

export default defineConfig({
  plugins: [solidStart(), nitro()]
})

Remove Vinxi from your dependencies and clean .vinxi from your .gitignore. That’s the migration.

The Maintenance Announcement: Why Now Makes Sense

The timing feels abrupt — v2 ships, maintenance starts — but the logic is sound. Solid 2.0 RC, released concurrently, migrated every capability that SolidStart provided into core libraries:

• Server functions moved to @solidjs/web/server-functions ("use server" as a language primitive)
• File-system routing is now a router-neutral package that handles HMR, code splitting, and typed route emission
• The serving layer lives in the Vite plugin’s start mode — solid({ start: true, ssr: true }) — with handleRequest(request) as the single production contract

Ryan Carniato, the framework’s creator, put it plainly: “Start mode replaces SolidStart.” The meta-framework layer became redundant because Solid 2.0 grew up enough to not need it.

Maintenance mode means security patches, not end-of-life. Existing SolidStart applications keep running without incident.

What Solid 2.0 Start Mode Offers

If you’re considering the forward path, Solid 2.0 RC is worth understanding. The framework ships a new Rust-based compiler built on the Oxc project, and the performance numbers are significant: an 88-file project compiles in 19ms instead of 440ms. A 1MB module that previously took 24 seconds now takes 70ms. That’s not incremental improvement — it’s a different category of build speed.

The API also simplifies meaningfully. createResource is gone; async flows through regular memos. Automatic batching runs on microtasks by default. JSX lost its Solid-specific prefixes (attr:, bool:, on:). The framework is getting closer to reading like standard TypeScript rather than a custom DSL.

What Should You Do?

• Migrate to SolidStart 2.0 now — if you’re on SolidStart 1.x, this is a mechanical upgrade. Node 24 is the only real requirement, and it keeps you on supported software.
• Watch Solid 2.0 stable — start mode is available in RC today. Full stable is expected soon. Once it lands, the path forward is clear.
• Consider TanStack Start — a valid alternative if the SolidJS 2.0 transition feels disruptive and you want a meta-framework under active feature development.

The consolidation of SolidStart’s capabilities into Solid 2.0 core is a healthy signal. Meta-frameworks disappear when the core framework grows capable enough to not need them — and in SolidJS’s case, that’s exactly what happened.