OxiCloud: A Rust Self-Hosted Cloud That Skips the PHP Stack

The problem OxiCloud targets: a cloud suite without the PHP drag

The README frames the project directly: it is for self-hosters, home labs and small teams who want files, calendars, contacts and office editing without the operational drag of a traditional PHP stack. That is a concrete complaint, not a marketing line. Nextcloud and ownCloud both ship as PHP applications with a database, a web server and a plugin surface, and the maintenance burden that comes with them is real. OxiCloud's answer is to write the server in Rust and lean on standard protocols instead of a custom sync stack. The README states plainly that OxiCloud is not trying to mirror the full plugin ecosystem of Nextcloud, and that it is designed for a smaller stack, fast startup and standards-based interoperability. The target user is someone who already knows what WebDAV is, already has a reverse proxy, and wants a file server rather than a platform. If you need a marketplace of third-party apps, this is the wrong project and the README says so.

How OxiCloud is put together: Rust binary, PostgreSQL, DAV endpoints

The visible architecture is a single Rust service backed by PostgreSQL. The README says the prebuilt binary bakes the whole SPA, all operator subcommands and the database migrations into one self-contained executable, and that binary releases are attached to every tagged release for Linux musl amd64/arm64 and macOS Intel/Apple Silicon. That is a different deployment shape from a PHP app: there is no separate web server to configure for the application itself, and migrations ship inside the binary rather than as a directory of SQL files you run by hand. Configuration is environment-driven, with example.env as the template. The protocol surface is exposed at fixed paths: files at /webdav/, calendars at /caldav/, contacts at /carddav/. Authentication is JWT with Argon2id password hashing, and OIDC/SSO is supported with documentation and config examples included. Office editing goes through WOPI, which the README says works with Collabora or OnlyOffice. The data model includes quotas, roles, shared links, trash, favorites, recent items, chunked uploads and deduplication. What the README does not describe is the internal module layout, the storage backend abstraction, or how deduplication is keyed. If you need to reason about where bytes live on disk before you commit, that detail is not in the supplied material and you should read the architecture docs in the repository.

Getting it running: Compose, binary or cargo

The README gives three install paths. The Docker Compose path is the shortest: clone the repository, cd into it, copy example.env to .env, then run docker compose up -d and open http://localhost:8086. The README adds one warning that matters operationally: if users will access OxiCloud through a domain or reverse proxy, set OXICLOUD_BASE_URL in .env before the first login. That is a pre-first-login constraint, not a post-hoc setting, which suggests the value is written into stored state rather than read per request. The prebuilt binary path downloads a release artifact per platform and follows docs/install/binary.md for download, verification and a systemd walkthrough; cargo binstall oxicloud is also listed as working once a release is out. Running from source requires Rust 1.93+ and PostgreSQL, and the README notes that if PostgreSQL runs on your host rather than in Docker you must update both OXICLOUD_DB_CONNECTION_STRING and DATABASE_URL to use localhost:5432. Two connection settings for the same database is a small papercut worth knowing about before you debug a failed startup. Deployment details live in docs/config/deployment.md, and the repository also ships a Helm chart and a Nix module for operators who do not want Compose.

Where OxiCloud is thin: clients, sync and encryption

The project status table is unusually honest and it is the most useful part of the README for an adoption decision. File storage and the web UI are marked Ready, WebDAV is Ready, CalDAV and CardDAV are Ready, OIDC/SSO is Ready, and WOPI office editing is Ready. DAVx5 on Android is Partial: the README says file sync works well but calendar and contact behaviour is still being refined. Desktop sync client is Planned and not yet available. Mobile apps are Planned and not yet available. End-to-end encryption is a roadmap item. The practical consequence is that OxiCloud gives you protocol access, not a sync product. On macOS Finder, Windows Explorer, GNOME Files and KDE Dolphin you mount a WebDAV share; that is a network drive, not a background sync engine with conflict resolution and offline caching. For a single workstation on a LAN that is fine. For a laptop that goes offline and comes back with edits on both sides, you are relying on the DAV client's behaviour, not on OxiCloud. The absence of end-to-end encryption also means the server operator can read stored files, which is expected for a self-hosted server but rules OxiCloud out for anyone who wanted zero-knowledge storage.

