# MicroCloud turns three Ubuntu machines into a private cloud

> canonical/microcloud is a Go tool distributed as a snap that configures LXD for virtualization, MicroCeph for distributed storage and MicroOVN for networking into a small private cloud in a few prompts, with a single init command and a join command for the other members. It is aimed at small clusters, edge sites and test labs, and it asks for three members before it calls a deployment production.

**canonical/microcloud** — Automated private cloud based on LXD, Ceph and OVN

- Repository: https://github.com/canonical/microcloud
- Website: https://canonical.com/microcloud
- Stars: 545 · Forks: 89
- Language: Go
- License: AGPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/canonical-microcloud

## One snap that configures LXD, Ceph and OVN together

MicroCloud creates a lightweight cluster of machines that operates as an open source private cloud. The mechanism is composition rather than invention. It combines LXD for virtualization, MicroCeph for distributed storage and MicroOVN for networking, and all of them are configured automatically by the MicroCloud snap for reproducible deployments. The README is explicit about what that snap drives, since it drives three other snaps, and the result is an automated deployment of a highly available LXD cluster for compute, with Ceph as the storage driver and OVN as the managed network. Once the cluster is up, members can run full virtual machines or lightweight system containers, and the README claims bare-metal performance for them. The value proposition in the README is speed and simplicity of deployment, plus the properties that come with the components, high availability, automatic security updates, self-healing clusters and fine-grained access control. The audience is explicit too, since MicroCloud is designed for small-scale private clouds and hybrid cloud extensions, and its simplicity makes it a fit for edge computing, test labs and other resource-constrained situations.

## A three member floor before anything counts as production

The requirements section is short and one number in it decides whether the project fits you. MicroCloud can be deployed on machines running Ubuntu 22.04 or newer, and a cluster can consist of a single cluster member for a testing deployment, while a production deployment requires a minimum of three cluster members. That is the whole constraint, and it exists because the components underneath need a quorum to do their job, though the README does not spell that out. For an evaluator, the practical consequence is that a laptop or a single virtual machine is enough to try the product, and not enough to run it as a service. The full list of requirements is in the pre-deployment requirements page of the MicroCloud documentation, and it is worth reading before anything else, because the snap model and the storage and network choices have implications for your hardware. There is also a subtlety in the snap arrangement itself, since installing the MicroCloud snap pulls in the other three snaps that it drives, so the versions of LXD, MicroCeph and MicroOVN you end up with are the ones Canonical pinned, not the ones you would choose yourself.

## Install four snaps, then init and join

The getting started path is short. You install the LXD, MicroCeph, MicroOVN and MicroCloud snaps, which can be done in one command:

```bash
snap install lxd microceph microovn microcloud
```

On the first machine you start the bootstrapping process:

```bash
microcloud init
```

On every other machine in the cluster you run the join command:

```bash
microcloud join
```

Following the CLI prompts, a working MicroCloud is ready within minutes, according to the README. The prompts are where the real decisions are made, so it is worth knowing what they will ask before you start. During initialization, MicroCloud scrapes the other servers for details and then prompts you to add disks to Ceph and to configure the networking setup. At the end of that process you have an OVN cluster, a Ceph cluster and a LXD cluster, and LXD itself has been configured with both networking and storage suitable for use in a cluster. In other words, the cluster formation, the storage definition and the network definition are all part of the same guided flow rather than three separate configuration exercises. The documentation links for installation and initialisation, plus a tutorial that demonstrates the basics, are the places to go for the full command reference.

## Networking defaults to OVN with an Ubuntu fan fallback

The networking story is where a small cluster differs from a large one, and the README handles it in a short section. By default, MicroCloud uses MicroOVN for networking, which it describes as a minimal wrapper around OVN, the Open Virtual Network. If you decide not to use MicroOVN, MicroCloud falls back on the Ubuntu fan for basic networking, which is the sensible choice for a small lab where the OVN underlay is more complexity than the workload deserves. On top of that baseline, you can optionally add three dedicated networks, and the names in the README are worth memorising because they come up in the setup prompts. The first is a network for Ceph management traffic, also called public traffic. The second is a network for internal traffic, also called cluster traffic. The third is a network for OVN underlay traffic. Separating these is what keeps storage replication, cluster heartbeats and the virtual network underlay from sharing a single path, and the cost is that each additional network has to be planned for in terms of interfaces and addresses.

## The Go side: microcloud, microcloudd, microcluster and dqlite

