Claude
aba89c4f5d
Every change is benchmark-verified (harness + before/after numbers in benches/, measured on this branch; reproduction commands in each doc): DAV / sync-client hot paths - PROPFIND dead-properties: one = ANY($1) query per 500-child page instead of one sequential query per child, and indexable `=` predicates instead of IS NOT DISTINCT FROM (seq scans). 2,000-child folder: 1.07-4.54 s of DB chatter -> 4-6 ms (258-773x). Applied to native + NC PROPFIND and both NC REPORT handlers. [benches/DEAD-PROPS.md] - Folder paging: keyset cursor (name > $last) + new partial index (folder_id, name) replaces LIMIT/OFFSET full-folder rescan per page. Full 20k-file walk: 1266 ms -> 77 ms (16.5x). New migration 20260917000000. [benches/PROPFIND-PAGING.md] - NC chroot / default-drive resolution: moka caches (30 s TTL, explicit invalidation on drive mutations) for find_default_for_user and the markerless chroot FolderDto. 2 uncached queries + 2 pool checkouts per NC/WebDAV/WOPI request -> sub-us moka hit (p50 0.7-3.6 ms -> ~1 us). [benches/CHROOT-CACHE.md] - Quota: PROPFINDs whose prop list never names a quota prop skip the 2-query resolution entirely (wants_quota()); the remaining lookups read 2 columns instead of the full auth.users row with its <=512 KiB avatar (11-16x, p50 3.4 ms -> 0.29 ms). Same narrow read now gates every upload quota check. [benches/QUOTA-PATH.md] CPU on the request path - ZIP exports (folder download, share ZIP, batch download): entries whose MIME says already-compressed (JPEG/MP4/zip/pdf/...) are Stored instead of Deflate - deflate ran inline on the tokio writer task at ~41 MB/s for ~0% size gain. Mixed media corpus: 4.31x wall and CPU, archive size unchanged. Shared predicate in common::mime_detect. [benches/ZIP-MEDIA.md] - Compression layers: tower-http's default maps to Brotli QUALITY 11 (verified in brotli-8.0.2 source and empirically: 90 ms per 64 KiB JSON response, 1.3 s per 700 KiB bundle). Both layers pinned to Precise(4): 99x less CPU for ~15% more bytes. SPA assets are now precompressed at build time (scripts/precompress.mjs, 77% smaller) and served via ServeDir::precompressed_br/gzip: 2016x less per-request work, and clients get the better q11 bytes. [benches/STATIC-PRECOMPRESSED.md] Batched / cached backend paths [benches/NPLUS1-AND-CACHES.md] - Content-search ReBAC re-verification: new AuthorizationEngine::check_files_read_batch (default = old loop; PgAclEngine override batches drive resolution + reuses role cache). 200 sequential point SELECTs per search -> 1-2 queries. - Batch-ZIP subtree downloads: drop per-file re-authz + per-file Recent recording (2 writes/file) for subtree entries already authorized at the root - mirrors the native folder-download path. ~6,000 statements removed from a 2,000-file archive. - CDC chunk manifests: immutable by content address, now moka-cached (weight-bounded 32 MiB, 60 s TTL, positive-only, invalidated on delete) - removes one manifest query (p50 0.44-4.4 ms) from every stream, range and full blob read. - People tab: grouped COUNT + batched cover lookup instead of dragging every face row with its 2 KiB embedding (10k faces: 30.4 ms & 21 MB -> 3.8 ms & 1.3 KB, 8.1x); merge() is one set-based UPDATE. [benches/PEOPLE-LIST.md] - Photos timeline cursor: raw timestamptz comparison instead of EXTRACT(EPOCH ...) wrapper + IS NULL OR disjunction - cursor is an index boundary again, deep scroll stops re-scanning skipped rows. - Public share landing: one atomic UPDATE ... access_count + 1 (was SELECT + full-row write-back: racy, lost updates, clobbered concurrent owner edits) - 3 round-trips -> 2 per visit. - move_to_trash: dead full-entity SELECT feeding a documented no-op removed from both branches; dead fields dropped from TrashService. - NFC normalization: is_nfc_quick fast path skips the decompose/recompose state machine for the ~100% already-NFC case (every row loaded from PG). Frontend - Large folders paint after page one (~200 items) via fetchFolderListing's new onPage hook instead of waiting for every sequential page. - Tested-and-reverted (kept for the record): cached Intl.Collator for name sorts - vitest showed it 2x SLOWER than V8's argument-less localeCompare fast path (5.6 ms vs 12.1 ms / 5k names). Sort order untouched. New bench harnesses under examples/ (bench feature): zip_media, dead_props, chroot_cache, quota_path, people_list, propfind_paging, static_precompress. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CBK1RdtzyP6759Muqe1K1w
A fast self-hosted cloud for people who want files, calendars, contacts, and office editing without dragging a heavy stack behind them.
Documentation · Quick Start · Star OxiCloud · Request a Feature · Supported Clients · Project Status
If OxiCloud saves you setup time, RAM, or complexity, give it a star. If something is missing, ask for a feature or request a docs improvement.
Why People Try OxiCloud
OxiCloud is aimed at 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.
What pulls people in:
- Standard protocols first: WebDAV, CalDAV, and CardDAV are built in
- Useful product surface already there: files, previews, sharing, trash, search, favorites, and recent items
- Modern auth and admin basics: OIDC/SSO, quotas, roles, and shared links
- Better interoperability: native desktop and mobile clients work without custom sync tooling for basic access
- Lower deployment friction: Docker Compose, environment-based configuration, Helm chart, and Nix module
OxiCloud is not trying to mirror the full plugin ecosystem of Nextcloud. It is designed for a smaller stack, fast startup, and standards-based interoperability.
Quick Start
Docker Compose
Requires Docker and Docker Compose.
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
Open http://localhost:8086.
Run from source
Requires Rust 1.93+ and PostgreSQL.
git clone https://github.com/AtalayaLabs/OxiCloud.git
cd OxiCloud
cp example.env .env
# If PostgreSQL runs on your host instead of Docker, update both
# OXICLOUD_DB_CONNECTION_STRING and DATABASE_URL to use localhost:5432.
cargo run
Deployment details: deployment guide · example.env
What You Get
| Area | Included |
|---|---|
| Files | Multi-file upload, folders, inline previews, thumbnails, chunked uploads, deduplication, trash |
| Sync and clients | WebDAV, CalDAV, CardDAV, native OS clients, Thunderbird, DAVx5 |
| Security | JWT auth, Argon2id, OIDC/SSO, shared links, quotas, admin/user roles |
| Integrations | REST API and WOPI for Collabora or OnlyOffice |
| Operations | Docker image, Docker Compose, env-driven config, PostgreSQL backend |
| Project tooling | Architecture docs, Helm chart, Nix module, CI |
Supported Clients
OxiCloud uses standard DAV protocols, so it works with native clients instead of requiring a custom sync stack for basic access.
| Use case | URL |
|---|---|
| Files via WebDAV | https://your-host/webdav/ |
| Calendars via CalDAV | https://your-host/caldav/ |
| Contacts via CardDAV | https://your-host/carddav/ |
Common clients that work well:
- macOS Finder
- Windows Explorer
- GNOME Files and KDE Dolphin
- Thunderbird
- Apple Calendar and Contacts
- DAVx5 on Android
Client setup guides: DAV client setup · WebDAV guide · CalDAV & CardDAV guide
Project Status
OxiCloud is actively developed and already covers the core self-hosted cloud workflow.
| Capability | Status | Notes |
|---|---|---|
| File storage and web UI | Ready | Uploads, previews, sharing, trash, and search |
| WebDAV | Ready | Standard file access for desktop and mobile clients |
| CalDAV and CardDAV | Ready | Working with Thunderbird, Apple clients, and others |
| OIDC / SSO | Ready | Documentation and config examples included |
| WOPI office editing | Ready | Works with Collabora or OnlyOffice |
| DAVx5 Android support | Partial | File sync works well; calendar and contact behavior is still being refined |
| Desktop sync client | Planned | Not yet available |
| Mobile apps | Planned | Not yet available |
| End-to-end encryption | Planned | Roadmap item |
Roadmap: TODO-LIST.md
Help Shape OxiCloud
If you want OxiCloud to get better faster, use the repo like a product feedback loop, not just a code dump.
- Give it a star if you want more people to discover the project: Star OxiCloud
- Propose missing functionality: feature request
- Point out confusing onboarding or weak docs: documentation request
- Report breakage or regressions: bug report
- Build it with us: CONTRIBUTING.md
The best feature ideas usually come from real deployment pain. If you hit friction, open an issue and describe the workflow you want.
Architecture and Deployment
OxiCloud follows a clean, hexagonal architecture so protocol handlers, business logic, and infrastructure stay separated.
- Backend: Rust + Axum
- Database: PostgreSQL
- Configuration: environment variables
- Default deployment: Docker Compose
- Additional packaging: Helm chart and Nix module
Architecture docs: internal architecture · caching architecture · database transactions · storage safety
Configuration and Integrations
Start with example.env. The most important settings are:
OXICLOUD_BASE_URLfor reverse proxies, domains, and external accessOXICLOUD_DB_CONNECTION_STRINGfor PostgreSQLOXICLOUD_OIDC_ENABLEDand related settings for SSOOXICLOUD_WOPI_ENABLEDand discovery URL for office editingMIMALLOC_PURGE_DELAY=0for lower idle RSS in constrained environments
Integration docs: OIDC setup · OIDC architecture · OIDC config examples · WOPI integration
Documentation
- Docs site: AtalayaLabs.github.io/OxiCloud
- Deployment: docs/config/deployment.md
- Batch operations: docs/guide/batch-operations.md
- Search: docs/guide/search.md
- Thumbnails and transcoding: docs/guide/thumbnails-and-transcoding.md
- Deduplication: docs/guide/deduplication.md
Development
cargo fmt --all --check
cargo clippy --all-features --all-targets -- -D warnings
cargo test --workspace
Contributing
Contributions are welcome. Read CONTRIBUTING.md before opening a pull request and CODE_OF_CONDUCT.md for community expectations.
If you are not ready to code yet, starring the project and opening a precise feature request is still a meaningful contribution.
Contributors
OxiCloud is a community-driven project, and we appreciate all contributions. Check out the Contributors page to see the amazing people who have helped make OxiCloud better.
Star History
License
OxiCloud is a trademark of the OxiCloud project. All other trademarks are the property of their respective owners.