Sandstorm: Open-source platform for self-hosting web apps | Hacker News Reader

Sandstorm: Open-source platform for self-hosting web apps

sandstorm.io

468 pointssrgpqt137 comments

Sandstorm was (is?) way ahead of its time. Fortunately a lot of its ideas live on (a la capnproto). My understanding is the achilles heel is the amount of effort required to integrate and update apps, since each app needs to be rather invasively modified to work with the centralized authorization framework. Also the general difficulty of managing a VPS or port forwarding. But once integrated it's really slick and secure.

The overall UX is very similar to my vision of the future of selfhosting. It should be as easy as installing an app on your phone, then going through a quick OAuth2 flow to set up a tunnel on a domain, and you're up and running.

Is! We're not dead yet! (see my other comment https://news.ycombinator.com/item?id=36193093).

I don't think app packaging could be said to be the achilles heel -- how much work it involves depends a lot on the app (some things are very easy, others can be painful), but it is certainly not the case that Sandstorm didn't take off because packaging was too hard.

“Was”, what’s left of sandstorm anymore besides a couple weekender coders whose $dayjob is at cloudflare these days? Doubt CF has anything like 10%/20% time like GOOG.

Sandstorm the business was shut down 6 years ago https://sandstorm.io/news/2017-02-06-sandstorm-returning-to-...

And Sandstorm Oasis the hosting service was shut down almost 4 years ago https://sandstorm.io/news/2019-09-15-shutting-down-oasis

This codebase is basically abandonware at this point and can’t be trusted for anything serious these days. If CF brought this on as an official product (and renamed it), it would go a long ways to build back trust

FWIW, the most-active Sandstorm developers over the past couple of years, such as zenhack (to whom you replied) and ocdtrekkie, are not Cloudflare employees, and never were. (They were never Sandstorm employees either.)

For my part, I am indeed mostly focused on Cloudflare Workers today and don't have much leftover energy to spend on Sandstorm. This has nothing to do with Cloudflare telling me how to spend my time. I make my own choices. I still love what we were building with Sandstorm, but what can I say, Workers has been a lot more successful and so I am drawn to focus my energy there.

Note that Cloudflare has no affiliation with Sandstorm, other than employing some of the former team members. Cloudflare did not acquire Sandstorm itself.

One problem with Sandstorm is that it didn't have something like miniflare. (Cloudflare didn't either until recently, and that's fixed now, but the value prop was high enough otherwise that this wasn't fatal.)

Another is that it lacked (and still does, from what I can see) a killer app. It had the perfect conditions last year with the Twitter acquisition, but to my knowledge didn't seize upon it. (Likewise, Cloudflare had a similar opportunity, but the Wildebeest project comes off as a celebration of Cloudflare's infrastructure for the sake of it and/or aimed at those who love devops stack complexity, generally—a fairly tonedeaf response to what would drive someone to want to run their own fediverse node that's not backed by Mastodon.)

The weird URLs—or rather: the constraints that led to them, and the downstream consequences to UX—didn't help.

This comment confuses me: Sandstorm itself is entirely local, and the vagrant-spk dev tool assembles local Sandstorm dev instances in virtual environments with three commands. I'm not sure what "thing like miniflare" we are missing!

As far as the killer app, Sandstorm has some really awesome Sandstorm-only apps, but probably not enough yet for our "exclusives" to be a draw to the platform on their own. Sandstorm currently has some limitations that make it difficult to use in federated environments, and we are working on it, but yeah, it meant we didn't have a fantastic story for social during all this Elon stuff.

> This comment confuses me: Sandstorm itself is entirely local

The hosted version wasn't. Having to prop up your own Sandstorm instance pretty much compromises the project goal—ease of app installability means little gains when you're still responsible for running Sandstorm infrastructure that it relies upon.

I share ocdtrekkie's confusion here.

Your original complaint was the lack of a "miniflare", i.e. a simulator for local development purposes. But you can run Sandstorm itself locally and there are in fact tools to streamline the process of doing app development using a local Sandstorm server.

Now you seem to be arguing something about how running Sandstorm locally is too much work for end users, who would prefer to use the hosted version? But I thought we were talking about app developers. End users don't need a "miniflare".

Please reply indicating whether you agree or disagree with the following statement:

"The Cloudflare developer experience with miniflare is worse than that of Sandstorm."

The experience configuring sendmail is worse than configuring icewm if you want to play audio files.

If what you're looking for here is someone to confirm that your crummy false equivalence is crummy and false, then that's doable. (Say the word if so.)

How do you compare to Yunohost? I find the app selection of Yunohost larger and broader

Sandstorm is much more secure, that's the main difference.

