Hoodik: a self-hosted encrypted drive where the server only ever holds ciphertext

The problem Hoodik solves, and the users it fits

Most hosted storage gives you a promise about encryption and a server you cannot inspect. Hoodik inverts that. It is a self-hosted storage server where, per the README, "all encryption and decryption happens in your browser" and "the server never sees your plaintext data". The backend is Rust on Actix-web, the frontend is Vue 3, and the repository is organised as a Cargo workspace with separate crates for auth, storage, transfer, links, shares, settings and migration.

The audience is narrow and specific. It suits someone who already runs a small server, wants file storage plus encrypted markdown notes, and is willing to accept that losing a password means losing data unless a private key was saved elsewhere. It does not suit a team looking for a drop-in SaaS replacement with shared drive semantics, because the material describes a per-user encrypted store, not a collaborative document suite. The topics on the repository (backup, cloud, e2e-encryption, self-hosted) match that reading.

Where the keys live: OPAQUE login, hybrid wrapping, browser-side ciphers

The mechanism is the whole product, so it is worth stating precisely. On registration each user gets an Ed25519 identity key pair for signing and an X25519 plus ML-KEM-768 wrapping key pair for wrapping file keys. File keys are wrapped under both algorithms at once, which the README describes as a hybrid that stays secure even if a future quantum computer breaks the elliptic-curve half.

Login uses OPAQUE, so the password never crosses the wire. The private keys are stored envelope-encrypted under a key derived from the OPAQUE export_key, which only the password can produce. Accounts created before this scheme used RSA-2048 and, according to the README, migrate to the new keys automatically on the next login. That migration path is a real design commitment: it means the server must keep legacy decryption working indefinitely.

On upload, a random symmetric key is generated per file, the file is encrypted chunk by chunk, and both the cipher identifier and the encrypted key are stored in the database alongside the file. The cipher is persisted in files.cipher, so changing the default cipher later does not orphan old files. The default is AEGIS-128L via WASM SIMD128/relaxed-simd, with AEGIS-256, Ascon-128a and ChaCha20-Poly1305 also supported.

Search is the part people underestimate. File names and note contents are tokenized in the browser and each token is tagged with HMAC under a key derived from the private key. Only tags are stored, so the server can match a query without being able to read the index. That is a meaningful difference from encrypting blobs and then asking users to give up on search.

Installing Hoodik with Docker and uploading the first file

The project is Docker-first. The Dockerfile exposes 5443/tcp, sets DATA_DIR to /data, and starts the binary through tini with the command hoodik -a 0.0.0.0 -p 5443. The README points self-hosters at hoodik.io/get-started for the full guide, and publishes multi-arch images (amd64, armv6, armv7, arm64) on Docker Hub as hudik/hoodik.

The repository's docker-compose.yml is written for development rather than production. It brings up PostgreSQL, an ephemeral postgres-test instance on port 5433, and MinIO with the console on 9001, using minioadmin as both root user and root password. Read it as a description of the pieces Hoodik talks to, not as a deployment template.

services:
  postgres:
    image: bitnami/postgresql:latest
    environment:
      - POSTGRESQL_USERNAME=postgres
      - POSTGRESQL_PASSWORD=postgres
      - POSTGRESQL_DATABASE=postgres
    ports:
      - "5432:5432"

SQLite works out of the box; PostgreSQL is enabled through a single environment variable. Object storage is optional in the same way: encrypted chunks can live on local disk or on any S3-compatible service. The example below is the MinIO service from the compose file, which is what you would point an S3 configuration at during a local trial.

  minio:
    image: minio/minio:latest
    command: server /data --console-address ":9001"
    environment:
      - MINIO_ROOT_USER=minioadmin
      - MINIO_ROOT_PASSWORD=minioadmin
    ports:
      - "9000:9000"
      - "9001:9001"

Once the container is running and you have registered through the web UI, the first meaningful action is an upload. Two endpoints carry chunks, and the README documents both shapes. A single chunk goes to the storage endpoint with an index and a checksum, and the server verifies a CRC16 per chunk before storing it.

POST /api/storage/{file_id}?chunk=N&checksum=...
POST /api/storage/{file_id}?format=tar

The tar variant packs many chunks into one uncompressed archive whose entries are named {index:06}.enc. The README is explicit that the per-chunk integrity check is skipped on that path, with TLS and the file-level hash covering transport and content. Downloads mirror the split, with a chunk query for one chunk and a format=tar query for the whole file. What you should see after a successful upload is ciphertext on disk or in the bucket, and a decryptable file only in the browser.

