One server holds the desktop, workspaces, and app catalog
AgentVerse OS treats a personal server like a browser-accessed developer machine. Its desktop opens on a laptop, tablet, or phone. Each project gets an Incus container, Docker inside it, VS Code, a terminal, and agents such as Codex or Claude Code. Stopping a workspace preserves it, so an agent's files and processes remain on the server when you close the browser.
The same interface manages a catalog of 944 self-hosted apps assembled from Runtipi, Coolify, Umbrel, and six hand-written manifests. Coder controls workspaces, Komodo deploys app stacks, Caddy handles routes, and Tailscale supplies private network access and certificates. The Rust cloudd service coordinates those pieces and embeds the Svelte desktop in its binary.
This is a personal cloud in the literal sense, not a hosted account. The README says nothing is exposed directly to the internet, and external services must run on the user's server to fit the design. Open issue 2 illustrates that boundary: a commercially licensed self-hosted memory service did not meet the project's open-source Store requirement.
What happened when we ran it
Our sandbox installed 363 Rust packages for commit 8a96c0b in 19 seconds. Compiling the cloudd project took 150 seconds. Cargo then ran 80 tests in 25 seconds, and all 80 passed. The environment was an unprivileged container with 3 CPUs, 12 GB of RAM, no secrets, and the project's Rust lab image.
The checkout contained 3,365 files, about 17,316 lines of source, and occupied 47.1 MB. A tests directory was present, while the scan found 0 CI workflow files and no Dockerfile. Passing 80 core tests is useful evidence for the Rust control plane. It says nothing by itself about a fresh host installation, live containers, browser behavior, or restoration after disk loss.
We did not install ZFS, join Tailscale, start Incus, deploy Coder or Komodo, or create a workspace. We also did not run the Svelte desktop build. The lab measurement covers cloudd, because the supplied project path was ./cloudd/. That boundary matters when a 150-second successful build sits inside a system made of several independently operated services.
The installer wants a clean host and an explicit disk
The documented floor is Ubuntu 22.04 or newer with at least 8 GB of RAM, a Tailscale account, and preferably a separate disk for ZFS. Installation runs with sudo and receives that disk through DISKS=/dev/disk/by-id/.... The sequence checks the host, prepares ZFS, installs Docker and Incus, authorizes Tailscale, then brings up Coder, Komodo, edge routing, the core, catalog, and workspace template.
That is a lot of host authority for a young project. Use a machine whose data you can afford to rebuild, identify the disk by its stable path, and read the installer before giving it sudo. The v0.2.0 release provides a prebuilt x86-64 package, avoiding the 363-package Rust build and separate desktop compilation, but it does not remove the host changes.
The first-run browser wizard completes setup after the server receives a Tailscale name and certificate. Updates arrive through the desktop or agentverse-update, with a rollback if the new core fails to come up. Those are good operating ideas. Their evidence is still bounded by the README's statement that the project lives on one test box.
Capabilities keep service addresses out of projects
A project asks for a named capability such as storage.s3, llm, or notify. AgentVerse OS then connects the workspace gate to the selected provider's network and injects the relevant environment variables. Code can call a stable internal address while the operator swaps the app behind it. Seven core entities and four contracts describe this routing model.
The gate is the only door into each workspace, and every Store app receives its own network. This is clearer than dropping all containers onto one shared bridge. It also means the security claim depends on correct behavior across Caddy, Docker, Incus, Coder, Komodo, and the Rust API. Our 80 passing tests cover contracts and rendering in the core, not an adversarial isolation review of that full chain.
Agent tools authenticate with the user's existing subscriptions. That avoids putting a shared vendor key into the platform, but each agent still runs inside a powerful development workspace. Review its file, network, and Docker access as carefully as you would on a normal server. Isolation between projects is more useful than an attractive desktop if the boundaries are understood and tested.
Backups exist, but disaster recovery is unfinished
AgentVerse OS can schedule ZFS snapshots, copy data to a restic repository taken from a snapshot, and roll back a single app. Backups start disabled. The status table says remote repositories and whole-system restore are not done. A backup button therefore should not be mistaken for proven recovery after the host or primary disk disappears.
Before storing important work, test an app rollback and export irreplaceable repositories somewhere outside the server. Keep agent configuration and secrets in a recovery plan that does not depend on opening the AgentVerse desktop. The missing whole-system path is a stronger adoption limit than any unfinished widget because this platform is meant to become the place where other services live.
Version 0.2.0 is honest about being for one person
The first public release, v0.2.0, shipped on September 12, 2026. GitHub showed 973 stars, 1 combined issue and pull request, and a last push on the release date when checked. The README labels it alpha 0.2 and says there are no user accounts or permissions. A second user is explicitly listed as not yet supported.
That leaves a clear buying decision. One technical user with spare hardware can learn from a coherent attempt to join remote workspaces and self-hosted apps. A family or company cannot safely map its access model onto software that has no accounts. Our clean 80-test run earns AgentVerse OS a lab machine, while the single-box history and incomplete recovery keep it away from production data.