OxiCloud versus Nextcloud: protocol server or application platform

The natural comparison is Nextcloud, and the difference is architectural rather than a feature checklist. Nextcloud is a PHP application platform: apps, a plugin marketplace, a long release history and a large surface area of optional functionality. OxiCloud is a Rust service that implements DAV endpoints, a REST API and WOPI, and the README explicitly declines to chase the plugin ecosystem. That trade shows up in two places. First, extension: with OxiCloud you integrate through the REST API or through WOPI, and there is no app store to browse. Second, operations: a single self-contained binary with embedded migrations and env-driven config is a smaller thing to keep alive than a PHP application with its own runtime, web server configuration and app update cycle. The honest framing is that these are different products that overlap on file storage. If your requirement list is mostly protocols plus a web UI plus office editing, OxiCloud covers it with less machinery. If your requirement list includes a specific Nextcloud app, or a desktop sync client with mature conflict handling, Nextcloud already has it and OxiCloud does not.

Maintenance cost and what the MIT licence means here

OxiCloud is MIT licensed, which is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a different posture from the AGPL that governs some self-hosted cloud projects, and it removes a category of concern for anyone embedding OxiCloud in a product. This is a description of the licence text, not legal advice; read the LICENSE file and talk to counsel if the distinction matters to you. On maintenance, the visible signal is release cadence: v0.8.9 landed on 2026-08-14, v0.8.8 on 2026-08-14, and v0.8.7 on 2026-07-22, with a repository push on 2026-09-08. Two releases on the same day suggests active iteration, and the 0.8.x version number tells you the project has not declared a stable 1.0 API. The upgrade mechanics are not spelled out in the supplied material beyond the fact that migrations are embedded in the binary, so the practical question to answer before deploying is how you roll back a schema migration if a release goes wrong. That is not documented in the README, and it is the single biggest operational unknown for a self-hoster.

Who should run OxiCloud, and what to check first

The fit is a home lab or a small team that already runs PostgreSQL, already terminates TLS at a reverse proxy, and wants file, calendar and contacts access through clients it already uses: Thunderbird, Apple Calendar and Contacts, DAVx5, or a WebDAV mount in Finder or Explorer. The fit is also someone who values a single binary with embedded migrations over a multi-service PHP deployment. The misfit is anyone who needs a desktop sync client, native mobile apps, or end-to-end encryption, because the README lists all three as planned rather than present. It is also a poor fit for anyone who depends on a specific Nextcloud app, since the plugin ecosystem is explicitly out of scope. Before pointing real data at it, verify the reverse proxy case: set OXICLOUD_BASE_URL in .env before the first login, not after, because the README flags that ordering. Then confirm your DAV clients reach /webdav/, /caldav/ and /carddav/ and that Android calendar and contact behaviour is acceptable to you, since DAVx5 support is marked Partial. Finally, decide your backup boundary: PostgreSQL plus the storage path the container writes to, tested with an actual restore, before the first upload that matters.

Editorial conclusion

Adopt OxiCloud if you run a home lab or small team and you want standards-based file, calendar and contacts access without a PHP stack, and you are comfortable running a v0.8.x project on PostgreSQL. Do not adopt it if you need a desktop sync client, mobile apps, end-to-end encryption, or a plugin ecosystem, because the README lists all four as planned or absent. Before you migrate real data, verify three things: that your OXICLOUD_BASE_URL is set correctly before the first login when you sit behind a reverse proxy, that your DAV clients authenticate against /webdav/, /caldav/ and /carddav/, and that your backup covers the PostgreSQL database plus whatever storage path the container writes to.

Official sources

1. AtalayaLabs/OxiCloud on GitHub
2. License: MIT
3. Project website
4. README
5. Releases