> how does Sandstorm scale to real-world SaaS?
It doesn't! Sandstorm is the anti-SaaS. Sandstorm is all about running fine-grained instances of apps (e.g. a separate Etherpad instance for every document) in a decentralized way rather than huge centralized "scalable" SaaS apps. Supporting SaaS-style apps is explicitly a non-goal for us.
Sandstorm is meant for people hosting personal servers for themselves or for businesses hosting corporate-internal apps for their employees; generally not for external-facing apps.
It turns out that decentralized apps are trivial to scale, without any fancy distributed systems architecture.
> Are you going to require your users to configure lots of API keys and services manually and manage these vendor relationships?
No. "Managing vendor relationships" is not a thing that one needs to do in Sandstorm's usage model.
Sandstorm apps are generally self-contained; they include all their code dependencies directly in the package, including the full stack of front-end, business logic, database, etc.
The only time a Sandstorm app needs to reach out to other apps and services is when the app logically needs to interact with other objects. For example, imagine a chart app which renders charts based on the contents of a spreadsheet (another app). These apps need to be connected, but this kind of connection makes logical sense to an end user. They know what a chart is, they know what a spreadsheet is, and they know they need to connect them. Sandstorm will provide something we call the "powerbox UI" to allow users to create these connections in a user-friendly way.
https://docs.sandstorm.io/en/latest/developing/security-prac...
> How does Sandstorm create an update-model for SaaS when developers are deploying hundreds of changes a day?
It's like mobile. You ship an app to the app market, and then users get updates from there.