If I understood it well enough, the intention was to formalize/standardize self-hosting such that it became easier (and with an emphasis on security).

With that done well, perhaps the next step would have been ready-made images. I could see it reducing friction for people if they'd rent a VPS, upload an ISO/IMG, and the resulting system was reliably secure. Then they'd use the Sandstorm interface to install apps with a web GUI.

There is still a roadmap documented here:

https://github.com/sandstorm-io/sandstorm/tree/master/roadma...

> It is more than enough security features for hosting your own apps, especially if you access them through something like tailscale.

But part of the whole point of Sandstorm and its ilk was that we could have so much better security. Sandboxing all the services really is better than what we're getting now.

I for one use Cloudron.io . Paying customer for 6 years.

I’ve been using Caprover for the last 4-5 years, and it’s great for my purposes.

It sounds like the OP may be looking for something that can be provisioned for multiple users, which Caprover doesn’t really have facility for. That said, the one-click-app templates are very easy to read/edit/update/create, if you can create a Docker Compose spec, you can create a template for Caprover.

I like that it’s really just a frontend for Docker, all of its functions are built around standard API calls to Docker. It means that I can install Portainer as a one-click-app, and use it to manage all of my other apps, without sacrificing any features. I can also spin up Docker containers outside of Caprover, and as long as I don’t run into port conflicts, it functions exactly as it should.

Caprover is just a one-man-show, so development may not be as responsive or rapid as some may wish, but the maintainer is very active, and he responds to pull requests promptly. One Click App templates are largely community maintained, but since they’re so easy to deal with, it’s trivial to work around most common issues, like updating versions or exposing new environment variables, and once again, the maintainer is very good about merging pull requests for app templates.

I think if I were doing it again I would not use containers at all. Instead I'd use isolates -- like Cloudflare Workers. In fact I'd probably build in on workerd (open source Cloudflare Workers runtime).

I'm obviously a bit biased here, as the architect of Cloudflare Workers. But, I think it's a much better fit for Sandstorm than containers were. Sandstorm suffered from some really bad cold start times, especially with every "grain" (e.g. document) running in its own container. It also led to a lot of other inefficiencies.

The down side of this is of course that it'd be much harder to port existing apps to the platform (unless maybe if they were already written to target Workers). But I think:

* Sandstorm didn't support existing apps very well anyway. It took a lot of work to convert apps for Sandstorm's security model. Many of the best Sandstorm apps were written from scratch for Sandstorm -- which incidentally was a lot easier than writing a traditional app, because Sandstorm took care of a lot of the work for you.

* AI-assisted coding takes a lot of the pressure off to support existing apps, because it'll be that much easier to build new ones. A Sandstorm-like environment would be a great fit for vibe coding since it takes care of so much of the boilerplate and enforces security in a way that the app can't screw it up.

What do you think? Would this ruin it for you?

You could not install Nextcloud on Sandstorm. Sandstorm has an app that used to work with Nextcloud's mobile app, but Nextcloud makes a very poor Sandstorm app because it is a monolith, instead of being granular.

(Personally I also find Nextcloud incredibly sluggish, but it is quite popular so it must work better for others.)

The problem with the strong security is that it makes it expensive to port into the system. They also assumed more sharing than people actually seem interested in. I'm mostly just running apps that have no reason to share with each other because they each have their own domain anyhow. So the end result is the ecosystem was more expensive to join if you had an existing system than it might have been otherwise, and it inhibited getting projects onboarded.

I am not the craziest self-hoster, but I've got several things now. I run a core syncthing node, Immich, Jellyfin, and Pihole. (Honorable mention I suppose to a Vaultwarden image, which is run on the public internet but my scripts treat it like it's another self-hosted option, rsync'ing it down locally and including it in the daily backup.) None of those are on Sandstorm, and a major reason why is the security system. They don't match it and porting it is a rather large amount of effort.

I haven't used any of the self-hosting options, so I can't review if any of them are as nice as Sandstorm. All of the above is running in Docker on an Ubuntu N150 and a USB hard drive, home-grown, with a backup script (restic over S3, true backup) that covers them all. It ought to in principle do most of what Sandstorm does now by driving docker, albeit missing the sharing, which I can't say looked all that compelling anyhow, automatic backup integration, etc., because it really isn't all that hard to set up.