I'm not too familiar with either's privacy/security practices, what makes Sandstorm more secure than Yunohost?

https://sandstorm.io/how-it-works

Sandstorm implements a capability-based security model, where not only does each app run in a strong sandbox, but a new instance of the app is created for each document (or whatever the app's logical unit of data may be). Sandstorm itself enforces that each document can only be accessed by the people with whom it has been shared, regardless of any bugs that might exist in the app itself. All communications between the user's browser and the app go through a proxy implemented by Sandstorm which applies this authorization regime.

Apps cannot even talk to each other or the internet without specifically requesting access, granted by the user. The UX model for these requests is designed to flow naturally for the user, by deriving the user's intent to permit access from the action they took that caused the access to be needed. For example, say the user wants to embed a chart into a document, where the chart editor and document editor are separate apps. The user clicks some sort of "embed" button in the document editor. Now they are presented with a chooser where they can pick which thing they want to embed. If they make a choice, there is no need to separately ask the user if they want the document to have access to the chart -- of course they do. Sandstorm works by having the system implement the "picker" UI directly, so that Sandstorm knows the user made this choice, and can automatically provide the implied authorization.

All this actually makes apps easier to write since they don't have to deal with authorization and user management themselves, and as a result there are a lot of neat unique apps for Sandstorm written by various people in a short amount of time. However, the down side is that existing off-the-shelf apps that do already feature their own user management and authorization are somewhat laborious to port to Sandstorm.

Yunohost takes a more traditional model of just running each app and letting it figure out its own authorization.

One can choose something like cloudron which provides isolation via docker

Cloudron is pretty cool, and Docker containers definitely help, but there's a huge security difference between what Docker provides and what Sandstorm does. One of the biggest differences is that most plain Docker-based self-hosting platforms isolate at the app level. Sandstorm isolates individual documents, which often means Sandstorm apps are protected from their own internal flaws as well.

Also, Cloudron is not open source and you need a subscription to use it generally. This has led it to be more successful of a business venture, of course, but is a big downside for software freedom.

docker was never meant as a security tool. Proper sandboxing needs to be done in the applications.

What would an application do that is more secure than namespaces+cgroups? Containers absolutely are a security tool (especially if you configure your capabilities and don't use PID 1), one with a security tradeoffs compared to real virtualization, sure, but you're not going to do that on a VPS.

Docker (or Podman) is just a tool that sets up some linux primitives for you. One with a track record and volume of users that'd make me trust it over things that specifically advertise themselves as "security sandboxes" (i.e. firejail, who had some extremely funny basic exploits to get root from their SUID'd binary). You can even pair containers with user namespaces now and get the fakeroot equivalent of containers.

> What would an application do that is more secure than namespaces+cgroups?

Object capabilities, which is what Sandstorm/Cap’n Proto are based on, provides much more security than Mandatory Access Control systems while also providing a much simpler method for getting there.

Sadly the literature on OCAP is fairly poor, often being either too low level or too abstract.

The tl;dr is that OCAP systems work by assuming an application has no functionality whatsoever, and then must be passed (not sandboxed but passed) functionality, either at start time, or when the application requests it.

The easiest way to understand it is imagine if instead of being able to open a file on the filesystem by path, you had to specifically be passed the file descriptor by the OS, possibly before runtime.

Another way to think about it is thinking about the OAuth2 capabilities that you can grant an application. You authorize an application to have certain capabilities, and then the client is handed back a set of API tokens or addresses. Those are the only way it can exercise those capabilities.

It's not being sandboxed, it simply doesn't have any additional way to get access.

That seems interesting and like a technically correct way to go, but also I can see nobody adopting it on a general purpose operating system and thus rendering it useless. Getting developers to use portals already is hard enough.

Thanks for actually answering the question.

> What would an application do that is more secure than namespaces+cgroups?

You need to understand how sandboxing work.

> Docker (or Podman) is just a tool that sets up some linux primitives for you. One with a track record

A pretty poor track record.

> You need to understand how sandboxing work.

That's pretty much my job. Can you be more concrete with what you're talking about instead of this passive agressive "you don't know what you're talking about" tone?

Flatpak and Snap are pretty much using the same primitives as containers, they just don't like using the word because of existing connotations. Mandatory access controls are neat, but nobody actually uses them unless the default doesn't disturb them or they have a compliance requirement.

> A pretty poor track record.

Modern containerd, after having been split up from Docker/Moby, has a better track record than most other sandboxing tools. I mentioned a laughably bad one that the Arch wiki and many HN users still seem to endorse.

"Security" really ought not going to be much of a selling point, since no one is particularly good at it these days; I'd be shocked if this thing could actually point to meaningful, as opposed to theoretical, security advantages.

Sandstorm is really good at security. I would absolutely encourage you to download a copy and try to identify an exploitable security vulnerability. As a Sandstorm user, I'd really like to know about it!

I suppose I'm talking about marginal differences. As in, I'd be surprised if Sandstorm can strongly outdo, e.g. my own Docker + Nginx proxy manager+SSL stuff?

You will be surprised then. Sandstorm utilizes capability-based security to grant access to applications, each app is only ever running when an authorized user attempts to launch the app, and each document within a given app is isolated to it's own only-run-on-demand container.

The core difference here is that for all intents and purposes app vulnerabilities are almost wholly mitigated. The only significant type of app vulnerability which Sandstorm cannot prevent is privilege escalation within a single document, where you've shared limit access of a document with a user, say read only, and due to an app vulnerability, they've figured out how to edit it.

Since all documents are private solely to the user who created them initially, and the process isn't even running until that particular user tries to open it, there's effectively no attack surface for Sandstorm apps most of the time. When they are spawned, they're spun up at randomly-generated ethereal subdomains, and authorized solely for access by the web browser that launched them.

But again, "meaningful?" These threats seem mostly imaginary. This feels like a bunch of hardcore locks and keys between the rooms inside my house.

I understand where you're coming from, and I would encourage you to get familiar with object capabilities, as it is one of those big pieces of hitherto-ignored low-hanging fruit.

Packaging existing apps tends to be extra work, since you have to retrofit things (like user accounts). But creating brand new apps can actually be less work, because it has things built in (like user accounts).

The Go implementation of capnp is alive and well, too. I highly recommend it: https://github.com/capnproto/go-capnp

Packaging should always just be zip.

Security can just be a OTP: https://github.com/tinspin/rupy/blob/master/src/se/rupy/http...

I think the answer is that packaging apps for Sandstorm is a bad hack, as ripping out the auth system and design granularity is all hard for an existing application. The best Sandstorm apps are written for Sandstorm, and in those cases, the granularity and built-in authentication make it way easier to write an app. I wrote a Sandstorm-native app in less than an hour.

But if you built your entire application assuming you're shipping it via Docker, untangling the sheer amount of redundant garbage you need to pare down to a single-document app that accepts outside authentication and security, ends up being a ton of work to package and then maintain it long-term.

Ideally, I think having apps not made for Sandstorm originally is mostly just a strategy to get enough people operating on Sandstorm's model for people to build Sandstorm-specific apps in earnest.

I think making apps that have a very clean separation between external security code (e.g. "the claims in the JWT") and internal security code (e.g. "the app's own internal understanding of security, regardless of provider") is always a fantastic idea.

Why not just make it be a docker launcher instead?

I wrote a blog post answering that: https://sandstorm.io/news/2014-08-19-why-not-run-docker-apps

Oof... 9 years ago.

Then it would be as poor of a user experience and have as many security problems as one of the literally dozens of self-hosting tools that are just Docker launchers.

Can you share links to the major ones (I'm aware of a couple like yunohost and cloudron)? What are the most important UX issues in your opinion? Disclaimer: I'm working on a docker launcher for selfhosting and want to solve some of the current problems.

Umbrel is another relatively popular one, particularly with the crypto space.

The biggest thing is the lack of integration. Some of them have patchy SSO integration options, but most won't tamper with the app in any meaningful way, so even if you have login integration, you have to log into each app on a server, and each app is subject to that app's capabilities for things like sharing.

You end up hosting a bunch of disjointed and separate services. Sandstorm feels much more like hosting Google Docs and it's barely ever used support for third party apps/document types.

Sandstorm requires aggressive app packaging work but the payoff is significant: Apps do not have independent authentication at all, logging into Sandstorm gets you into all of your applications, and every file can be shared using the same process with other users or the public trivially.

In fact, because we break apps into "grains" or documents, we can do crazy things like allow you create Collections which comprise of documents made with different applications and then share that as a single unit with others. So I can take a couple specific Etherpad documents, a Wekan board, and a WordPress, put them into a project collection, and then share that with a collaborator with one link.

> Umbrel is another relatively popular one, particularly with the crypto space.

Impressive that Umbrel's popular because IIRC it doesn't take security as seriously as say Sandstrom. You'd think the crypto folks would at least care about that, if nothing else?

Umbrel pivoted. When it launched it actually was a Bitcoin miner, and then they added other apps, and then made the Bitcoin miner optional. And yeah, I don't know the details about the internals but a friend of mine was not thrilled with their approach. I think one specific point was that they don't support using HTTPS on the local network at all.

The issue for me with Sandstorm is that it's great until some service/app you need is missing or broken, and then you're back to manual self hosting. I always find that self hosting even one app is the pain, self-hosting more isn't that bad (once you have your box setup).

I have tried for a client who wanted to install open source app in server with sandstorm about 3 or 4 years ago, it is just very slow at the time. Hope they improved that since.

Check out fractalnetworks.co if you are looking for something similar that is still under active (commercial) development.

It's worth mentioning https://YUNoHost.org.

I've done plenty of manual self-hosting. I explored sandstorm for a year or two in the mid 2010s. It worked as promised, but the complexity of integrations, fraying, showed.

I switched to yunohost 6 years ago. I almost entirely don't think about it. I use a few services, wallabag and Uptime Kuma. Tried Nextcloud, HedgeDoc /HackMD/CodiMD, and Monica PRM because it was so painless to give them a go.

My initial motivation for exploring it, came from the hope it could install NextCloud. My attempts at installing OpenCloud and NextCloud, with scripts that would make non-idempotent changes that fail on a second run after first pass fixes, left me sensing an unfriendly forced upsell environment.

I have had to do some manual fixing to complete an upgrade or two, but it has workflows for backups, and some stringent, but fully automated configuration, sanity checking. I don't worry about the complexity.

I tried out Yunohost and I do like it in principle, however what really started to annoy me was that they decided to roll their own sso, and my impression is that it's not very good (there are some threads on the forum criticising it for being quite a mess IIRC). The issue is that because of this it doesn't always play ball with apps which allow for SSO functionality, e.g. the seafile desktop app does not work with yunohosts SSO. I wish they would just switch to an established system like authentik, authelia or keycloak. There were some issues about this in the tracker but I think the suggestions were shut down pretty quickly.

Dang. That's good to know, thank you.

My understanding is YunoHost makes absolutely no attempt to isolate apps from one another, it just helps you install stuff on a Linux box. Unfortunately that means a single flaw in a single app compromises your entire server.

Some effort has been put into adding systemd hardening per unit basis.

Every app is run by a special user created to do just that. This app user only has permissions for the app and data folder.

(I don’t have much security/hardening experience)

It’s was designed predocker and is a pretty old school setup. I remember they had issues updating Debian because the new Debian had a new php version which caused issues for some apps.

Yes, Yunohost makes installs very easy. But if something isn't working right then you got extra layers to deal with. I don't know how Sandstorm deals with this, but Yunohost taking care of the install and upgrade procedures means that you are bound to the Yunohost integration's version of the software. For instance when installing Discourse via Yunohost this version lags behind significantly. And also Yunohost disables the Discourse upgrade process, while it offers a superior experience.

I feel like we are always getting into the same trap with those self-hosting platforms. It is the same problem we faced with the Linux Desktop & Mobile. A lot of cool visions, but fragmented efforts, limited app ecosystem & low adoption. We already have Sandstorm, Umbrel, Start9, Yuno, etc. but none of them had the success they deserved.

I'm wondering if taking something like Fedora CoreOS/IoT, Cockpit, linuxserver.io images & develop a nice GUI & documentation on top wouldn't have much greater chance to succeed. People who will try to self host & will most likely stick to it are already familiar with tech & willing to tinker anyway.

Engineers love engineering, they love their own engineering when it comes to open source/free time projects, and they tend to not like the legwork of publishing, polishing and making it ready for public consumption. (Which is a lot of work on its own)

Engineers and QA/useability/marketing people tend not to mingle in these projects. I am broken record at this point, but Blender and Godot tackled this problem.

Take sandstorm, it looks like a informative website but just looking at it I see a ton of friction installing it. Whether or not that is true, but the optics are against it.

Sandstorm was actually a startup with product and marketing and we did spend a lot of time trying to make it as simple as possible to install.

The only way to make Sandstorm easier to set up would be to partner with hosting providers to offer one-click installers. In the absence of that, Sandstorm's current install is about as easy as it could possibly be given the constraint of "should run on a generic Linux host".

(Aside: People have always given Linux flak for being hard to install. But have you ever tried to install Windows from scratch? It's sooooo much harder. But no one cares because it's preinstalled on every PC you buy.)

(Aside 2: How did Chrome become the most popular browser? Sure as hell not because it's so easy for people to install. Most people don't know what a browser is. It got there by Google paying a lot of people to bundle it. It's honestly amazing that Google pulled it off, against competitors who owned their respective operating systems.)

Anyway, back in the day, Sandstorm actually offered its own hosting service, which you didn't need to be technical to sign up for. So it was actually quite easy then. But it was a first-party service. In retrospect I think building the first-party service was a mistake. It distracted too much engineering time away from actually building out the platform and ecosystem. It meant we could offer a better price point than a VPS provider would, but I think the people actually interested in the product at that point weren't so price-conscious. If I did it again I'd focus on partnerships.

That's a useful bit of feedback. Indeed I would actually say that installation is quite simple as such things go. And maintenance is dead simple, it updates itself in the background.

Does this fit your description? https://www.freedombox.org/ This is heavily coupled to Debian.

Yes in many aspects, and I guess they are leveraging the heavy lifting of Debian package maintenance

I would say containers, and especially docker, turned out to be the best solution for this space. We just need some good non-commercial tools for getting the fancy nobrainer app-managment. Everything existing now is ever commecial or still too complicated for the laymen.

This looks exciting and definitely something to look out for as an option fkr self-hosting.

Similiar and a little bit more mature is also YunoHost, https://yunohost.org/, or for professional environments, UCS https://www.univention.com/.

The one big plus for ucs is their samba server, but it's not the right choice if you are looking for an appstore to install apps from.

My personal favorite is Cloudron, as they have an app concept that only needs minimal human maintenance. And you could even combine it with an LDAP server like ucs for the user management.

When an idea like this strikes but doesn't take off there's definitely an element of "before it's time" but it's also really hard to get people to adopt opinionated development models unless it's part of a bigger language ecosystem or brand which can offer the scale of opportunity like an app store.

There's been attempts to do this without the opinions e.g deploy docker containers but the reality is we do actually need a cohesive vision for the end user for anything like this to take off. Catering to the developers alone in the self hosted model is very hard. And I know Kenton tried hosting too. It's just a tough business all around.

I used this for a few years at a previous job and really liked it — it didn't get a ton of adoption by other people there, though, unfortunately. It had a bunch of cool ideas and seemed well implemented. I'm sad that it didn't work out as a commercial endeavor.

I like how they use capability-based security [0] and use Cap'n Proto protocol. This is another technology that is slow to get broad adoption, but has many things going for when compared to e.g. Protocol Buffers (Cap'n Proto is created by the primary author of Protobuf v2, Kenton Varda).

[0] https://sandstorm.io/how-it-works#capabilities

[1] https://capnproto.org

I recently evaluated different protocol libraries for inter-language IPC. The state of Cap'n Proto is sadly quite a bit worse than Protobuf. Many languages either don't have an implementation, or it hasn't been updated for several years.

But it's such a good system, I wish we could use it.

Some language implementations are under active development, like C++, Go and Rust. Others not so much. As language support comes, these are major ones. Let's hope they can drive the ecosystem forwards into more popular use.

I don't think it's going to happen with only a couple languages with good support. Messaging is fundamental enough that you don't want to swap libraries if not necessary, which means I won't choose it if the languages our products use are not well-supported. Just as a couple of examples:

- Node (& JS in general) have three implementations. One[1] mentions in the README that it's a hacky wrapper, the interface isn't final and the implementation is slow - for 9 years now. Another one[2] without support for RPC hasn't been updated in 4 years, and the last one[3] for 10 years.

- Lua[4] has been updated sporadically over the last couple of years, but the README mentions it ONLY works with LuaJIT v2.1, not with current Lua versions.

Currently it's hard to justify using it in a long-term project, considering how much broader the language implementations for Protobuf are. They also aren't perfect, but there is a lot more buy-in.

[1] https://github.com/capnproto/node-capnp

[2] https://github.com/capnp-js/plugin/

[3] https://github.com/jscheid/capnproto-js

[4] https://github.com/cloudflare/lua-capnproto

A tough road ahead, I agree. Currently there is other work going, by the Spritely Institute [0] non-profit. They are working on standard specifications fo the Object Capability Network (OCapN) [1] and Cap'n Proto may align with that. Spritely's object capabilities vision [2] looks very promising. Their open standards approach is very early stages still [3].

[0] https://spritely.institute

[1] https://github.com/ocapn/ocapn

[2] https://spritely.institute/static/papers/spritely-core.html

[3] https://ocapn.org

That's awesome, thank you for sharing those links! An open, shared standard with non-profit backing is sorely needed. I'll cross my fingers for them!

Cap'n Proto suffers from trying to improve upon something good enough. It's a real pity, have such a tech without org weight behind it.

I mean, Cloudflare has some org weight. Just not Google monopoly weight.

Google doesn't have a monopoly on serialization formats.

Do you know who created Sandstorm?

On the other side of things, I've started using https://www.pikapods.com/ they follow the docker model but are a paid (~$2/mo) hosting provider focusing on open-source self-hostable apps. Seems to me like an easier path for getting non-techies to 'selfhost' their own apps.

Pikapods have provided my software for a while. Have not had much feedback from users yet, but no bad feedback is a good sign I guess. The person behind PikaPods was very receptive to my concerns that their website mentioning of "upstream revenue share" could be misleading (didn't apply for my project), and they quickly took action to improve things.

Super cool idea but sadly seems to have been slowly dying over the last few years :( (unless something has changed recently?)

The biggest change lately is probably: https://zenhack.net/2023/01/06/introducing-tempest.html

But yeah, Sandstorm has been in a state of "not dead but not moving fast" basically since the company went under; things picked up a bit in 2020, and I got oriented-enough on the codebase during that time to keep it floating along, but, per the post, it's never been easy going.

Anyway, I wish I were answering this question in 6 months time, when I'll be able to show off a variation of Tempest that is relatively usable and can do a few tricks that Sandstorm can't.

Just spent ten minutes delightedly reading your updates on this. It looks fantastic! I'm really excited to watch what happens next, and wish I had time to contribute.

Are there primary areas in which contributions would be most valuable, especially from those without Golang experience/skills?

I suppose that depends on what your skill set is.

At some point the project would greatly benefit from some attention from a UI/UX specialist -- I'm doing my best, but it's not what I'm an expert at. Though right now I'm mostly focused on getting enough stuff to work for it to be of interest, and someone fussing with the UI might just be distracting.

Doing app packaging for Sandstorm might be the most accessible way to help for someone who's not a Go dev -- Tempest will of course benefit from more apps when it's ready to run them, and it'd be a high impact thing for the community right now.

Tempest [0] looks very interesting. What is the current state of the project?

[0] https://github.com/zenhack/tempest

Currently Tempest can run a lot of Sandstorm apps. However, a lot of functionality one would expect or need is not implemented yet. It will be a bit before it can replace a Sandstorm server. But it's architecturally different in some fundamental ways which will make implementing new features that Sandstorm never had much easier.

You've told me about something totally new. I want to get involved with sandstorm. Exciting.

always interested in self hosted solutions, not tried sandstorm and up for giving it a go, however if I was starting a small fairly simple personal project with no need to scale can I get wheels on it with Tempest, or should I consider building on sandstorm then porting?

All of the dev tools use Sandstorm, and Tempest is not at this point, "complete". But if you were to build something on Sandstorm today, you can be reasonably confident it will work with Tempest.

Can you tell me how I can get involved with sandstorm

I've book marked Tempest :) Looks promising. Wish you luck!

This project seems like just the thing to kickstart a new era of decentralization/federation for the social web, an answer to Reddit/Twitter/etc.

This looks really interesting. Having the ability to self-host various open-source apps is great, though, for me at least, it's always a bit stressful. Without a lot of dev ops experience I'm not always confident in my setup and the upgrade process. Having a tool that simplifies self-hosting would certainly lower the "mental barrier" for more people to do it.

This is, in my opinion, the biggest gap in the market. Selfhosting shouldn't be any more difficult or less secure than running an app on your phone.

I'm a bit split on this. As an OSS enthusiast I'd certainly like for self-hosting installation and maintenance to be easier. However, from the business perspective, I also see this as just one less reason to use hosted services - which will degrade sustainability of many open source projects.

Not sure I'm understanding you correctly. Can you share an example of what you mean?

Unfortunately you are probably still better off using commercial hosted services. None of these projects really seemed to have the resources to properly deal with the security you need for an internet hosted service

After a closer look - I must agree. On the other hand, with more projects implementing bash scripts or using Docker for easier installation, maybe there's a way to make self-hosting easier without such dedicated apps.

Hosted services will always offer more convenience. If the price is fair, they are likely better options in general.

Another twist on self hosted web apps is peergos. Uses a capability based system for access and sharing. End-to-end encrypted and P2P.

App Examples - github.com/peergos/example-apps

API Docs - book.peergos.org/features/apps.html

Disclaimer: I work on the project.

Looks like Caprover https://github.com/caprover/caprover which has been around for a bit, have used in past. Any notable benefits over it?

Fromctheb readme, Caprover is developers developers developers developers.

Sandstorm is for users/admins to deploy many apps together.

I've tried sandstorm and yunohost but those didn't make me confortable enough to use in a production setting. I've been using cloudron.io for a few years and it's great. Never had issues with data loss or updates.

12*15=$180/year/person for cloudron.io is not the cheapest.

Have you considered or tried nextcloud?

I'm also using apps such as grafana, prometheus, gitlab… So nextcloud by itself wouldn't cut it. I'm willing to pay (it's $15/mo per server, not per user) because I want something reliable that I won't have to spend a lot of time on. And also because we're a company, not just a random enthusiast :)

not "/person" but "/host", right?

I saw "semantic model" and got excited, but that's at the "grain" level.

The idea of applications has been stale for a long time, it just takes a long time for people to get there.

Microsoft doesn't want it to happen quickly because they like selling Office as a package, but they're slowing decomposing it. OLE was a micro step, now with a cloud graph model and AI they're going much deeper.

Ultimately, your "table" can be generated from data in a "spreadsheet" or "database." And your AI can interact with this data precisely. At a certain level, you really shouldn't need to care where something was generated or viewed. It's data. But the more strongly it's "typed," the more accurate everything becomes.

Yes there's some hype over AI, but it is just incredibly useful, even the most basic and stumbling step of importing your documentation to an app or browser based AI to answer questions. Anything that doesn't include it as a first class consideration is last epoch, in the same category as Visicalc, 1979. Unfortunately, that includes the vast majority of Open Source. KDE was way ahead of this, but they stumbled. I hope they can catch up. Local, Open Source AI needs to leap ahead or computing is going to collapse.

So the first step is to give all the data a schema, ideally a domain-relative one so it's interoperable. See Linked Data.

It's worth mention umbrel, https://umbrel.com/

Once umbrel is setup apps are are just as easy to update and install as an iPhone. I also appreciate how it has a dependency system so apps can build on one another. Umbrel is more for personal homelab rather than sharing with friends, there is no public endpoint you would want on the clearnet, you need to VPN in, but that also makes it more secure.

That website is a very impressive piece of work, but it's also massive friction, if I may say so. "Get up and running in 30 seconds." Pf... can't even get to what they're "selling" in that time. Scroll, scroll, more scroll. A nice, to the point pitch would be nice. Same for Yuno, which people are touting in other threads here, no one seems to be getting to the point "any time soon" on these pages. Sandstorm is probably the best of the bunch at that, but even there I didn't quite get it until I came to the discussion here on HN.

Umbrel is OK. Worked good for me, indeed is relatively easy and a huge amount of apps for install. Mostly related to bitcoin.

I have to agree, the scrolljacking on this site is beautiful and horrific.

Is it something operational or it's all on pre-order?

Fancy website hints on prevalence of form over substance, although perhaps it's just me. People who are concerned about privacy and big corporations don't need fancy rotating boxes, rather clear and concise explanation of the matter.

Just my 2 cents

I installed Umbrel on a VM. It demonstrates a few interesting ideas, but at the same time a form over function is everywhere with nothing fundamental to compensate for that. So you are kind of right.

I use several of these options (cloudron, caprover, easypanel, yunohost) because one of them has an app that the others don't. Umbrel has let me get a Nostr account and relay up and running, for example.

Just keep in mind that Umbrel itself is not open source, since they prevent commercial use/distribution.

What’s involved to get additional open source “apps” into the store?

I was considering Mattermost over Rocket Chat, but it’s not currently supported/listed.

Have a look at the packaging tutorial: https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tu...

I unfortunately don't have the availability to test their solution. But I love the vision. I hope they pull through.

There's an online demo on their page. Just click and try out everyting.

I have used Sandstorm quite a bit in the past for smaller clients. It's remarkably sane and works as described. Sometimes it could be a little slow with getting updates, but I don't know if that's still a thing.

The space of Linux distros specifically for self-hosting data has always been a little fragmented, which is a shame since it's really useful for the intended audience. A bit like Linux distros in general, perhaps.

Maybe if one of the bigger distributions, like Debian or Fedora, got behind one system it would improve. But that's also how we ended up with Flatpak and Snap, so it could be either way really.

Host for free in the cloud: https://paul.totterman.name/posts/free-clouds/

I am using Caprover, and I assume Sandstorm is similar. While the idea is good, and it works well, finding supported apps is hard. Many apps have to develop individually config files for each such platform and maintain them updated. Very few platforms do it.

In the end, I find the LAMP stack the best for self-hosting, especially with an interface like cPanel. You can simply upload files and the app works (PHP), you can view the databases (PHPMyAdmin), most hosting companies support it, there are many apps built on it.

For the services at home I use https://www.runtipi.io/. I'm quite happy with it.

Suppose I'm willing to build an ecosystem of internal tools for my company. Can Sandstorm make my life easier in this kind of effort? Or is the added complexity simply not worth it? I'm curious about how I'd deal with data sharing in my enterprise if each user has a set of data "grains".

It is hard trying it figure out what path to choose.

Do you just run Docker or do you combine it with Docker Compose?

Do you instead opt for Proxmox in combination with Podman?

Maybe you opt for something simpler like this tool; Sandstorm.

Or even more complex of a setup with a K8 cluster with combined with Gitops.

It is interesting and a lot of really good tools to chose from but it is not obvious to me.

For me, the biggest blocker for using Sandstorm has been the inability to run on ARM https://github.com/sandstorm-io/sandstorm/issues/2083

Sandstorm's value prop is such that if you wanted its benefits, a one time purchase of a low end micro PC shouldn't be the blocker.

Happy to see this project still going. Loved the concept and tried it for a while, but building apps for it was very complicated at the time, which made it much less useful. Looking forward to giving it another shot.

Probably the biggest revolution in app packaging is there is now a tool that helps automate enabling an app to request outside network resources. It used to require you write some Cap'n Proto and all, now you just need to include powerbox-http-proxy in your app package, more or less.

Sorry for the silly question but I don't get it.

Is this a remote server where you can install and use web apps from third parties?

Or can you actually build a web app there so that users can employ it? Something similar to Digital Ocean.

It's a platform that you install on your own server, at home or on a VPS (Digital Ocean, etc).

The installation is a few simple CLI steps. From there everything is in the browser, including the admin. Each user, once logged in, can install whatever apps they want from the app store. Or they can upload their own if they want. This is safe because everything is containerized. Apps have to be specially designed (or retrofitted) for Sandstorm, though.

I've had pretty good experiences with https://yacht.sh/, which only does docker containers.

There is an alternative : https://github.com/ethibox/ethibox

https://www.youtube.com/watch?v=y6120QOlsfU

https://cloudron.io is a viable alternative.

So... this is a company that sells a service that lets you run an app on 127.0.0.1?

Nope. The service, like any other, is them hosting the software (Sandstorm) and the software/apps you choose to run therein.

It’s also open source, so you can choose to host Sandstorm yourself, instead of using their service.

You didn’t ask what Sandstorm is, so I’m assuming you already understand what it is.

But you run it in your data center? Is it just some pre-configured apps you can run on a machine / vm / container wherever? I mean... that's not completely without merit. But isn't this just what we used to call "software" ??

> But isn't this just what we used to call "software" ??

By way of analogy:

You could carry around a phone that has a simple Linux distro running on it. And while we're at it, what's the point of having a package repository? So we could get rid of that, and compile all our software from source. So the user experience is something like: SSH into your phone, curl down a source tarball for the calculator software you would like to run on your phone, and first make sure you have all of the build dependencies installed, and now make && sudo make install.

So what's the point of Android or iPhones?

Well, I'm very technically proficient, and yet I don't want to SSH into my phone and make && sudo make install. God help my non-techie family and friends. We all want to install software that has gone through at least some semblance of an audit, and we want to install it trivially, and we want that software to then run in a minimally privileged sandbox. While a "phone app" is technically "software", the distinguishing factor is that aforementioned features are implied when someone says "app".

So recap of what it's like to use a phone app:

- There's a distribution channel that makes it easy to search for and install the app of your choosing.

- The apps run in a sandbox. Privileges/capabilities are surfaced through a common setting UI: don't want the app to be able to send you notifications? You can toggle that in a way that the app can't circumvent.

Maybe you do or do not appreciate these features. But if you, like many, do appreciate these features, the a logical question is: is there anything like this but for software we want to use outside the context of our phones? And, well, if we're wanting this software to be accessibly not only on our phone, we should probably make this as maximally accessible as we can, and what could be more accessible than a browser based app -- now you're not limited to using it just from your phone (though that's possible too), you can access it from your laptop, or a friend's computer, or your gaming console's browser, or anywhere else where you can browse the web.

So that's what Sandstorm is, more or less. Trivially installable apps, where you can completely own your own data (if you're hosting yourself), and even if someone else is hosting Sandstorm you can trivially export your data, the whole app is sandboxed, you have a common dashboard for controlling each app's capabilities, etc.

To clarify, Sandstorm does not sell any service today. It is an open source project that makes it much easier to self-host apps on your own server -- maybe in a datacenter, maybe on a device in your home.

Once upon a time, years ago, Sandstorm was a startup, and that startup did offer a paid hosting service as an option. However, that startup shut down a while ago and the paid hosting service went away. But the open source project lives on.

(I was the co-founder of said startup.)

so essentially if i have a VM, i can just install the apps i require and then use them for my business. This sounds great but then I need to make sure i am monitoring and debugging it if something breaks ?

Also how does sandstorm makes money then ?

> Also how does sandstorm makes money then ?

It doesn't. It is an open source project. Originally Sandstorm was offered by a startup, but they stopped [0] in 2017. You can make donations though [1].

[0] https://sandstorm.io/news/2017-02-06-sandstorm-returning-to-...

[1] https://sandstorm.io/news/2021-06-17-sandstorm-community-fun...

NextCloud and OwnCloud already exists.

NextCloud and OwnCloud are productivity suites (the analogy is Microsoft Office), while Sandstorm is an operating environment (the analogy is Microsoft Windows).

Reply on news.ycombinator.com