# OxiCloud: a Rust self-hosted cloud that bets on WebDAV, CalDAV and CardDAV instead of plugins

> OxiCloud is an MIT-licensed Rust server that puts files, calendars and contacts behind standard DAV protocols in a single binary. It is aimed at home labs and small teams who want Nextcloud's useful parts without the PHP stack, and it currently ships no desktop or mobile sync client of its own.

**AtalayaLabs/OxiCloud** — ☁️ Ultra-fast, secure & lightweight self-hosted cloud storage — your files, photos, calendars & contacts, all in one place. Built in Rust.

- Repository: https://github.com/AtalayaLabs/OxiCloud
- Website: https://atalayalabs.github.io/OxiCloud/
- Stars: 3,593 · Forks: 172
- Language: Rust
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/atalayalabs-oxicloud

## The operational weight OxiCloud is trying to remove

The README frames the target audience plainly: self-hosters, home labs and small teams who want "the useful parts of a cloud suite without the operational drag of a traditional PHP stack." That sentence is the whole pitch. Nextcloud and ownCloud are the reference points here, and the trade they make is breadth for weight: a PHP runtime, a database, an app store, and a plugin surface that grows with every feature you enable.

OxiCloud inverts that. The product surface listed in the README is deliberately finite: multi-file upload, folders, inline previews, thumbnails, chunked uploads, deduplication, trash, search, favorites, recent items, shared links, quotas and roles. There is no plugin marketplace, and the README says so directly in a pull quote: OxiCloud is not trying to mirror the full plugin ecosystem of Nextcloud. If your requirement is an app for every need, this is the wrong project and you will notice within an afternoon.

Who it actually fits: someone who already runs a reverse proxy and a database, wants file sync plus calendar and contact sync for a handful of users, and would rather configure a single service than administer a PHP application with a plugin graph. The Rust 1.93+ requirement in the badges, and the single self-contained executable described for binary releases, point at the same audience.

## What the single binary actually contains

The repository layout makes the architecture legible. There is a src/ tree for the server, a frontend/ directory holding a SvelteKit SPA built with Vite, and a migrations/ directory for the PostgreSQL schema. The Dockerfile confirms the split: a Node stage runs npm ci and npm run build to produce the SPA in /static-dist, and a Rust stage compiles the server that serves it. The justfile's release recipe does the same two steps locally, building the frontend first and then cargo build --release.

The database is PostgreSQL and only PostgreSQL. docker-compose.yml pins postgres:18.2-alpine3.23 alongside the application, and the application waits on a pg_isready healthcheck before starting. Configuration is environment-driven through an .env file loaded via env_file, which is why the quick start tells you to copy example.env before anything else. There is no SQLite fallback mentioned anywhere in the README.

The server stack is axum 0.8.8 on tokio, with mimalloc as the allocator. One detail in docker-compose.yml is worth quoting because it explains an operational quirk: mimalloc retains freed pages by default, so the compose file sets MIMALLOC_PURGE_DELAY to "0" so that RSS tracks the live working set. The comment claims roughly 400 MB reclaimed on musl/aarch64 at no throughput cost. That is the project's own note, not an independent measurement.

Protocol support is the differentiator. WebDAV lives at /webdav/, CalDAV at /caldav/, CardDAV at /carddav/. Because those are standards rather than a bespoke sync API, macOS Finder, Windows Explorer, GNOME Files, KDE Dolphin, Thunderbird, Apple Calendar and Contacts, and DAVx5 on Android can all talk to the server without a vendor client. The README says exactly that: native clients work "without custom sync tooling for basic access."

## Installing OxiCloud with Docker Compose and reaching first login

The README's quick start assumes Docker and Docker Compose. Clone the repository, copy the environment template, and bring the stack up. The compose file maps port 8086 on the host and starts both PostgreSQL and the application.

```bash
git clone https://github.com/AtalayaLabs/OxiCloud.git
cd OxiCloud
cp example.env .env

# If users will access OxiCloud through a domain or reverse proxy,
# set OXICLOUD_BASE_URL in .env before the first login.
docker compose up -d
```

After the containers report healthy, the web UI answers on http://localhost:8086. The healthcheck in docker-compose.yml polls http://127.0.0.1:8086/ready every 30 seconds, so that endpoint is the fastest way to confirm the server is actually up rather than merely running.

If you would rather not run Docker, the README points at two other paths. Prebuilt binaries for Linux musl amd64/arm64 and macOS Intel and Apple Silicon are attached to every tagged release, with a download, verify and systemd walkthrough in docs/install/binary.md. The Cargo.toml metadata also configures cargo binstall for the package name oxicloud, which fetches the release tarball instead of compiling. Running from source needs Rust 1.93+ and a reachable PostgreSQL instance, and the README flags the two variables to edit when the database is not in Docker: OXICLOUD_DB_CONNECTION_STRING and DATABASE_URL, both pointing at localhost:5432.

Once you are logged in, the first useful test is not in the web UI at all. Point a DAV client at the server and confirm it can list files. The README documents the WebDAV endpoint as https://your-host/webdav/, and the setup guides under docs/guide/ walk through the client side, including the WebDAV guide and the CalDAV and CardDAV guide. A successful listing comes back as a DAV multistatus response rather than an HTML page. If you get HTML, you are hitting the SPA and not the DAV endpoint, which usually means the path or the reverse proxy rewrite is wrong.

## Where OxiCloud stops: no first-party sync client, no E2E encryption

The status table is the most honest part of the README, and it should drive the decision more than the feature list does. File storage and the web UI, WebDAV, CalDAV and CardDAV, OIDC/SSO and WOPI office editing are all marked Ready. Three rows are not. DAVx5 Android support is Partial, with the note that file sync works well while calendar and contact behaviour is still being refined. Desktop sync client is Planned. Mobile apps are Planned. End-to-end encryption is Planned.

