ArozOS: a web desktop for Raspberry Pi and low power home servers

The problem ArozOS solves, and who ends up using it

A single board computer or a cheap VPS gives you storage and a network, but no interface. You end up with SSH, a Samba config file and a folder of half-remembered commands. ArozOS puts a desktop in the browser instead: a startup menu, a task bar, a file manager with drag and drop, and system settings, all served from the host itself. The README describes the target hardware as a Raspberry Pi 3B+ or 4B, and the precompiled binaries cover armv6, armv7, arm64 and amd64, so a Pi Zero W, an Orange Pi or a small Debian VPS are all in scope. The stated floor is 512MB of system memory and 1.5GB of storage. That is the pitch: a Synology-style web interface without buying a Synology. The people who get value from it are the ones who already run Debian on their own hardware and want file sharing, disk mounting and a usable UI in one process, rather than assembling Nextcloud or a Samba plus Apache stack. The project is written in Go, with a JavaScript frontend, and is licensed GPL-3.0.

Virtual file system, sandbox architecture and the network services around it

The piece that shapes everything else is the virtual file system with a sandbox architecture. Storage is not exposed as raw paths to the frontend; the README lists a Virtual File System plus Sandbox Architecture alongside Mount Disk Utilities for local file systems (ext4, NTFS, FAT) and remote ones (WebDAV, SMB, SFTP). So the desktop talks to an abstraction, and the disks behind it can be local or remote. On top of that the host runs its own sharing servers: FTP, WebDAV and SFTP, plus a basic-auth HTTP interface the README says is for legacy devices with outdated browsers. Networking is handled in the same process: mDNS discovery, SSDP broadcast so the box shows up in the Windows Network Neighborhood page, UPnP port forwarding for hosts behind a NAT router, and WiFi management through wpa_supplicant on Raspberry Pi or nmcli on Armbian. Security features listed are oAuth, LDAP, IP white and blacklists, and an exponential login timeout. Extensibility comes in two shapes: an ECMA5 scripting interface, and third party Go or Python modules that run as sub-services behind a reverse proxy. The startup flags mirror this design. allow_mdns, allow_ssdp, allow_upnp, allow_iot and allow_cluster all default to true, which means a default install is discoverable and willing to talk to nearby ArozOS hosts.

Installing ArozOS on Debian or Raspberry Pi OS

The README gives two routes. Building from source needs Go 1.20 or above and optionally ffmpeg, wpa_supplicant or nmcli. The precompiled route is one command on a fresh Raspberry Pi OS, Armbian or Debian install, run over SSH or from the desktop terminal.

wget -O install.sh https://raw.githubusercontent.com/tobychui/arozos/master/installer/install.sh && bash install.sh

The script asks on-screen questions and can register ArozOS as a systemd service. If you chose that, the README says to check it with sudo systemctl status arozos. Otherwise you start it by hand from the install directory.

cd ~/arozos
sudo ./arozos
# or if you have launcher installed
sudo ./launcher

The sudo is not cosmetic: the README notes it is needed for hardware and WiFi management features. After the first start, the system unpacks its files, and the README says to wait around 3 to 5 minutes depending on processing power and disk speed before opening the setup page.

http://{ip_address_of_your_host}:8080/

That page creates the root admin account. If your browser hides its user agent, the README gives two direct links instead: http://localhost:8080/mobile.system and http://localhost:8080/desktop.system. To build from source yourself, the sequence in the README is git clone, cd ./arozos/src/, go mod tidy, go build, then ./arozos. On Windows the process is manual: download arozos_windows_amd64.exe and web.tar.gz from the release page, put both in a folder whose name is ASCII with no spaces, add ffmpeg to %PATH%, and double click the exe.

Where ArozOS is the wrong choice

The platform assumptions are narrow. The README says the Linux binaries are only tested with Debian based Linux, so a Fedora or Alpine host is outside what the project claims to support. The Windows build is explicitly partial: the README states some features are not available for Windows, and it calls the Windows arm64 version experimental and not tested. The OpenWRT mipsle build and the Linux riscv64 and loong64 builds are also labelled experimental, with the README warning they might contain weird bugs and asking anyone interested to contact the maintainer directly. So if your target is a router or a RISC-V board, you are on a path the project itself does not stand behind. Docker is a community contribution: the README thanks SysAdmin74 for a dockerfile and links to it as WIP, which means there is no first-party container image to pin. The default flags are another consideration. allow_mdns, allow_ssdp, allow_iot, allow_cluster and allow_pkg_install all default to true, and allow_pkg_install lets the system install packages through apt or apt-get. On a machine exposed to a network you do not control, those defaults are a decision you should make deliberately rather than inherit. Finally, if your actual need is a sync-and-share product with mobile clients and a large app ecosystem, a web desktop on a Pi is a different category of tool.

ArozOS compared with a plain Samba or NAS setup

The obvious alternative is not another web desktop. It is the thing most people already do: install Samba or NFS on the same Debian box, mount the shares from their laptop, and manage the machine over SSH. That approach is lighter and has no web process listening on port 8080. The difference in approach is where the interface lives. With Samba, the file browser is the one on your own computer and the server holds no UI state; ArozOS ships the file manager, the task bar and the settings panel as part of the server, and the client is a browser. That matters when the device has no screen or when the people using it are not the people administering it. The README's built-in sharing servers (FTP, WebDAV, SFTP, and a basic-auth HTTP interface for outdated browsers) exist precisely so that legacy clients can reach the same storage without the desktop. A second alternative is a full NAS distribution or a self-hosted cloud suite, which brings a wider feature set and a heavier footprint. ArozOS goes the other way: one Go binary plus a web archive, aimed at 512MB of memory. The trade-off is ecosystem. You get an ECMA5 scripting interface and Go or Python sub-services behind a reverse proxy, not a catalogue of packaged apps.

Maintenance, licence and the upgrade path

The repository is not archived, and the most recent push recorded for it is 2026-09-23. Releases are frequent and versioned: v3.0.2 on 2026-08-22, v3.0.1 on 2026-07-19 and v3.0.0 on 2026-06-15. That cadence matters because the installer script and the web.tar.gz are versioned artefacts that must match the binary; the Windows instructions in particular require the exe and web.tar.gz from the same release page to sit in one folder. Upgrading therefore means replacing both parts, not just the binary, and the README does not document rollback. The uninstall path is a script in the installer folder, which the README mentions only as the way to recover from a broken setup. If you installed as a systemd service, upgrades touch that unit, and sudo systemctl status arozos is the README's own way to check the result. On licensing: the project is GPL-3.0, so if you modify ArozOS and distribute it, or ship it inside a product, the GPL obligations attach to that distribution. Running it on your own hardware for yourself does not raise that question. This is a summary of the licence identifier in the repository, not legal advice; read the LICENSE file before building anything commercial on top of it.

Editorial conclusion

Adopt ArozOS if you want a browser desktop on a Raspberry Pi 4B, an Orange Pi or a small Debian VPS and you are comfortable managing a Linux host yourself; the precompiled installer targets armv6, armv7, arm64 and amd64 and the README states 512MB of memory and 1.5GB of storage as the floor. Skip it if you need a Windows-first deployment (the README says some features are unavailable there and calls the arm64 build experimental), if you depend on the OpenWRT, riscv64 or loong64 builds, which the README labels experimental, or if you want a container-first deployment, since Docker is only a community file linked as WIP. Before committing, verify three things on your own hardware: that the systemd service starts, that your disks mount through the Mount Disk utilities, and that the built-in FTP, WebDAV and SFTP servers bind the ports you expect.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tobychui/arozos on GitHub