Cloud in a Bottle: self-hosting's real problem was never install
A new open-source personal cloud from Imbue bets that unified auth, not a one-click installer, is what self-hosting has been missing. Here's what that changes for Sri Lankan builders.
Every self-hosting project I have tried in the last decade solved the wrong problem. They made installing ten apps easy and left me to run ten separate logins, ten update cycles and ten backup scripts. That is where the enthusiasm dies, usually around week three.
So the launch of Cloud in a Bottle, announced on the project's blog by the company Imbue, caught my attention for one line in particular: log into your instance and you are "automatically logged into all your apps."
🔍 What actually shipped
Strip the framing away and the architecture is deliberately boring, which I mean as praise. The post describes it as "just an Ubuntu machine with a web server that hosts a dashboard and routes HTTP(s) requests to containerized apps."
| Fact | Detail |
|---|---|
| Licence | AGPL-3.0 |
| Isolation model | Rootless, hardened containers |
| Auth | Single sign-on across every installed app |
| Telemetry | None |
| Install targets | Cloud VPS, VMs, or bare metal |
| Development time before launch | 6+ months, privately |
| Business model | Free self-host, plus paid managed instances (trials include a $10 credit) |
The post is also openly rude about the alternatives, calling out Sandstorm as abandoned, Nextcloud as unreliable, YunoHost as insecure and Coolify as poorly integrated. You do not have to agree with all four verdicts to recognise the pattern being described.
🔑 Unified auth is the feature, the installer is not
I want to be precise about why this matters, because "one-click install" has been the pitch for years and it has never been enough.
A dashboard that installs Nextcloud, Vaultwarden and a wiki in three clicks still leaves you with three identity systems. The cost of that shows up later:
- Three password resets when someone leaves your team.
- Three places to enable 2FA, one of which you will forget.
- Three sets of session cookies with different expiry behaviour.
- No way to say "this person can reach the wiki but not the password vault" in one place.
The post compares the optional integration APIs to what a smartphone OS gives apps. That is the right comparison. Android is not valuable because installing an APK is easy; it is valuable because every app can assume an account, a permission model and a share sheet already exist.
Key takeaway: self-hosting has been an install problem in marketing and an identity-and-operations problem in reality. A project that treats auth as platform infrastructure is attacking the part that actually causes abandonment.
💰 Why the cost case reads differently on an LKR salary
For a developer paid in Sri Lankan rupees, SaaS subscriptions have two costs, not one. There is the sticker price, and there is the friction of paying it: a card that works for foreign currency, headroom under whatever limit applies to it, and a rate you did not choose.
Running your own box changes the shape of the spend rather than just the size of it:
| Managed SaaS | Self-hosted on your own VPS | |
|---|---|---|
| Billing | Per user, per app, per month | One server bill, regardless of app count |
| Currency exposure | One USD charge per vendor | One USD charge total |
| Marginal cost of app #6 | Another subscription | Usually zero |
| Cost when you stop using it | Still billed until cancelled | Still billed until destroyed |
| Failure recovery | Vendor's problem | Yours, at 2am |
That last row is the honest one, and I will come back to it.
Where self-hosting genuinely does not pay is when the workload needs hardware you cannot amortise. Running an open LLM is the clearest example: a rented GPU has a floor price whether you send it ten requests or ten thousand, and the crossover point against a per-token API is often much further out than people assume. If you are weighing that specific decision, our AI self-hosting vs API cost calculator does the break-even math in both USD and LKR. Documents, notes, bookmarks and a wiki are a different story. Those are cheap to host and expensive to rent.
⚠️ The part the launch post is honest about
Credit where it is due: the post does not oversell. It names its own chicken-and-egg problem. The catalogue of curated apps is described as "pretty small," growing weekly, and building for the platform today needs "technical familiarity (or a coding agent)."
Add the things no platform can outsource for you:
- Backups you have restored at least once. An untested backup is a belief, not a backup.
- Patching. Rootless hardened containers reduce blast radius; they do not apply updates for you.
- Uptime expectations. If your family's photos live on it, you are now on call.
- Exit plan. Know how to get your data off before you put anything important on.
If you want a mechanical starting point, the boring version works fine:
# nightly encrypted snapshot to object storage, 02:30 server time
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Our cron expression builder will translate that schedule if you would rather see it in plain English before trusting it.
⚖️ The AGPL clause worth reading before you build on it
AGPL-3.0 is not an incidental detail. It is the licence that closes the "we modified it but only run it as a network service" gap in the GPL. Practically:
- Self-hosting it for yourself or your team: no obligations triggered.
- Modifying it and offering it to users over a network: your modifications are covered.
- Building an app that runs on the platform: depends entirely on how you link to it, and that is a lawyer question, not a blog question.
For a small Sri Lankan studio thinking about offering a managed version to local clients, this is the clause to read first, not last. Imbue selling managed instances themselves is the tell: AGPL plus a hosted tier is a deliberate structure, not an accident.
💡 What this means for you
If you are a student or a solo developer here, I would not migrate anything you depend on today. The catalogue is small by the project's own admission, and a two-week-old platform is not where your dissertation should live.
What I would do:
- Spin it up on a cheap VPS you can destroy, and put something genuinely low-stakes on it: bookmarks, a scratch wiki, a media library.
- Watch the app catalogue for three months. Platform bets live or die on third-party apps, and that curve is visible early.
- Treat it as a portfolio exercise. Running containerised services behind a reverse proxy with SSO is a real skill, and it reads better on a CV than another tutorial project.
The idea worth taking from this launch, even if the project itself does not survive, is the diagnosis. Self-hosting never lost on installation difficulty. It lost on the tenth login prompt.