"Is the framework our site uses still OK?" When a client asks this, what they want to know is not which technology is better, but one thing: whether they need to set aside migration costs in next fiscal year's budget.
What happened with SolidStart is good practice for that decision. The stable release of 2.0 came out on August 4, 2026, and about a week later it was announced that the framework itself would continue with maintenance releases only. A new version came out even as its role heads toward an end, which at first glance seems contradictory.
What happened
In 2.0, for Solid 1 apps, the build coordination layer that had been used separately until now (Vinxi) is gone, and the framework uses Vite's Environment API directly. It requires Node.js 24 or later and Vite 8 to run, and the configuration also moves from app.config.ts to vite.config.ts.
The announcement of the Solid 2.0 release candidate, published in mid-August, explains that server functions have become a core feature, the serving layer has moved to the new "start mode," and file-based routing has moved to a separate package that does not depend on any particular router. On that basis, it said that start mode replaces SolidStart. Nothing breaks if you run SolidStart in production today, SolidStart will continue to receive maintenance releases, and a migration guide has been published. Solid 2.0 itself is still at the release candidate stage as of September 24, 2026.
Read "maintenance mode" as three separate stages
To avoid panicking over the wording of the announcement alone, separate the states.
| Status | What actually happens | Decision for the client |
|---|---|---|
| New features stop | Features that work today keep working | No budget needed. Consider it at the next round of changes |
| Maintenance releases only | Bug and vulnerability fixes still arrive | Just get a migration estimate |
| Updates stop | Cannot keep up with updates to the language and build tools it depends on | Set a deadline and migrate |
SolidStart is currently in the middle stage. If someone proposes a complete rebuild at this point, ask for the reasoning. A rebuild usually becomes necessary not because of the framework itself, but when the surrounding dependencies get stuck first.
The surrounding requirements are what really matter
In practice, the fact that 2.0 requires Node.js 24 or later weighs more heavily than anything about the framework. Servers stuck on old versions of Node, CI images and what your hosting supports directly decide whether you can migrate.
When you request estimates, ask for them to be broken down into the following units so you can compare them.
- Moving the configuration file and getting the build to pass
- Work on the runtime environment to meet the Node and Vite requirements
- Replacing plugins and libraries in use that are not supported
- Checking the parts users see, such as page display and forms
A lump-sum estimate hides where the heavy work is. If it is split into these four parts, the client can decide what to do this fiscal year and what to defer to the next.
One more thing to check is how security updates reach you. Even while the framework itself keeps issuing maintenance releases, the libraries it depends on may stop updating first. Not having decided who receives vulnerability notifications and who assesses their impact is a problem closer to real harm than whether your versions are old or new.
Put dependency lifespans in the contract
When you commission a site, nobody can know when its framework will reach its end. What you can decide is who does what when the end is announced. If your maintenance contract includes a list of the main dependencies in use and the procedure for notification and estimates when the end of updates is announced, decisions will not depend on particular individuals.
The same pattern is playing out elsewhere. We covered a case where CDN version pinning changed in update control in htmx 4.0, and a case where the developer's organization changed in the Tailwind acquisition and what is inside your dependencies. We summarize developments on the build tooling side in the unified Vite toolchain.
If you do anything this week, just take inventory
Before migrating, list what your site runs on: the framework and its version, the Node version, hosting, where builds run and the main plugins. Just having this list changes how you respond the next time a similar announcement comes out.
We checked the SolidStart 2.0 stable release announcement, the Solid 2.0 release candidate announcement and the npm publication history on September 24, 2026, and organized this research article based on them. We have not carried out a migration to SolidStart 2.0 or run any builds. For details of the migration steps, see the official migration guide.
For an inventory of the frameworks you use or help scoping a migration, please consult GleamHub.
