#5213Requested

LTS Maincloud

Requested by @Lethalchip
Energy Committed354,100TeVfrom 7 boosters

Summary

While Maincloud is not technically on a bleeding edge or nightly release cycle, the latest version is deployed immediately after a new SpacetimeDB release.

Your only option to not upgrade to latest is to use Standalone or lock in an Enterprise deal for a private node. Each of these have issues:

  • Standalone -> Free, but doesn't scale
  • Enterprise -> Potentially costly, and overkill for most

The logical conclusion for a vast majority of users is to use shared hosting, a-la Maincloud. It even comes with SLA / Uptime Guarantees if you're a Pro subscriber.

The Issue

I have no doubt that a lot of effort goes into this, but deploying new SpacetimeDB versions to Maincloud without any issue or bugs is a tall order- in fact, it's an impossible order. The new version is being deployed to thousands of modules, all on various runtime versions, and some functionality will be tested live for the very first time in unexpected ways. We can have 1,000 different smoke tests, but they will never handle all of the edge-cases. This has, and will continue to lead to disruptions to Maincloud customers.

If your app or game has paying customers, this type of disruption is not acceptable. Playing devils advocate- some would even argue that these types of disruptions indicate that Maincloud is not a production-ready environment.

Proposal

Similar to #5204 and its related feature request I would love to see a LTS Maincloud instance that is fixed to a specific stable build.

spacetime publish <module_name> --lts

This would prevent new Maincloud version deploys (and bugs) from disrupting production applications deployed on LTS Maincloud, giving potential start-ups and businesses peace of mind knowing their backend infra is stable.

Challenges

I acknowledge this comes with many challenges, so I am looking for feedback and replies in the github thread:

  • Does current maincloud transition to LTS or Latest?
  • Maincloud will need module migration tool to go from server to server
  • Can you only migrate your module from LTS to Latest and not the other way around?
  • At what interval is the LTS version updated? What type of key milestones indicate a version bump?
  • What type of deploy/patches are allowed on LTS? Bugfixes only? What about QoL?
  • What should be the default Maincloud publish functionality, LTS or Latest?

Happy to hear your thoughts. Let's have a discussion.

  1. website-features added the feature-request label Jun 3, 2026
  2. An alternative to a LTS server would be a "pre-release" to a Testcloud or something that allows testers to play around on the new version for 1-2 weeks prior to release on Maincloud. The Testcloud could have "unlimited" energy, meaning you can test out XYZ new version for free, however would have regular wipes to prevent production usage.

Boost this Request

Reopen this request?

The request will return to its prior live status.

Mark as Duplicate

Pick the request that LTS Maincloud is a duplicate of. Energy rolls up into that request and GitHub closes the linked issue as a duplicate with a timeline reference to the canonical.

Unmark Duplicate

Restore as an independent request. The linked GitHub issue will be reopened and its duplicate-of relationship cleared. The original timeline entries stay as history; the note below is posted as a follow-up comment.