The repository is a Go project, and go.mod names the module github.com/canonical/microcloud/microcloud and asks for Go 1.27.2. The dependency list shows what the tool is made of. It pulls in canonical/lxd, canonical/microceph/microceph, canonical/microcluster/v3 and canonical/microovn/microovn directly, so the MicroCloud code talks to the same libraries the other snaps run. The cluster layer comes from microcluster, and the Makefile shows where the consensus layer comes from too, since a deps target retrieves dqlite, with raft, from the canonical/dqlite repository and builds it with autoreconf and configure before the Go build proceeds. The client side is a terminal interface, with charmbracelet bubbletea, bubbles and lipgloss in the dependency list, and the service side uses gorilla/mux and gorilla/websocket. The Makefile also reveals the two binaries, microcloud and microcloudd, each built with the agent build tag, and a separate build-test target that uses a test tag and enables feeding console input from a file. The repository layout is conventional, with api/, client/, cmd/, database/, multicast/, service/, snap/, snapcraft/, test/, demos/, doc/ and version/ directories, plus AGENTS.md, a .golangci.yaml, revive.toml and a SECURITY.md. The licence is AGPL-3.0, and the COPYING file at the root is the licence text.

## Where MicroCloud is the wrong tool

The cases where it does not fit are structural rather than marginal. A single machine is one of them, because the product is a cluster, and while one member is allowed for testing, a production deployment needs three, so if your requirement is one box with a few containers then a plain LXD install is a much smaller decision. A second case is an environment that cannot take snaps, since the whole deployment model is snap based, the MicroCloud snap drives three other snaps, and the snap packaging sources live in a separate repository, microcloud-pkg-snap. A third is a team that needs to run something other than a small private cloud, because the components are chosen for a specific scale, and the README positions MicroCloud for small-scale private clouds, hybrid cloud extensions, edge and test labs rather than for large deployments. The alternative to MicroCloud is the hand-built route, installing LXD, MicroCeph and MicroOVN yourself and configuring the cluster, the storage pools and the network by hand. The difference in approach is exactly the value proposition. The manual route gives you full control over versions, interfaces and layout and it has no snap or AGPL-3.0 constraints, but every one of the three clusters has to be made to work together by hand. MicroCloud trades that control for a repeatable, prompt-driven path to the same end state.

## Release lines, cadence and what to pin

The release list shows two long term support lines running in parallel, which is the single most useful fact for an operator. MicroCloud 3.4.0 LTS was released on 2026-10-19, MicroCloud 3.3 on 2026-08-26, and MicroCloud 2.1.4 LTS on 2026-08-26, so the LTS streams receive their own maintenance while the current stream moves faster. The repository is not archived and the last push was on 2026-10-22, days after the 3.4.0 LTS tag, so the cadence of work and of releases is easy to follow. For a deployment that must stay up, the choice is between pinning an LTS line and accepting that upgrades then come at LTS pace, or following the current stream and taking more frequent change. The Go build system in the repository is the part that most affects a self-build, since the deps target retrieves and compiles dqlite with raft before the Go build, and the build produces both the microcloud client and the microcloudd daemon with the agent build tag, while the check target runs static checks, unit tests and the system tests in the test directory. Nothing here is version-agnostic advice, it is the shape of the repository as it stands today, and it is worth reading the installation and initialisation documentation in canonical.com/microcloud/docs/latest before you commit a hardware purchase to it.

## Conclusion

MicroCloud fits a team that wants a real clustered private cloud on a handful of Ubuntu machines without hand-configuring LXD clustering, Ceph and OVN together, and that can live with snap packaging and a three member minimum for anything production. It does not fit a single server experiment, where a plain LXD install is simpler, and its AGPL-3.0 licence needs review before you run it as a service for others. Before deploying, read the pre-deployment requirements in the MicroCloud documentation and confirm your machines are on Ubuntu 22.04 or newer, since the last push was on 2026-10-22, days after MicroCloud 3.4.0 LTS was released.

## FAQ

### How do I install and bootstrap a MicroCloud cluster?

Install the snaps with snap install lxd microceph microovn microcloud, then run microcloud init on the first machine and microcloud join on every other machine. The prompts let you add disks to Ceph and configure networking, and the result is an OVN, Ceph and LXD cluster.

### How many machines does a production MicroCloud need?

The README says a cluster can consist of a single cluster member for a testing deployment, and that a production deployment requires a minimum of 3 cluster members. Machines must run Ubuntu 22.04 or newer.

### What happens if I do not want OVN networking in MicroCloud?

By default MicroCloud uses MicroOVN, a minimal wrapper around OVN. If you decide not to use MicroOVN, MicroCloud falls back on the Ubuntu fan for basic networking, and you can optionally add dedicated networks for Ceph management traffic, internal cluster traffic and OVN underlay traffic.

### What licence is MicroCloud released under?

The repository is licensed AGPL-3.0, with the licence text in the COPYING file at the root. Check the terms yourself if you intend to run MicroCloud as a service for other people.

## Sources

- [canonical/microcloud on GitHub](https://github.com/canonical/microcloud)
- [License: AGPL-3.0](https://github.com/canonical/microcloud/blob/main/LICENSE)
- [Project website](https://canonical.com/microcloud)
- [README](https://github.com/canonical/microcloud/blob/main/README.md)
- [Releases](https://github.com/canonical/microcloud/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/canonical-microcloud