That first gap is the one that bites. Nextcloud users expect a tray icon that keeps a folder in step with the server. OxiCloud does not have one, and the README does not pretend otherwise. You get sync through WebDAV mounts and third-party DAV clients, which works, but it is a different experience: conflict handling, selective sync and bandwidth control are the client's problem, not the server's. On Windows, mapping a WebDAV drive is workable but not the same as a dedicated client. On macOS, Finder's WebDAV support has its own quirks.

The second gap is encryption. The README lists end-to-end encryption as a roadmap item, so files are encrypted in transit and passwords are hashed with Argon2id, but the server holds the plaintext. If your threat model includes the host being compromised, this is not the tool for that job yet. The README does not document rollback behaviour for upgrades either, so treat release notes and migrations/ as the source of truth before a version bump.

One more boundary worth naming: the compose file's default database credentials are postgres/postgres, and the README's quick start does not tell you to change them. That is a local-development default, not a deployment posture, and the documentation is silent on hardening it.

## How OxiCloud differs from Nextcloud and Cloudreve

Nextcloud is the obvious comparison, and the difference is structural rather than feature-by-feature. Nextcloud is a PHP application with an app store, a large plugin ecosystem, first-party desktop and mobile clients, and end-to-end encryption available through apps. OxiCloud is a compiled Rust service with a fixed feature set, standards-based access, and no plugin layer. If you need a specific Nextcloud app, OxiCloud almost certainly does not have an equivalent, and the README says the project is not attempting to. The other side of that coin: fewer moving parts, one process, one database, and no PHP runtime to patch.

Cloudreve is the other name that comes up in the same searches. It is a self-hosted file management and sharing system, and the practical distinction to check is protocol surface: OxiCloud's README makes WebDAV, CalDAV and CardDAV the centerpiece, which is what lets Apple Calendar, Thunderbird and DAVx5 connect without a custom client. If calendar and contact sync through standard DAV is not on your list, that advantage disappears and the comparison becomes about storage backends and sharing features instead.

On operations, OxiCloud ships a Helm chart, a Nix module and a Docker image, plus a WOPI compose file (docker-compose.wopi.yml) for hooking up Collabora or OnlyOffice. That is a narrower integration story than Nextcloud's, but it covers the deployment shapes most home labs actually use.

## Maintenance, releases and what the MIT licence means here

The last push to the repository was on 2026-09-08, and the most recent release is v0.8.9 from 2026-08-14, following v0.8.8 on the same day and v0.8.7 in July. The version is still 0.x, which is worth weighing: the project is pre-1.0 and the README's own status table shows three roadmap items still open. The repository is not archived, and the release cadence over July and August shows tagged artifacts are being produced rather than only commits landing.

Upgrade cost is mostly a database question. Migrations live in migrations/, and the compose file starts PostgreSQL before the application, so a version bump means running the new image against the existing volume and letting migrations apply. The README does not document a rollback path, and there is no downgrade guidance in the repository. Take a dump of the pg_data volume before upgrading, and read the release notes for the tag you are moving to.

OxiCloud is MIT licensed, which is the permissive end of the spectrum: you can use it commercially, modify it, and redistribute it, provided the copyright notice and licence text are preserved. The repository ships a LICENSE file at the top level. This is not legal advice, and MIT says nothing about the separate licences of Collabora or OnlyOffice if you enable WOPI editing, or about the terms of any OIDC provider you connect. Those are separate agreements you should read on their own.

## Conclusion

Adopt OxiCloud if you are comfortable running PostgreSQL and want a small Rust service that exposes files, calendars and contacts over WebDAV, CalDAV and CardDAV, with OIDC and WOPI already wired up. Do not adopt it if you need a first-party desktop or mobile sync client, end-to-end encryption, or the plugin ecosystem that Nextcloud offers; the README lists all three as planned or absent. Before committing, verify the DAVx5 calendar and contact behaviour the status table marks as partial, and confirm which OIDC provider your setup uses, since the README points to config examples rather than naming providers.

## FAQ

### How do I install OxiCloud with Docker?

Clone the repository, copy example.env to .env, and run docker compose up -d. The compose file starts PostgreSQL and the application, and the web UI is then reachable on http://localhost:8086.

### How does OxiCloud compare with Nextcloud?

OxiCloud is a Rust service with a fixed feature set and standards-based access, while Nextcloud is a PHP application with a large plugin ecosystem and first-party sync clients. The OxiCloud README states it is not trying to mirror that plugin ecosystem.

### Is there an OxiCloud demo or hosted version?

The README describes only self-hosted deployment paths: Docker Compose, prebuilt binaries attached to tagged releases, and running from source with Rust 1.93+ and PostgreSQL. No hosted demo is mentioned.

### What clients can connect to OxiCloud?

Because OxiCloud exposes WebDAV, CalDAV and CardDAV endpoints, the README lists macOS Finder, Windows Explorer, GNOME Files, KDE Dolphin, Thunderbird, Apple Calendar and Contacts, and DAVx5 on Android as working clients.

### Does OxiCloud have a desktop or mobile sync app?

No. The status table marks the desktop sync client and mobile apps as Planned, so basic access currently goes through DAV clients rather than a first-party sync application.

## Sources

- [AtalayaLabs/OxiCloud on GitHub](https://github.com/AtalayaLabs/OxiCloud)
- [License: MIT](https://github.com/AtalayaLabs/OxiCloud/blob/main/LICENSE)
- [Project website](https://atalayalabs.github.io/OxiCloud/)
- [README](https://github.com/AtalayaLabs/OxiCloud/blob/main/README.md)
- [Releases](https://github.com/AtalayaLabs/OxiCloud/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/atalayalabs-oxicloud