Self-hosting sucks. It's high-skill and high-maintenance to a degree that most non-professionals would never consider it. And most pros are too busy to bother. Still, self-hosting is critical if we're going to escape today's digital feudalism. To make a future of digital self-ownership feasible, self-hosting has to get easier.
Enter Cloudron. It's a platform that simplifies self-hosting, abstracting away system level details and presenting an app store-style user experience. I've spent the last week with it and I've been impressed.
The blog you're reading now is self-hosted, running on a Ghost app installed and managed by my Cloudron instance. In this post I want to share my experiences getting this arrangement up and running and why I think you might want to too.
Like Cloudron itself, this post assumes you're a reasonably technical person; not necessarily not a professional programmer or sysadmin, but that you already own a domain name or know how to get one, and that you're able to get a Linux server—VM or otherwise—running somewhere on the public internet.
Installation is simple, but comes with a constraint—you must run a specific version of Ubuntu as an operating system (
20.04 LTS at time of writing). I was initially put off by this requirement (I prefer running Debian), but on further consideration, it makes sense that Cloudron locks down choice at the OS level—it's the only way to guarantee a reliable "just works" experience at an app store level.
The first step, then, is to run Ubuntu somewhere and install Cloudron on it. Certain providers like AWS and DigitalOcean offer VM images with Cloudron pre-installed, so keep that in mind if it's an attractive option for you.
Once installed, you'll visit an admin web interface to provide Cloudron with a domain you control and information about how to manage subdomain DNS records for each of your installed apps. If you use a provider like Cloudflare or Gandi that provdes an API for DNS management, Cloudron will integrate with it directly—this is very slick—otherwise a wildcard entry will do.
With those two steps complete, you're up and running with your own app store, ready to install any of 100+ self-hosted web apps and services. Here's what mine running at my.beams.io looks like:
This is where Cloudron begins to shine, making standing up a public internet service nearly as easy as installing a smartphone app. Here's what it looked like to install the Ghost app powering this blog:
Try it yourself in 90 seconds
Cloudron operates a public demo instance anyone can use. It took me 89 seconds there to install and run Ghost. Try it yourself:
- Log in to my.demo.cloudron.io with
- Search for the
Ghostapp and install it. Name it e.g.
- Wait ~30 seconds until the app is is labeled
- Click on the app to see it live at
As you can see, installation is dead simple. You don't need to know anything about an app to install it. In this way, Cloudron really does bring smartphone-level ease of use to self-hosting. If, however, this is sounding a bit naïve or simplistic, it's for good reason—running and managing an internet service is inherently more complex than a running a smartphone app. Among other things, you're going to need:
- logs and terminal access
- remote backup and recovery
- resource management, e.g. memory and cpu quotas
- single-sign on across apps
- alerts when problems arise
Cloudron doesn't pretend this complexity doesn't exist. It just doesn't force you to deal with it up front. It packages and integrates it in a way that a non-professional (or busy pro) can manage with relative ease. Smart defaults are in place, low-level access is available and you can discover and tweak it all on an as-needed basis. For example, here's a quick tour of some of the management facilities for the Ghost app behind this blog:
After a week of running several apps on Cloudron, I've been surprised how easy they've been not just to install, but also to manage. I've had to troubleshoot a few problems, monitor logs, etc, but never needed or wanted to drop down below the Cloudron interface to do it.
In this and the following sections, I want to share the various pros and cons I've come across in getting my hands dirty with Cloudron. This isn't meant to be a comprehensive list; it just reflects my own considerations thus far.
Huge time saver. Cloudron succeeds in its goal of making self-hosting easier in a dramatic way. I've quickly stood up services that I've always wanted like my own GitLab and Matomo instances, but had never gotten to before because of the effort I knew it would take. The benefits of being able to instantly install and easily administer services like this is hard to overstate. It's made all the difference for me in taking self-hosting seriously, and I think it can do the same for many others.
Timely app updates. I've been impressed to see how quickly the team makes new versions available in the store when an underlying app ships a release. Without exception, the apps I've been interested in running have been up to date with the latest version.
Thriving community. I've had a great experience interacting with the team and community so far, mainly via the forum. Responses to my questions have been prompt and helpful.
It costs money. Yes, this is a pro. Cloudron has a user-focused, (mostly) privacy-friendly business model and that's a good thing. Quality products like this are not free to create and maintain; if we want nice things, we have to learn to pay for them, and I'm happy to support the project with my $180 yearly subscription.
No lock-in. Should you want to move an app away from your Cloudron instance, there's nothing keeping you from it. From an end-user perspective, there is nothing Cloudron-specific about the apps you run. They function as they would on any other platform and can be migrated transparently.
Rich feature set. It's beyond the scope of this post to dig into all of Cloudron's functionality, but suffice to say I've been impressed how mature and polished the feature set is, especially given that Cloudron still feels relatively unknown.
Operating system constraints. As mentioned above, Cloudron imposes a strict requirement about running a particular version of Ubuntu. In addition, admins are advised not to manage their own package updates and to leave everything to Cloudron instead. From the
motd at login:
NOTE TO CLOUDRON ADMINS ----------------------- Please do not run apt upgrade manually as it will update packages that Cloudron relies on and may break your installation. Ubuntu security updates are automatically installed on this server every night. Read more at https://docs.cloudron.io/security/#os-updates
For these reasons, it's probably advisable to dedicate a (virtual) machine to Cloudron and to run nothing else on it. You'll be going with the flow if you treat it the machine largely as a black box managed by Cloudron. This isn't necessarily a "bad" thing, but I list it here because it seemed like a negative to me at first. Now it seems like a good tradeoff.
A privacy hole. Your Cloudron instance phones home to Cloudron-the-company (Cloudron UG) for info on new apps and updates. A subscription plan paid via credit card is required to install more than two apps and this means Cloudron UG knows which apps you've installed and your true identity. This problem could be solved by supporting payment in bitcoin and an option to do app updates over Tor.
Automatic app updates. This is a convenient default, but goes a step too far for me. I want to have the opportunity to at least look at a changelog before upgrading an app I depend on. You can turn it off on a per-app basis or globally in
Settings > Updates. Your instance will still notify you by email when new app versions are available.
Not quite open source. When I first encountered Cloudron I was under the impression that it was free and open source software (FOSS), and indeed it originally was. Only later did I realize that the project license changed in early 2019 from the AGPL to a proprietary one. This "Cloudron License" stipulates that although Cloudron's frontend and backend sources remain publicly available and developed in the open, users may not run them in production unless they pay for a subscription. This restriction classifies Cloudron as "source available" versus free and open source.
A lengthy forum thread from mid-2020 asks Why not make Cloudron fully open source again? Comments from the founders indicate that choice to change the license was a pragmatic one, and that while they are not entirely opposed to returning to a FOSS license, they have not yet seen sufficient benefit in doing so.
I sympathize with the founders' need to ensure a steady revenue stream for their work, and I must concede that perhaps the current arrangement is the best one for them right now. With that said, I think it's reasonable to expect that many users would pay for a subscription even without proprietary licensing, particularly if that subscription entitles them to additional services like priority support. A useful analog may be the way that millions of users pay for WordPress.com hosting even though WordPress itself is licensed under the GPL.
Having considered this quandry, I've decided to carry on using Cloudron because my most important requirement is auditability of the source, and that remains possible under this scheme. I'm concerned, though, that on a long enough timeline, Cloudron will be supplanted by another, fully FOSS alternative, particularly if Cloudron's overall app store model for self-hosting catches fire like I think it can.
In a word, none.
Sandstorm is a similar app-store self-hosting platform. It has ambitious ideas, but takes a more intranet-like approach and is now only minimally developed, with few apps supported and many out of date. My initial excitement and subsequent disappointment with Sandstorm sent set me searching for alternatives and I found Cloudron as a result—thanks in part to @balajis's tweets about it.
Nextcloud may seem similar, as it provides a platform for self-hosted apps and services. It isn't—it's in a different category. From Cloudron's point of view, Nextcloud is just another app in the store.
HomelabOS looks like an interesting project, also having 100+ apps available, but appears less mature and more focused on an on-premises deployment with its "offline-first" approach.
With no significant competition, I see Cloudron as a zero-to-one phenomenon, a first mover. Network effects matter less in a self-hosting world, though, so I don't see why there couldn't be real competition in the future, particularly if it has a better open source story than Cloudron does today.
Adoption and awareness
Cloudron is far more mature and useful than its current ~600 Twitter follower count would suggest. The website claims that "thousands of organizations use Cloudron" and while I have no reason to believe that's not true, I spend a lot of time in decentralization circles and I find it odd how few people I know had ever heard of it.
It appears that the simplest explanation to this paradox is correct one: that Cloudron has been executing quietly and competently for a long time, servicing a large enough customer base to pay the bills, and hasn't needed to draw a lot of attention to itself.
In any case, it looks like Cloudron is well-positioned to take on a next, larger wave of adoption as millions look for alternatives to big centralized tech platforms. Perhaps, as @balajis suggests, self-hosting will see a comeback with Cloudron playing a significant role.
If you like what you've seen here and want to use Cloudron yourself, start with the installation instructions. Feel free to add a comment below linking to any useful service (e.g. blog) you end up self-hosting. It would be cool to see what springs up out there as people read this.
- Cloudron UG could accept bitcoin payments via their own self-hosted BTCPay Server instance. It's been suggested here and here to include it in the app store. ↩
- In that it doesn't conform to the letter and/or spirit of the official definitions of free software and open source software. While source available isn't a very common term in the industry, it isn't without precedent. See this list at Wikipedia, and note that some prominent projects like GitLab EE are defined as "source available", often as part of an "open core" business model.↩