Solid 2.0 retires SolidStart and moves full-stack support into a mode of its Vite plugin
Solid 2.0 folds SolidStart into its core and a new start mode of the official Vite plugin, retiring the meta-framework rather than shipping a 3.0. Existing apps keep running on maintenance releases; new full-stack Solid work now starts from a plugin flag.
Solid 2.0 reached Release Candidate with an announcement the team titled “The Big Reveal,” and the headline for anyone building full-stack Solid apps is not a new API but a subtraction: SolidStart, the framework’s meta-framework, is being retired. Its server functions, routing, and serving layer have moved into Solid’s core and a new start mode of the official Vite plugin, and the team decided that what was left over did not justify a 3.0. For a project weighing Solid against Next.js or SvelteKit, the shape of the decision just changed.
What moved, and where it landed
Over the 2.0 cycle, each capability SolidStart existed to provide was relocated. Server
functions marked with the "use server" directive are now a core feature backed by
@solidjs/web. The serving layer is a mode of the compiler’s Vite plugin, enabled with
solid({ start: true }), which owns entry files, dev serving, and the production build,
so a full app can run on plain Vite with no separate framework configuration.
File-system routing moved to a router-neutral filesystem-routing package that keeps
SolidStart’s conventions but no longer ties them to one router. The practical result is
that a new Solid app scaffolds from @solidjs/vite-plugin directly, and SSR becomes a
one-line ssr: true addition rather than a framework you install on top.
For a working developer, the payoff is fewer moving parts to reason about. A server
function’s body is just code, so validation, auth, and logging are lines you write rather
than framework hooks you wire, and anything referenced only inside a "use server" block
never reaches the client bundle. Deployment follows the same logic: a build emits a static
client plus a server module that default-exports a web-standard fetch handler, and the
platform Vite plugins from Cloudflare, Netlify, and Nitro consume Solid’s server
environment directly, so there is no Solid-specific adapter layer to configure.
Why retire a framework that just shipped 2.0
The timing looks odd until you separate the two releases. SolidStart v2 reached stable in early August, a year-plus rebuild that swapped its Vinxi build layer for Vite 8’s Environment API; that version targets Solid 1.x and remains a supported, production-ready choice for teams on the current core. The retirement is a statement about the future, tied to Solid 2.0. In the team’s words: “What remained at the end of that process was a wrapper around things that no longer needed wrapping. So instead of shipping a hollow 3.0, we’re retiring it. Start mode replaces SolidStart.”
That framing is worth taking at face value rather than reading as a project in trouble. A meta-framework earns its keep by filling gaps in the framework beneath it. When Solid’s core absorbed those gaps, the wrapper had less to do, and the team chose to fold it in rather than maintain a thinning abstraction.
What SolidStart users should actually do
Nothing urgent. The team is explicit that existing SolidStart apps keep running and that SolidStart will continue to receive maintenance releases, so this is not a deprecation with a countdown clock. The move to start mode is described as mechanical for most apps, with a migration assistant that scans a project and flags the specific sites that need changes. The honest planning note is that this is a maintenance-mode framework now: new feature work is happening in core and start mode, so a team starting a Solid project today should reach for start mode, and a team already on SolidStart should treat migration as scheduled maintenance rather than an emergency.
The pattern, and its limits
Solid is making a specific bet: that the Vite Environment API has matured enough for a UI framework to own its full-stack story without a separate meta-framework in between. It is not the only project testing that idea. TanStack Start already ships a Solid 2.0 beta and pairs with start mode out of the box, and the broader migration of deployment logic into Vite plugins is what makes an adapter-free build possible in the first place. It would be a stretch to read this as the end of meta-frameworks generally; Next.js, Nuxt, and SvelteKit remain distinct layers with their own reasons to exist. What Solid demonstrates is narrower and still notable: once the core and the build tool absorb enough of the job, the framework on top can shrink to a plugin flag.
What it means
For most developers the change is a simplification: one plugin, a start: true flag, and
a server-function primitive that lives in core. For teams already invested in SolidStart,
the message is reassuring on the short horizon and clear on the long one. Keep shipping,
migrate on your own schedule, and point new work at start mode. The retirement of a
framework that just reached 2.0 reads less like instability and more like a project
deciding that the cleanest meta-framework is the one you no longer need to install.