Solid 2.0 pulls server functions and routing into the core, and SolidStart is now maintenance-only

SolidStart is winding down because Solid 2.0 absorbed almost everything it did. Server functions, the serving layer, and file-system routing move into the core as a Vite plugin flag, and the team is retiring the standalone meta-framework rather than shipping a SolidStart 3.0.

By Stackmaven

SolidStart, the full-stack meta-framework for SolidJS, is winding down, and the reason is unusual: the core library it sits on absorbed nearly everything it did. With the Solid 2.0 release candidate, server functions, the serving layer, and file-system routing move directly into Solid itself, and the team is retiring the standalone framework rather than shipping a SolidStart 3.0. The SolidStart you deploy today still works, but new full-stack Solid work is meant to happen in the core going forward.

What moved into core

In the Solid 2.0 RC announcement, which creator Ryan Carniato titled “The Big Reveal” on August 13, the shape of the change is explicit. Over the 2.0 cycle, server functions moved into core under @solidjs/web/server-functions, the serving layer became a Vite plugin “Start mode” you turn on with solid({ start: true }) and an optional ssr: true, and file-system routing moved into a router-neutral package. Production now runs through a single handleRequest(request) contract. A turnkey full-stack setup that used to require a separate framework is now a flag on the compiler plugin.

Carniato’s own framing is the tell. “SolidStart’s job was to provide what core couldn’t,” he wrote, and by the end of the 2.0 cycle “what remained was a wrapper around things that no longer needed wrapping.” So instead of a SolidStart 3.0, the project goes into maintenance and Start mode takes its place.

SolidStart 2 first, then the wind-down

The sequence matters, because SolidStart 2 was a real modernization in its own right, not a lame-duck release. It dropped the Vinxi build layer for Vite 8’s Environment API and the Rolldown toolchain, added direct deployment integration for Nitro v3, Cloudflare, and Netlify, and fixed the flash-of-unstyled-content problem in lazy-loaded component styles. It requires Node.js 24. For teams on Solid 1 it is production-ready and will keep receiving maintenance releases. It simply turned out to be the last major line: once core could host its responsibilities, the team stopped iterating on the wrapper.

The migration is a move, not an upgrade

The precision that matters for planning: SolidStart 2 runs on Solid 1 and does not support Solid 2. The official migration guide is blunt about it, warning teams not to install Solid 2 into an existing SolidStart application. Adopting Solid 2 is a structural port, not a version bump. Configuration shifts from app.config.ts to a standard vite.config.ts with the solid({ start: {...}, ssr: true, serverFunctions: true }) plugin. The old entry-client and entry-server files get deleted because the plugin generates them, the app splits into an App.tsx for the router and providers and a Document.tsx for the HTML shell, and server function imports move from @solidjs/start to @solidjs/web/server-functions. The team calls most of the work mechanical, and independent walk-throughs agree the SolidStart 2 step is largely find-and-replace, but the jump to Solid 2 is a genuine migration that teams should schedule rather than assume.

What it means

This is a different bet than the rest of the ecosystem is making. React with Next.js, Vue with Nuxt, and Svelte with SvelteKit all keep the meta-framework as a distinct layer above the UI library. Solid is collapsing that layer into the core, arguing the split was incidental complexity once the core could host it. For a working Solid developer the read is practical: nothing breaks today, so keep shipping SolidStart 2, but treat it as a stable endpoint rather than a platform to build years of new architecture on, and plan the eventual move into Solid 2’s Start mode. For teams weighing Solid against other stacks, the smaller surface, one plugin flag, one request contract, and fewer build pieces, is the pitch, and the cost is a real migration plus an ecosystem still settling around a fresh 2.0. Solid’s answer to “do I still need a meta-framework?” is becoming “no, you need a flag.”

Sources cited