obacht consists of four parts: a small agent running on the respective device, a web app through which the devices are managed, a native app for macOS, and a gateway in the EU through which the devices are reachable from the outside. Together they take over the parts of self-hosting which otherwise require an administrator: installation, updates, certificates and remote access.

The following describes the main processes as they appear in the default easy mode, as well as what happens in the background along the way. Since obacht is currently in a closed pilot phase, some of the details may still change.

Supported are Raspberry Pis, Linux machines such as old laptops or mini PCs, and Macs with Apple silicon. After choosing the type of device and giving it a name, a personal device key is created once in the browser and protected with a passphrase. This key never leaves the browser and is used to sign all later changes to the device. The device in turn only accepts changes that are signed with exactly this key.

How the agent gets onto the device depends on the hardware. For a Raspberry Pi, a set of prepared files is copied onto a freshly flashed SD card, so that neither SSH nor a terminal is necessary. A Linux machine is connected with a one-time install command, which remains valid for seven days. On a Mac, a native app is installed, which runs the hosting environment in a lightweight Linux VM and connects itself via the browser. In all cases, the device then establishes an outbound connection to obacht and shows up in the dashboard after a few minutes.

The catalogue currently contains more than sixty open-source applications in seven categories, ranging from personal cloud storage and password managers to websites, collaborative tools, design software and local language models. Each of these apps is described by a manifest, which is signed by the registry and pins the exact versions of the container images used. Should a manifest be altered on its way, the device would refuse the installation.

The installation itself comes down to a few decisions on a single page: on which device the app should run, under which address it should be reachable, and a few settings such as an admin password, which are prefilled where possible. After unlocking the device key, the installation is signed in the browser and passed on to the device by the API, which itself only relays it. The device checks the signature, installs the app and reports back every step, from reserving the address to issuing the certificate. At the end, the app is reachable under its own address and can be opened on a smartphone via QR code.

Every app gets its own web address, which is composed of the name of the app, the username and the obacht domain, for instance nextcloud.demo.obacht.space. Alternatively, apps can be published under one's own domain, either as a single address via an A record, or as a whole protected zone, which is verified once via a TXT record and can then be used for any number of apps. In all cases, the certificate is issued directly on the device via Let's Encrypt, so that the gateway only sees the name of the requested address, but not the content.

The interface comes in two modes. The easy mode uses plain language and is oriented towards the logic of an app store: apps instead of templates, web addresses instead of domains, a device key instead of SSH keys. The advanced mode in turn shows what lies underneath, such as services, events, logs, monitoring, the raw templates, a file browser and a terminal in the browser. The idea here is not to hide the complexity, but to make it unfoldable step by step for those who want to understand what is happening on their device.

On macOS, obacht runs as an app in the menu bar. The apps themselves run inside a bundled Linux VM, while local language models via Ollama run natively on the graphics chip of the Mac, which would not be possible inside the VM. The menu bar shows whether everything is running and how much traffic has been used, and allows pausing the device; the app window lists the apps hosted on the Mac together with their addresses. In addition, a domain can be bound to a local port, so that, for example, a development server on the Mac becomes reachable under a real address.

The following screen recording shows the whole process on a Mac mini in about two and a half minutes: from signing in and connecting the Mac, to installing a local language model including Open WebUI and chatting with it under its own address, to publishing a Ghost website from the same machine.

The following part is rather aimed at a technically versed readership.

The agent on the devices is written in Go and runs as a single static binary, which stores its state in SQLite and regularly compares the desired with the actual state of the device. On the cloud side, several NestJS services handle the API, the WireGuard network, SSH access and the gateway. The gateway uses nginx with the ssl_preread module to forward incoming traffic based on the requested domain into the respective WireGuard tunnel, without being able to decrypt it; TLS only terminates in Caddy on the device itself. The web app is built with Next.js, the macOS app with SwiftUI, and the whole infrastructure is hosted in Germany.

Three paths run through the system: visitors accessing an app hosted on a device, owners sending signed changes to their device and, in advanced mode, an SSH connection to the device. None of these requires an open port at home, and at no point does the platform hold a key that would allow it to read the traffic of an app or to act on a device on its own.

It should be emphasised that obacht is neither a backup solution nor does it promise availability. If the device at home is switched off or its internet connection fails, the apps hosted on it are not reachable either, and the data lies only on this one device. The described security architecture has been designed with care, but has not yet been validated in depth by an external audit. Until the public launch, obacht is therefore to be understood as a pilot, and not as infrastructure for particularly sensitive data.