[HN Gopher] Sandstorm- self-hostable web productivity suite
       ___________________________________________________________________
        
       Sandstorm- self-hostable web productivity suite
        
       Author : nalinidash
       Score  : 146 points
       Date   : 2025-08-09 06:06 UTC (16 hours ago)
        
 (HTM) web link (sandstorm.org)
 (TXT) w3m dump (sandstorm.org)
        
       | docsaintly wrote:
       | I looked into Sandstorm when I moved away from NethServer; I'm a
       | strong believer in self-hosting. Sandstorm was too haphazard with
       | apps and security of apps didn't seem to be their highest
       | priority. I went with Cloudron, it's a nice mix of good app
       | selection and security.
        
         | wisty wrote:
         | Security was their highest priority.
         | 
         | IIRC idea was that all security was done by sharing links (with
         | capabilities) to documents.
        
         | ferfumarma wrote:
         | The entire security model of sandstorm is incredibly strong.
         | This criticism is hard to understand. Can you elaborate at all?
         | Do you recall any specific issues?
        
           | jerf wrote:
           | 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.
        
       | oulipo wrote:
       | Cool, what would be the differences with a tool like
       | https://dokploy.com/ ?
        
         | mkl wrote:
         | That seems to be totally different. Sandstorm was a way of
         | building your own private ~equivalent of Google Workspace out
         | of existing open source web apps running in containers behind a
         | common auth system.
        
       | meindnoch wrote:
       | This still exists? Is anyone using it? What's the use case?
        
         | neuroelectron wrote:
         | Imagine iCloud but you can manage more than 1,000 files at
         | once, the files transfer much more quickly and don't have to
         | use a touch interface that flakes out, plus no rent.
        
       | AceJohnny2 wrote:
       | Oh Sandstorm, what could've been...
       | 
       | Taking from https://sandstorm.org/about
       | 
       | > _Kenton Varda [NB: kentonv around here] launched Sandstorm in
       | 2014 via an Indiegogo campaign, before co-founding Sandstorm
       | Development Group with Jade Wang to develop Sandstorm as both a
       | Software-as-a-Service_ [...]
       | 
       | > _In early 2017, Sandstorm Development Group ran out of funding
       | and the team primarily joined Cloudflare._ [NB: Where kentonv
       | works to this day, leading the Cloud Workers team. Arguably
       | related?] [...]
       | 
       | > _In 2020, a group of Sandstorm enthusiasts began a community
       | effort to revive development of Sandstorm. [...] As of 2022,
       | Sandstorm Development Group has been completely dissolved, and
       | development of the Sandstorm project has transitioned to a
       | community-run model._
       | 
       | kentonv actually posted a recap of the history, including the
       | tragic passing of Ian "zenhack" Denhart who was leading the
       | community effort https://sandstorm.io/news/2024-01-14-move-to-
       | sandstorm-org
        
         | swah wrote:
         | What could have been? I remember being so excited about this at
         | that point, I was sure it was going to take a significant chunk
         | of [famous web services still around]. They even send me
         | stickers for Cap'n'proto..
        
       | MissTake wrote:
       | Is it just me, or is Sandstorm just not maintained any more?
       | 
       | The most recent closed issues were self closed rather than as the
       | result of development, while meanwhile the open issues continue
       | to pile up with virtually no code changes made to the tree...
       | 
       | It's a shame because it seems like it could have been a thing.
       | Sadly though it's hard to justify time investment into a platform
       | like this if you know there's little to no chance of getting any
       | issues fixed.
        
         | crabmusket wrote:
         | There is a small community maintaining it - there should be a
         | link to the Zulip on the website - but it is a small group and
         | a complex beast. Some effort is going into a rewrite that keeps
         | the same app/security model, but moves from C++ to Go and
         | simplifies the database layer. I believe that's taking up a
         | fair bit of contributor energy.
        
         | benatkin wrote:
         | They didn't quite reach the MVP level and so in a way it wasn't
         | really maintained in the early days either.
        
       | germandiago wrote:
       | Hello everyone. I have been using Sandstorm and put it to good
       | use in the last few years.
       | 
       | I used it with Wekan for project management and I also run
       | Dokuwiki for self-hosted docs. It has been zero maintenance for
       | me so it has been great.
       | 
       | However, the packages ecosystem seems unmaintained. It is a pitty
       | because I think the tool has a ton of potential and I really
       | liked it.
       | 
       | I am considering moving to Yunohost or something similar but
       | right now my little server hosts, together with other services,
       | Sandstorm and I think Yunohost needs to monopolize the server.
       | 
       | So I would ask for recommendations on similar tools. Not bare
       | Docker containers but fully lanaged platforms wirh one click
       | installs where it is easy to add/remove users.
        
         | diggan wrote:
         | > So I would ask for recommendations on similar tools. Not bare
         | Docker containers but fully lanaged platforms wirh one click
         | installs where it is easy to add/remove users.
         | 
         | I've done a similar journey for my self-hosted stuff, started
         | with Sandstorm, moved to Yunohost, but got frustrated with the
         | configuration, and how different every package was and
         | eventually have landed on using NixOS for my home servers. It's
         | not a "fully managed platform" in the traditional sense, but if
         | you're a developer, that's almost what you get. Adding new
         | services is usually just adding the configuration for them.
         | 
         | Bit of a learning curve learning the language, tooling and
         | ecosystem, but once you're over that hurdle, having all
         | declerative configuration in SCM together with easy linking of
         | configuration options together (define service ports once,
         | reference them in other services, for example), and everything
         | being easy to rollback, have been a god-send so far. Been
         | running it for maybe 2 years or something by now, with more or
         | less zero issues besides the ones I introduce myself.
         | 
         | Adding/removing users can be as easy as adding/remove one line
         | of configuration, and redeploying. Simple enough for me and my
         | family so far.
        
         | ethan_smith wrote:
         | For Sandstorm alternatives with one-click installs and user
         | management, consider Cloudron, Caprover, Umbrel, Unraid,
         | TrueNAS SCALE apps, or Portainer with its app templates - most
         | allow running alongside other services without monopolizing
         | your server.
        
           | nativeit wrote:
           | 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.
        
         | sunshine-o wrote:
         | I have been thing a lot about why none of those self-hosting
         | solutions never took off and most of them died off over the
         | last decade.
         | 
         | Why are we going dehydrated in the middle of the ocean, with
         | docker and so many open source alternative to the common
         | software and services ?
         | 
         | My conclusion is this: just pick the distro you like, whether
         | it is Debian, Fedora, Arch or FreeBSD. Preferably one with the
         | selection of package you need. All those will be maintained in
         | a few years too, you just need to upgrade.
         | 
         | Because in the end the solution was the problem. A Debian for
         | example was meant to host Internet services, it is well put
         | together and has a large selection of software and can be
         | trusted. It is more than enough security features for hosting
         | your own apps, especially if you access them through something
         | like tailscale.
         | 
         | A lot of people (me included) thought that since containers
         | were the hype we should build something new and setup
         | everything like a corporation would do. Looking back it was a
         | bad idea and it did not work (fact).
        
           | yjftsjthsd-h wrote:
           | > 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.
        
           | unixhero wrote:
           | I for one use Cloudron.io . Paying customer for 6 years.
        
         | justusthane wrote:
         | There are lots -- "selfhosted OS" is the term to look for.
         | Umbrel and CasaOS are some other popular ones. I don't personal
         | experience with any of them though.
        
         | mxuribe wrote:
         | There also used to be Freedom Bone
         | [https://gitlab.com/bashrc2/freedombone] ...but, honestly, I've
         | never used it nor am even sure if its still alive as a project.
        
         | npteljes wrote:
         | I loved the idea of Sandstorm as well, but ended up moving my
         | stuff to Proxmox and TurnKey Linux. TKL is a similar idea to
         | Sandstorm, but on the container level, so what you download are
         | LXC images, ready to go after a minimum of user-friendly
         | configuration. They are going since 2008, and they have around
         | 120 offerings.
         | 
         | TKL is integrated into Proxmox, so for example if you'd like a
         | new Wordpress site or a Nextcloud or Mattermost instance, you
         | just click a bunch on the web interface, it downloads the image
         | and installs and runs it, you do the initial setup my giving it
         | a bunch of info on a user interface, and the thing is ready to
         | go.
        
       | raphinou wrote:
       | I was initially enthousiastic about sandstorm when I encountered
       | it, but in the end my preferred solution for self hosting has
       | been Docker Swarm. Dead simple setup, low maintenance, everything
       | easily deployable within Swarm (crons, backups, first deployment
       | setup, reverse proxy config incl. certificates, etc).
       | 
       | Additionally a lot of projects provide a Docker compose file
       | which is mostly compatible with swarm. I started using Swarm [1]
       | when k8s was already ruling, but never regretted my choice.
       | 
       | 1: https://www.yvesdennels.com/posts/docker-swarm-in-2022/
        
       | bhasinanant wrote:
       | What I do want to understand is, why would anyone use this
       | instead of NextCloud, for example. I'm all for having local
       | setups though, as a general policy. It's just that from what I
       | know, the difference in feature sets is just too huge right now.
        
       | esafak wrote:
       | Smaller cats, bigger screenshots, please.
        
       | c-hendricks wrote:
       | I remember Sandstorm but don't remember it ever billing itself as
       | a web productivity suite... It was a repository of self-hostable
       | apps with their own auth layer integrated so managing users and
       | permissions was easier.
       | 
       | This always sounded like a monumental task. I've since gone with
       | Authelia.
        
       | kentonv wrote:
       | sandstorm.org is an offshoot of sandstorm.io, my old (failed)
       | startup. Some folks who really wanted to keep the project running
       | took over ownership of the open source code. I'm not involved
       | these days. Full story at:
       | https://sandstorm.io/news/2024-01-14-move-to-sandstorm-org
       | 
       | The people still trying to run it are good people, so I hate to
       | say this, but... it doesn't seem like they are going to make
       | progress. There hasn't been a new release in years, and the
       | codebase is rotting. I wouldn't recommend running it in its
       | current state.
       | 
       | Meanwhile, though, I feel like the advent of vibe coding has made
       | Sandstorm's approach seem newly relevant. Sandstorm's
       | architecture made "novice" code safe to run even for users with
       | sensitive security needs. Well well well, suddenly we have a
       | whole lot more novice code than we used to.
       | 
       | Is it... time for me to take another pass at this?
        
         | unixhero wrote:
         | I could have definitely used it in my company nowadays, as a
         | paying org. A refresh of available apps would maybe be
         | necessary now. Sandstorm was so awesome.
        
         | creativeSlumber wrote:
         | > Is it... time for me to take another pass at this?
         | 
         | Yes please. I was very excited for Sandstorm when it first
         | started. Sad to see it's current stage.
         | 
         | Also I think the world around has evolved quite a bit wrt
         | containerization from when Sandstorm first started. I wonder
         | how you would build it today, if you were to build from
         | scratch. Could you utilize docker for most of the
         | containerization?
        
           | kentonv wrote:
           | 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?
        
       ___________________________________________________________________
       (page generated 2025-08-09 23:01 UTC)