I ran it for about 7 and a half minutes earlier. It's a little slow to start but once I got used to the rhythm of things I really started to understand why it's so popular.
Overall, I'd say I'm a fan.
this post was submitted on 10 Sep 2025
25 points (100.0% liked)
Selfhosted
60253 readers
821 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
Came looking for this comment and was not disappointed.
I prefer dokploy and having full control over each aspect (like auth, backups and routing).
But this looks nice for when you don't care and just want to use it as it is provided.
The revolutionary thing about sandstorm is not all that much about administering hosting as it is about integrating deeply with applications.
I don't get that part. Can you explain it please?
Dokploy has a list of hundreds of "templates" where you basically one click install a working docker container with said app. But there is no deeper integration.
Is sandstorm different somehow?
For example, ether pad (document editor) is a) packaged to be single-click deployable on sandstorm (this is similar to dokploy), but also b) modified so that it runs each document as a "grain".
In sandstorm, "grain" is some chunk of data + an instance of the app running. So when you open a document, it will spawn a new process for it on the server and attach the data needed to that process (similar to how you would attach volumes to docker containers). This grain is isolated from other open documents, which is good for security, but also good for development:
- apps don't need to handle the organization or storage of documents (they just write to a dir and sandstorm associates it with the grain),
- apps don't need to handle user auth or permissions,
I used it for a project once. It is good, but make sure you have tested backup and restore (from scratch) before you need it. I found that to be a bit more problematic than usual server business. (but that was 6 years ago)
If I get it correctly, this is a kind of kasm but only for the local user, right?
I wouldn't say so - it's not streaming app views from the server, it provides containers for apps, segmented into "grains". So each open document gets it's own container. Other than that, it's just normal web apps (like immich or seafile).
OK, it is clearer now, thanks