Open Source Cloud Computing
Renting compute by the hour is frictionless right up until the workload turns steady and predictable, and then you are paying an elasticity premium you no longer use while a provider's pricing quietly shapes how you architect everything. This category spans the whole stack you would otherwise rent: the platform that deploys your apps, the compute that runs them, the distributed database underneath, and the object and block storage behind that. The open source versions let you run each layer on hardware you already own, so provisioning, scaling, and deployment answer to capacity you paid for rather than a per-hour meter. The cost of that control is operations, which is the real thing to weigh before committing.
Coolify
Self-hostable PaaS for deploying apps, databases, and 280+ services to your own servers
TiDB
Open-source distributed SQL database with ACID transactions, HTAP, MySQL compatibility, and vector search
Dokploy
Self-hostable PaaS for deploying applications, databases, backups, and Docker workloads on a VPS
CockroachDB
Distributed SQL database with ACID transactions, horizontal scale, and PostgreSQL wire protocol support
Podman
Daemonless tool for managing OCI containers, images, volumes, and pods with a Docker-compatible CLI
Dokku
The smallest PaaS implementation: a Docker-powered mini-Heroku for your own server
Dragonfly
In-memory data store compatible with Redis and Memcached APIs, built for modern application workloads
RustFS
Distributed object storage in Rust with S3 compatibility and OpenStack Swift support
containerd
Container runtime daemon for Linux and Windows that manages image transfer, storage, execution, and supervision
Our picks
A self-run cloud is built in layers, so these picks span deploy, compute, storage, and data.
Push-to-deploy PaaS: Coolify Coolify brings a hosted-platform workflow to servers you own, connecting over SSH to deploy static sites, full-stack apps, databases, and more than 280 one-click services onto a VPS, bare metal, or a Raspberry Pi. It writes app and database configuration to your server, so deployed resources keep running even if you remove Coolify itself.
Private cloud for virtual machines: OpenNebula OpenNebula builds and manages enterprise private clouds from KVM or LXC hosts, and is widely adopted by teams moving off VMware to infrastructure they control. A single front-end node runs the services operators connect to, and it extends to containerized and edge workloads alongside plain virtual machines.
Unified storage cluster: Ceph Ceph serves object, block, and file storage from one cluster of commodity servers, replacing separate systems for each. Data is spread across nodes with replication or erasure coding for redundancy, reachable through an S3-compatible API, iSCSI and NVMe over Fabrics, or POSIX and NFS, and it pairs with Rook to run natively on Kubernetes.
Distributed SQL database: TiDB TiDB is a distributed SQL database that separates compute from storage and uses Raft consensus with multiple replicas for automated failover, so it scales horizontally and survives node loss. MySQL 8.0 compatibility lets existing drivers and tools connect, and its HTAP design pairs row and columnar storage for transactional and analytical queries in one system.
Sorting the layers before you self-host
Cloud is an umbrella here, and the first job is knowing which layer under it you are shopping for. If you want a Heroku-style push-to-deploy experience on a server you own, a PaaS like Coolify, Dokku, or CapRover is the answer, and it leaves your apps running even if you remove the platform. If you need to carve machines into many virtual machines with tenants, quotas, and networking, that is IaaS territory - OpenStack, Apache CloudStack, and OpenNebula, the last of which many teams reach for when replacing VMware.
Storage and data are their own decisions, and they are where a self-run cloud feels either boring or fragile. Ceph serves object, block, and file storage from one cluster and pairs with Rook to run natively on Kubernetes, while RustFS and OpenStack Swift focus on S3-style object storage. For the database layer, TiDB, CockroachDB, and YugabyteDB give you distributed SQL that survives node and rack failures, but each expects real operational maturity - Raft consensus and rebalancing are not free to run. Match the redundancy you configure to the failure domains you can actually afford to lose.
Whatever the layer, test the operating model before you commit, because open source infrastructure is never just an installer. Identity, quotas, upgrades, monitoring, backups, and incident response are the ongoing job, and container plumbing like containerd and Podman or backup tools like Velero and Kopia become the pieces you lean on when a host dies. Plan failure domains from day one; if one switch, rack, or storage pool can stop everything, you have a virtualization cluster, not a resilient cloud.
Related categories
Frequently asked questions
Which layer of the stack am I actually choosing between?+
This category mixes layers that solve different problems. A PaaS such as Coolify or Dokku deploys and runs your applications. An IaaS platform such as OpenStack or OpenNebula provisions virtual machines, networks, and tenants. Storage systems such as Ceph and RustFS hold the bytes, and distributed databases such as TiDB and CockroachDB hold the records. Decide which layer you need before comparing tools, because a PaaS and an IaaS are not substitutes.
Is running an open source cloud cheaper than public cloud?+
Only when utilization is high and you already fund an operations team. You trade cloud margins for hardware, power, space, spare capacity, upgrades, and round-the-clock recovery. The math favors steady, predictable workloads on hardware you keep busy. Bursty demand, global reach, and exotic managed services usually stay cheaper on a public cloud or in a hybrid design, so size the real total cost, not just the license.
How much infrastructure do I need before self-hosting is realistic?+
A lab runs on a single machine, but production needs redundant control nodes, separate storage capacity, resilient networking, monitoring, backups, and a way to rebuild a failed host. Plan failure domains from the start rather than bolting them on later. The blunt test: if one rack, switch, or storage pool can take the whole thing down, you have a virtualization cluster, not a resilient cloud.
What is the difference between a self-hosted PaaS and an IaaS platform?+
A PaaS like CapRover, Dokku, or Dokploy takes your code or container and runs it, handling routing, TLS, and databases so you never think about the machine. An IaaS platform like Apache CloudStack or OpenStack hands you raw virtual machines, networks, and storage to build on, closer to what a public cloud sells. PaaS trades flexibility for speed; IaaS trades speed for control over the whole environment.
Do I need Kubernetes to run these?+
Not for most of the PaaS options - Dokku and CapRover run on a single Docker host, and Coolify deploys over SSH. Kubernetes becomes relevant when you adopt tools built for it: Rook runs Ceph storage inside a cluster, Velero backs the cluster up, and Kubero gives a Heroku-style workflow on top. If you do not already operate Kubernetes, a single-server PaaS is far less to run.
How do the distributed databases here differ from a single Postgres server?+
TiDB, CockroachDB, and YugabyteDB spread data across many nodes with consensus replication, so they survive disk, machine, and rack failures and scale horizontally by adding nodes - things a single server cannot do. CockroachDB and YugabyteDB speak the PostgreSQL wire protocol and TiDB targets MySQL compatibility, easing migration. The cost is operational complexity: rebalancing, multi-replica storage, and tuning that a lone Postgres never asks of you.
What should I know about the storage options before choosing?+
Match the access pattern to the system. Ceph serves object, block, and file from one cluster and suits mixed needs, while RustFS and OpenStack Swift concentrate on S3-style object storage for backups and unstructured data. VM boot volumes, application data, and backups stress different systems, so check how each handles a lost storage node and test a restore into a separate environment before real data piles up.