Cloud in a Bottle turns a machine with Ubuntu into a home server where a single login opens all your apps. It’s open source under AGPL-3.0, has no telemetry, and Imbue released it on September 5th. That unified login piece is the central point, and it’s exactly what neither Nextcloud nor a Docker Compose stack gives you.
If you’ve ever set up a home server, you know the shape of the problem. You spin up Vaultwarden, then a wiki, then a photo gallery, and you end up with four separate accounts, four login screens and four different ideas of who you are. Cloud in a Bottle moves the identity boundary: it’s not in each app, it’s on the machine. You log into your instance and you’re already inside everything running on it.
What is Cloud in a Bottle?
It’s a self-hosting platform, not a standalone application. You install it on a machine with Ubuntu 24.04, point a domain at it and from there you add apps from a catalog through a web panel. Each app runs in its own rootless hardened container; the platform handles TLS, DNS, routing and authentication for all of them.
The premise of the launch post is deliberate: “Self-hosting should feel like using a smartphone that serves webapps, not a sysadmin side job.” The comparison the project is going for is that of a mobile operating system: apps isolated by default that ask permission to talk to each other.
And that second half is the more interesting part. Beyond the single login, the platform exposes “an interface to allow permissioned access to data and capabilities between different apps”. Your notes app can ask you for contacts; you grant or deny. In a stack of unrelated Docker containers, that conversation simply doesn’t exist.
Is it a real alternative to Nextcloud?
It’s worth being precise, because the launch post isn’t neutral and shouldn’t be read as a benchmark. Its author, Zack Polizzi, positions the project against four predecessors: Sandstorm as abandoned, Nextcloud as slow, YunoHost as lacking sandboxing and Coolify as container hosting without platform-level integration. Those are his characterizations, not independent tests — and the creator of Sandstorm showed up in the Hacker News thread to respond.
Setting aside the framing, the real distinction holds: Coolify and Docker Compose host containers. Cloud in a Bottle integrates them. Nextcloud does have a broad ecosystem of apps and unified login within its own world, but everything outside Nextcloud still stays outside.
The practical reading: if what you want is a mature suite of files and collaboration with a decade of apps behind it, the answer today is still Nextcloud. If what bothers you is that each self-hosted app is an island with its own password, this is exactly what scratches that itch.
The story worked: 607 points and 302 comments on Hacker News, with much of the discussion pointing less at the project than at the cloud complexity people are trying to escape.
How does it work under the hood?
One machine, one service: the router, openhost.service. Around it:
- Caddy terminates TLS on port 443.
- CoreDNS acts as the authoritative DNS server for your zone, which is what makes wildcard subdomains per app possible.
- Podman runs each app as a rootless container under the unprivileged
hostuser. - A system agent handles the privileged operations that need root.
An app receives, by default, “its own data directories and nothing else”, “no capabilities beyond the Docker defaults” and a single port on loopback. Everything else is negotiated.
Storage is split into three levels, and apps read their paths from environment variables (BOTTLE_APP_DATA_DIR and friends) instead of having them hardcoded:
/data/app_data— permanent, on local disk, with backup./data/app_temp_data— temporary on local disk, without backup./data/app_archive— archive, on JuiceFS with local or S3 backend.
How do you install it on a VPS?
You need a domain you control with access to its DNS configuration, a machine with Ubuntu 24.04 and the inbound ports 80/tcp, 443/tcp and 53/tcp+udp open. That last one surprises more than one person: the machine runs its own authoritative DNS, so you delegate the zone to it.
curl -fsSL https://raw.githubusercontent.com/cloud-in-a-bottle/cloud-in-a-bottle/main/scripts/provision.sh \
| sudo bash -s -- --domain mycooldomain.com --acme-email you@example.com
The same script works for a dedicated home server, with other flags — local HTTP only, no public certificate:
curl -fsSL https://raw.githubusercontent.com/cloud-in-a-bottle/cloud-in-a-bottle/main/scripts/provision.sh \
| sudo bash -s -- --domain lvh.me:8080 --local-http-only --open-claim
And if you’d rather not hand over a whole machine, there are appliance images .qcow2 and .ova in the releases, for QEMU or VirtualBox. The minimum is 1 vCPU, 2 GB of RAM and a 20 GB disk — something you probably already have in hardware sitting around a corner.
What are you giving up today?
The catalog is small, and the project says so without sugarcoating: “we aim to maintain a high bar, only adding things that actually deliver a great user experience, so it’s pretty small right now”, with weekly additions. At the time of publishing this note, that’s the honest constraint: if the app you want isn’t in the catalog, you package it yourself.
That packaging at least has a defined form. Any web app in a container can run on the platform as long as it includes a cloudinabottle.toml manifest that declares it; the control plane, written in Python, can also build an app directly from a Git repository instead of requiring an already-built image. The documentation includes a guide for writing that manifest, and the code lives at github.com/cloud-in-a-bottle/cloud-in-a-bottle — it’s worth reading before pointing a domain at an installation with curl | sudo bash.
It’s also the structural limit of the platform. An app has to cooperate to be hosted, and several people in the Hacker News thread pointed out that that’s precisely the constraint that limited Sandstorm: a platform that needs apps packaged for it grows at the speed of those doing the packaging.
Then there’s the license, which is worth reading carefully rather than taking for granted. The code is released today under AGPL-3.0, and Imbue finances the project by selling managed instances — the launch post commits that the self-hosted path runs “exactly the same code” and remains “first-class”. But the README declares the intent to change terms: “something like a fair source license, with the intent that personal use will always be unrestricted, while commercial use may be scoped to support a sustainable project.” At the time of publishing this note no changes have been made nor a date given. If you deploy it personally, that text sounds reassuring. If you’re evaluating it for a company, AGPL-3.0 is what you have now, not necessarily what you’ll have later — and that’s a question worth resolving before building on top.
Is it worth an afternoon?
If you already have a home server and the multiple-passwords problem bothers you, yes: the VM image makes it a low-risk experiment and the installation is a single command. If you need a specific mature app today, check the catalog first; that’s where the gate is, not in the technology.
If you’re deciding where to host what you build, our guide to hosting options is useful too: Where to Host Your AI-Built App in 2026: From One-Click to Full Control