Solid 2.0 pulls SolidStart's job into core, and the meta-framework is being retired
Solid's 2.0 release candidate folds the server functions, routing, and serving layer that once justified SolidStart into core, and the team says SolidStart is being retired rather than shipped as a 3.0. Its job now lives in a built-in Start mode.
Solid’s full-stack story is collapsing into a single package. With the Solid 2.0 release candidate, the reactive library is absorbing the server functions, routing, and serving layer that used to justify a separate meta-framework, and the team has said SolidStart will not get a 3.0. For anyone running Solid on the server today, the framework they build on is quietly changing shape.
What the Solid team announced
The Solid 2.0 RC, which the team titled “The Big Reveal,” lays out a consolidation that has been running for the whole 2.0 cycle. “SolidStart’s job was to provide what core couldn’t,” the announcement says, and over that cycle “each of those capabilities moved home: server functions into core, the serving layer into start mode, file-system routing into a router-neutral package.” What is left of SolidStart, by the team’s own account, is “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.”
The reassurance is explicit, and worth repeating for anyone with production code: “If you run SolidStart in production today, nothing breaks. SolidStart will continue to receive maintenance releases, and the migration guide is available now.” This is a wind-down, not a cliff.
What “Start mode” actually is
Start mode is not a new framework, it is a mode of the Solid Vite plugin. A
full-stack Solid app now opts in with a single plugin call,
solid({ start: true, ssr: true }), which swaps client rendering for hydration,
turns on the server-side rendering transforms, and produces the server bundle.
File-system routing, the feature most people associate with a meta-framework,
moves into a router-neutral filesystem-routing package that keeps SolidStart’s
conventions, hot module reloading, and code splitting, and emits typed routes for
Solid Router. API routes stay as GET and POST handlers expressed as fetch
middleware.
For a working developer, the practical shift is that the full-stack surface is now assembled from Solid core plus a router package and a Vite flag, rather than from a separate framework layered on top of all three. That means fewer moving parts, but also fewer places for the abstraction to smooth over rough edges.
The timeline is doing a lot of work here
The sequence matters, because SolidStart 2.0 only just shipped. The stable 2.0
release landed in early August as a ground-up modernization: it drops the Vinxi
build layer and builds directly on Vite 8’s Environment API and its Rolldown-powered
toolchain, which is what finally let Solid configure separate client and server
builds without a coordinator sitting in between. That release requires Node.js 24
and Vite 8, and most apps upgrade by moving their configuration from
app.config.ts into vite.config.ts. So the same cycle that produced a modern
SolidStart 2.0 also made the case that SolidStart no longer needs to exist as its
own project. The 2.0 line is, in effect, the last major version.
What changed in Solid 2.0 itself
The consolidation rides on a larger reactivity change that is the real headline of
the RC. Solid 2.0 makes asynchronous work a property of the reactive system rather
than something bolted on around it. The older Suspense-style patterns give way to
reworked boundaries the team names <Loading>, <Errored>, and <Reveal>, and
manual batching is gone because everything batches by default. For developers, that
means data fetching and pending states are meant to be expressed in the graph
itself, which is also what makes a thinner serving layer viable: much of what a
meta-framework used to coordinate is now core behavior.
What SolidStart developers should do
The honest reading is that nothing is urgent and nothing is optional forever. Independent coverage from InfoQ framed the move as SolidStart entering maintenance as its role winds down, which is the right altitude: existing apps keep working and keep getting fixes, but the forward path is Start mode, not a future SolidStart. If you are starting a new full-stack Solid project, target Start mode on Solid 2.0 so you are not adopting something that is already being retired. If you maintain a SolidStart app, read the migration guide now and plan the move deliberately rather than waiting for a deadline that, by design, is not coming.
The wider signal is worth sitting with. Solid is betting that a strong enough core reactive model shrinks the meta-framework down to a plugin flag, and that the routing and serving conventions developers valued can live as standalone packages rather than a branded stack. If that bet holds, it is a quiet argument that some of what we call frameworks is really just core capabilities that had not landed yet.