Recovery, the tar transfer trade-off, and when Hoodik is the wrong tool

The README puts a warning in blockquote form: store your private key somewhere safe, because if you forget your password the private key is the only way to recover the account and decrypt your files. There is no documented server-side reset. That is the correct design for an end-to-end encrypted store, and it is also the failure mode most likely to bite a casual self-hoster. A forgotten password is not an inconvenience here; it is data loss.

The tar transfer path is a second trade-off worth naming. Batching chunks into one request reduces HTTP round-trips on slow networks, but the README states plainly that per-chunk integrity verification is skipped. If a chunk is corrupted in flight, the file-level hash is your only detector, and it tells you the file is bad rather than which piece failed. On a lossy connection the chunked endpoint is the more diagnosable choice.

Hoodik is the wrong tool for shared editing. There is no mention of concurrent multi-user document editing, and the encryption model is per-user key material, which makes shared plaintext access structurally awkward. It is also the wrong choice if you need a permissively licensed library to embed: the badge points at CC BY-NC 4.0, a non-commercial licence, and the repository's licence field is reported as NOASSERTION, so the file and the badge are not in obvious agreement. Verify the actual text of LICENSE.md before building anything commercial on it. Finally, if you want someone else to run the server and hold the availability risk, the README itself points at Hoodik Cloud as the managed version running the same code.

How Hoodik differs from YeetFile, OxiCloud and Peergos

The closest comparisons in this space are other self-hosted encrypted stores. YeetFile is the obvious sibling: also self-hosted, also built around client-side encryption, and also aimed at people who want to own the server. The practical difference to check is the key hierarchy and the transfer layer, because that is where Hoodik has made specific, documented choices: OPAQUE login, hybrid X25519 plus ML-KEM-768 wrapping, and a chunked or tar transfer split over two HTTP endpoints.

OxiCloud sits at the opposite end of the encryption question. It is a self-hosted file cloud, but the pitch is closer to a conventional drive than to a zero-knowledge one, so the server-side search and sharing story is simpler and the trust model is weaker. If your priority is a familiar file-sync experience rather than browser-side ciphers, that trade is the one to weigh.

Peergos takes a different architectural route entirely, building on content-addressed storage and peer-to-peer ideas rather than a single Actix-web server backed by SQLite or PostgreSQL and optional S3. That changes operational burden more than it changes the user-facing feature list. Hoodik's bet is that one container, one database and an optional bucket is the cheapest thing an individual can actually keep running. Whether that bet pays off depends on how much you value the smaller operational surface versus Peergos's decentralised model.

Maintenance cadence, upgrade cost and the licence question

The last push was on 2026-08-29, and v2.5.2 was released the same day, following v2.5.1 on 2026-08-28 and v2.5.0 on 2026-08-26. That is a tight release cluster rather than a long history of steady cadence, and the repository is not archived. Treat the release notes for those three versions as the source for what changed, because the README does not document rollback or downgrade steps.

Upgrade cost is dominated by two things. First, the multi-arch Docker image means a version bump is usually a tag change, but the container runs migrations against your database, and the README does not describe a migration rollback path. Second, the cipher is stored per file, which is good for forward compatibility and means an upgrade that changes the default cipher will not break existing files. Take a database backup before a version jump anyway, since the material offers no rollback procedure to fall back on.

On licensing, the badge in the README reads CC BY-NC 4.0, while the repository metadata reports NOASSERTION. The package.json points at LICENSE.md as the licence file. CC BY-NC 4.0 is a non-commercial licence, which is unusual for a server application and materially restricts commercial self-hosting and redistribution. This is not legal advice; read LICENSE.md and the CLA.md in the repository root, and get your own opinion if money is involved.

Editorial conclusion

Adopt Hoodik if you want a browser-based encrypted drive you control, are comfortable running a single Docker container with SQLite or PostgreSQL, and can live with a non-commercial licence. Do not adopt it if you need a permissively licensed component to embed in a product, or if you cannot store each user's private key somewhere safe, because the README says that key is the only way to recover an account after a forgotten password. Before committing, verify the licence terms against your own use, confirm the cipher your files will use, and test recovery with a throwaway account.

Frequently asked questions

Official sources

1. hudikhq/hoodik on GitHub
2. Issues
3. Project website
4. README
5. Releases