Boost what matters

Feature Requests

Submit feature requests and boost what you want to see next.

#5213

LTS Maincloud

RequestedJun 3, 2026

## 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. ## Proposal Similar to [#5204](https://github.com/clockworklabs/SpacetimeDB/issues/5204) and its related [feature request](<https://spacetimedb.com/features/requests/38>) 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. _Requested by [@Lethalchip](https://spacetimedb.com/@lethalchip) via the SpacetimeDB site._

355,105TeV
From 8 boosters
#5199

Sync Inter-database Communication (Sync IDC)

RequestedJun 3, 2026

I would like to be able to call a reducer on another database from within my database. I want the reducer to be able to return the result, and I would like it to do so atomically: Receiver (payments) — a plain reducer that returns a value. ctx.sender is the calling database's identity. ```rs #[spacetimedb::reducer] fn charge(ctx: &ReducerContext, customer: Identity, amount: u64) -> Result<u64, String> { let mut acct = ctx.db.accounts().customer().find(customer).ok_or("no account")?; if acct.balance < amount { return Err("insufficient funds".into()); } // aborts the whole tx acct.balance -= amount; let new_balance = acct.balance; ctx.db.accounts().customer().update(acct); Ok(new_balance) } ``` Caller (orders) — the call is inline; the local insert and the remote charge commit together or both roll back. ```rs use payments; #[spacetimedb::reducer] fn place_order(ctx: &ReducerContext, item_id: u64, price: u64) -> Result<(), String> { let payment_db = ctx.db.config().single().payment_db; // a stored payments::Identity // Sync cross-database call (Level 7, 2PC). `?` aborts the whole distributed tx on Err. let new_balance = payments::Identity(payment_db).reducers.charge(ctx.sender, price)?; ctx.db.orders().insert(Order { id: 0, customer: ctx.sender, item_id, price, balance_after: new_balance }); Ok(()) } ``` _Requested by [@cloutiertyler](https://spacetimedb.com/@cloutiertyler) via the SpacetimeDB site._

88,002TeV
From 6 boosters
#5198

Async Inter-database Communication (Async IDC)

RequestedJun 3, 2026

I would like to be able to send messages from one database to another via an outbox table. Sender side (inventory module) 1. Declare the outbox table. It needs a #[primary_key] #[auto_inc] u64 msg_id, a #[target] typed identity, and payload columns matched by name to the receiver reducer's parameters. ```rs use game_world as gw; #[spacetimedb::table(name = out_receive_item, outbox(gw::receive_item))] pub struct OutReceiveItem { #[primary_key] #[auto_inc] msg_id: u64, // runtime-assigned sequence number #[target] target: gw::Identity, // which database to deliver to // Payload columns — names must match gw::receive_item's parameters. item_id: u64, qty: u32, } ``` Defaults are the strong guarantees: ordered = true, reliable = true → ordered, exactly-once delivery per (sender, receiver). 2. Send by inserting a row. Leave msg_id at 0; the runtime assigns it on commit. If the transaction rolls back, nothing is sent. ```rs #[spacetimedb::reducer] fn transfer_item(ctx: &ReducerContext, to: gw::Identity, item_id: u64, qty: u32) { ctx.db.out_receive_item().insert(OutReceiveItem { msg_id: 0, target: to, item_id, qty, }); } ``` 3. (Optional) Observe the outcome. Attach an on_result reactive reducer naming the outbox table. It fires once per terminated delivery, post-commit, on the sender. Ok(()) means the receiver returned Ok; Err(s) carries the receiver's error or a terminal transport/schema failure. ```rs #[spacetimedb::reducer(on_result(out_receive_item))] fn on_transfer_result( ctx: &ReducerContext, row: OutReceiveItem, result: Result<(), String>, ) { if let Err(err) = result { log::warn!("transfer of item {} to {:?} failed: {}", row.item_id, row.target, err); } } ``` _Requested by [@cloutiertyler](https://spacetimedb.com/@cloutiertyler) via the SpacetimeDB site._

88,002TeV
From 3 boosters
#5205

Improved SpacetimeAuth Web UX

RequestedJun 3, 2026

# Improved SpacetimeAuth Web UX ## Summary I’d like to request improvements to the SpacetimeAuth web login experience, especially for apps using third-party providers like Google and Discord. ## Issues ### 1. Extra authorization step The current identity-provider flow appears to require these steps: 1) Click login button on app 2) Click “Login with Google/Discord/etc.” 3) Click authorize with the provider 4) Click “Authorize Application” That fourth step is confusing for new users because they feel they already authorized the login provider. Ideally, third-party auth would only require selecting the provider and approving the provider login. If the extra step is required for technical reasons, the page should more clearly explain what is being authorized and why. ### 2. Login screen polish Play testers said the SpacetimeAuth login page looked somewhat “sketchy,” especially when only Google and Discord providers are available and email login is not enabled. A few CSS/layout improvements would help it feel more trustworthy and consistent with the polish of the main SpacetimeDB website. ### 3. Embedded login option It would be super helpful to support embedding the provider selection directly inside an app, similar to Firebase Auth, instead of requiring a redirect away from the page. ### 4. Role management Role management would still be useful, but it is lower priority for me because I already implemented a custom solution. ## Impact These changes would reduce login friction and improve trust for users trying apps built on SpacetimeDB, and prevent losing new players in the onboarding process. _Requested by [@doodlechaos](https://spacetimedb.com/@doodlechaos) via the SpacetimeDB site._

55,421TeV
From 3 boosters