umbrelOS 2.0 makes a homelab easier to operateumbrelOS 2.0 makes a homelab easier to operate

A home server needs controls, not just apps

Installing apps on a homelab is not particularly difficult anymore. The harder part starts when I need to isolate services, manage disks, expose something on the local network, or let an AI agent help without handing over the whole server. umbrelOS 2.0 focuses on that less glamorous but more useful side of self-hosting: making Umbrel easier to operate with some discipline.

This release adds Machines, a more capable storage manager, GPU acceleration, and a built-in MCP server. Umbrel is still designed to make self-hosting approachable, but it now covers work that previously meant leaving its interface or building another infrastructure layer around it. For a homelab used for experiments, media, or automation, that is a meaningful change.

Virtual machines with isolation and published ports

Machines runs full operating systems inside Umbrel. Virtual machines are managed from the browser, and I can allocate CPU, memory, and storage to each one. Umbrel documents ready-to-use options for Ubuntu, Debian, Fedora, Alpine, Android, and several Windows releases, while also allowing custom ISOs and preinstalled disk images.

Machines live on a private network: they can reach the Internet, but other LAN devices and other machines cannot reach them directly. To expose a service, I need to configure Port forwarding in that machine’s settings. The Umbrel-side port must be between 40000 and 49999, and it is forwarded to the port listening inside the guest.

For example, a Linux machine running SSH can be reached from the LAN by forwarding the guest’s port 22 to a high port on the host. That is useful for a disposable development environment, a separate Ubuntu box, or a service I do not want mixed with Umbrel’s main apps. It also discourages the habit of exposing an entire VM before checking which services are actually running.

Umbrel port: 40022
Port inside the machine: 22
Published service: SSH

There is an important caveat: machines start with Umbrel and consume actual CPU and memory. On self-built hardware, Intel VT-x or AMD-V should be enabled in the BIOS. If Umbrel itself runs in a virtual machine without nested virtualization, or if the guest uses a different CPU architecture than the host, Machines falls back to software emulation and performance will be much worse.

Storage is no longer an invisible choice

Storage Manager handles internal disks on systems with at least two NVMe or SATA slots. From Settings > Storage Manager, I can add drives, inspect their health, and choose between FailSafe and Full Storage. Umbrel uses ZFS underneath both modes, but they lead to very different operational trade-offs.

FailSafe is designed to tolerate a single drive failure. With SSDs, it uses ZFS RAIDZ1; with hard drives, it uses mirrored pairs and requires an even number of disks. Full Storage combines all available capacity with striping, but losing one drive means losing the whole pool.

This is not something I would choose blindly. Full Storage can make sense for reproducible data, caches, or a lab where capacity matters more than continuity. FailSafe is a better fit for photos, documents, or application data that I do not want to restore under pressure, although it still needs an independent backup strategy.

Umbrel also supports SSD acceleration when hard drives are the main storage and an unused SSD slot is available. The SSD handles small files, metadata, and read caching; it does not turn hard drives into SSDs or replace backups. The umbrelOS boot drive cannot join the storage pool either, so on custom hardware the system drive needs to be planned separately.

The GPU becomes an application resource

umbrelOS 2.0 detects NVIDIA, AMD, and Intel GPUs, including integrated graphics and Thunderbolt eGPUs. Compatible applications can use the GPU without manual driver installation, while Live Usage shows GPU and VRAM activity. That is practical for local models in Ollama and video transcoding in Jellyfin.

This is not a global switch that grants every app access to the GPU. Only applications built for GPU usage receive it, and the installation dialog marks GPU access as required when applicable. If I add a GPU after an app has already been installed, I need to restart that app before it can use the hardware.

That also draws a useful line between Umbrel and more advanced virtualization stacks. Machines cannot pass a GPU through to a virtual machine for gaming or AI workloads. Linux and Android machines can use it to render their desktop more smoothly, but the guest does not get direct GPU access.

Built-in MCP with explicit permissions

The most interesting addition for agent workflows is the built-in MCP server. From Settings > AI agents (MCP), I can connect Claude Code, Codex, OpenClaw, and other compatible clients. Each agent gets its own token, and Umbrel only displays that token once during setup.

The important part is not simply that an agent can install apps or inspect logs. It is that access can be scoped. By default, agents only receive basic information; I then explicitly grant access to selected apps, folders, the App Store, umbrelOS management, or individual machines. An agent with access to an app can manage its data, settings, and logs, and can restart, update, or uninstall it.

For Codex, Umbrel shows connection instructions in its interface. If I want to understand what is being stored, the equivalent configuration uses Umbrel’s local MCP endpoint and a token read from an environment variable:

[mcp_servers.umbrel]
url = "http://umbrel.local/mcp"
bearer_token_env_var = "UMBREL_MCP_TOKEN"

UMBREL_MCP_TOKEN must contain the token generated by Umbrel for that specific agent, not a reused password. The MCP endpoint uses HTTP on the local network even when Umbrel’s web interface is opened over HTTPS, because MCP clients do not automatically trust Umbrel’s local certificate. For an agent running outside the home, Umbrel documents using Tailscale on both ends and connecting through the server’s Tailscale IP address.

The small print

MCP is still in beta, and agents act as the system owner within the permissions they receive. They cannot shut down or factory-reset Umbrel, manage users or backups, or change networking settings, but they can make real changes to authorized apps, files, and machines. A token is not a decorative integration detail; it is an operational credential.

FailSafe is not a backup either. It protects against a drive failure, not accidental deletion, bad configuration, theft, or hardware damage to the server itself. umbrelOS can create encrypted backups to another Umbrel, a NAS, or a USB drive, and that remains the layer that makes recovery possible when the issue is not a single failed disk.

I would not upgrade without checking the storage situation first. On self-hosted installations created with umbrelOS 1.x, using multiple internal drives with Storage Manager may require a fresh umbrelOS 2.0 install, storage setup, and backup restore. After upgrading from the 1.x line, going back requires erasing the device.

umbrelOS 2.0 is not a replacement for Proxmox if I need complex network topologies, high availability, GPU passthrough, or detailed hypervisor controls. It also does not remove the need to understand which apps I install, which folders I share, or what permissions I hand to an agent. What it does offer is a more consistent way to operate a straightforward homelab without turning every task into a terminal session.

Source: umbrelOS 2.0 release on GitHub Official umbrelOS 2.0 documentation