beclab/Olares: a self-hosted Kubernetes personal cloud for local AI agents

What Olares actually solves for agent workloads

Most local AI setups break at the same point: the model runs fine, but nothing around it does. Your files sit on a NAS, your GPU sits in a desktop, your app runs in Docker on a third machine, and each piece has its own login. Olares targets that gap. The README describes it as an "open-source personal cloud OS you operate in plain language, built to run AI agents and LLMs on hardware you own." The audience is explicit: individual users and small teams who want compute, storage, networking and apps in one place rather than four.

The argument the project makes for itself is about data access. Agents are more useful when they can read your files, messages and history, and cloud AI services hold that data on third-party servers. Olares answers by putting the agent next to the data. The README names OpenClaw as a use case for running agents with local LLMs. That framing matters: this is not a model runner with a web UI bolted on, it is an operating environment where the model is one workload among several.

Kubernetes underneath, a browser on top

The mechanism is Kubernetes. The README states the platform is "powered by Kubernetes" and turns machines into a self-hosted AI platform reachable from any browser. The repository layout backs that up: top-level directories include platform/, framework/, infrastructure/, apps/, daemon/ and cli/, which reads like a split between cluster infrastructure, the application layer and the command-line tooling.

The architecture is presented as a mapping onto the three cloud layers. The README says Olares provides open-source alternatives to IaaS, PaaS and SaaS, with a diagram mapping open-source components to each layer. The practical consequence is that apps are not installed as loose containers. They come from Olares Market, described as one-click installs of open-source AI apps and models. Storage is handled by a Files app that reaches local files, synced data, connected cloud storage and external SMB or NFS shares. Networking is handled by a private VPN, a reverse proxy and public, private or internal entrances, so an app gets an HTTPS endpoint without you publishing ports by hand.

GPU handling is the part most homelabs get wrong, and Olares claims to pool GPUs and other accelerators across nodes. Three modes are named: time-slicing, memory-slicing and exclusive. That is a real scheduling decision, not a checkbox, because time-slicing suits inference serving while an exclusive mode suits a workload that needs the whole card.

Installing Olares on a Linux host

The documented Linux script path has hard requirements. At least 4 CPU cores, at least 8 GB of available RAM, at least 150 GB of available SSD storage, and Ubuntu 22.04 to 25.04 or Debian 12 or 13. The README is blunt that installation will fail on an HDD. A dedicated GPU is optional and only affects local AI acceleration.

Before touching the host, create an Olares ID in LarePass, the client app that provides secure login, a built-in VPN and file sync. Then run the installer from the Linux host:

curl -fsSL https://olares.sh | bash -

The README explains that this downloads the official installer from olares.sh and runs it with Bash. Expect a guided setup rather than a silent script, and note that piping a remote script into a shell means you are trusting that endpoint at the moment you run it. If you would rather not, the README points to platform-specific instructions for Windows, macOS, Raspberry Pi and VMs in the installation guide.

After installation, a web wizard walks you through activation. There is also a terminal route, documented as activating Olares using the Olares CLI. Once activated, the desktop is reachable at an address derived from your Olares ID. The README gives this example: if your ID is marvin123, the desktop is at https://desktop.marvin123.olares.com. Access from a phone, desktop or browser goes through your Olares ID and LarePass.

Where Olares is the wrong tool

The resource floor is the first real constraint. A 150 GB SSD requirement and 8 GB of RAM is not a Raspberry Pi experiment, even though the README says dedicated installation methods exist for that board. If your goal is to run one quantized model behind a chat page, Olares asks you to install and operate a Kubernetes-based platform to get there. That is a large amount of moving parts for a single workload.

The second constraint is the activation dependency. Creating an Olares ID in LarePass is step one of the documented flow, and the desktop address is derived from that ID under olares.com. The README does not document what happens if you want a fully offline identity or a self-hosted equivalent of that naming path, so treat the identity service as part of the setup rather than an optional convenience.

The third is maturity signalling. Releases in the recent list are versioned 1.12.7-alpha.7 and 1.12.7-alpha.6 alongside a dated build, 1.12.7-20260909. Alpha tags on the newest line mean the edge of the project moves quickly and you should expect to read release notes before upgrading. The last push to the repository was on 2026-09-10, so the codebase is current, but current is not the same as stable-tagged.

Olares against a plain NAS or a single-model server

The README anticipates the obvious comparison and asks how Olares differs from a traditional NAS. Its answer is that Olares aims at an all-in-one self-hosted personal cloud experience rather than file serving. That is a fair distinction. A NAS gives you storage and, on some models, a container runtime. It does not give you GPU pooling across nodes, per-app HTTPS entrances, or a curated market for AI applications.

The other comparison is a single-model server such as a bare inference stack behind a chat UI. That approach is lighter and easier to reason about: one process, one port, one model. Olares trades that simplicity for orchestration. You get scheduling across accelerators, storage that spans local disks and SMB or NFS shares, and system apps like Files, Vault, Market, Dashboard and Control Hub available at first login. You also inherit Kubernetes failure modes, which is the honest cost of the trade.

Licence and the cost of staying current

Olares is licensed under AGPL-3.0, per the repository. The practical implication for most self-hosters is small: you are running it, not distributing it. If you plan to offer a modified Olares as a network service to others, the AGPL's source-availability expectations are the part to read carefully. This is a pointer to the licence text, not legal advice, and the repository ships both LICENSE and LICENSE.md at the top level.

Upgrade cost is the other ongoing expense. The release cadence visible in the recent list shows multiple builds within days, including alpha tags. On a Kubernetes-based platform that means upgrade planning is not optional: you want to know whether a release touches the platform layer or only an app. The README does not document rollback, so before applying an alpha build, check the release notes for the version you are moving to. The CLI in the repository is the natural place to look for the supported upgrade path.

Editorial conclusion

Adopt Olares if you want agents and local models running on hardware you own and you are willing to give it a dedicated machine, an SSD of at least 150 GB and a real Kubernetes-shaped mental model. Do not adopt it if you only need a chat interface for a local model, or if you have no spare Linux host, since the documented path expects Ubuntu 22.04 to 25.04 or Debian 12 or 13 and fails on HDD storage. Before committing, verify your platform against the installation guide, confirm your disk is SSD, and read the activation path in the Olares CLI tutorial so you know whether you will finish setup in the browser wizard or the terminal.

Frequently asked questions

Official sources

1. beclab/Olares on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases