Hoodik: Self-Hosted Encrypted Storage Where the Browser Holds the Keys

The Problem Hoodik Solves, and the Threat Model It Assumes

Most self-hosted file sync tools encrypt in transit and at rest on the server. The operator of that server can read every file. Hoodik takes the other position: encryption and decryption happen in the browser, and the README states plainly that the server never sees plaintext data. That single design choice determines who the project is for. It suits a person or a small group running their own instance on a VPS or a home machine who does not want to be the party capable of reading the stored data, and who wants that property to survive a database dump, a subpoena, or a misconfigured backup. It also suits anyone who wants the same guarantees from a managed host, since the README describes Hoodik Cloud as running the same publicly auditable code with identical browser-side encryption. The cost is that recovery becomes a personal responsibility. The README carries an explicit warning that if you forget your password, the private key is the only way to recover the account and decrypt files, and it tells you to store that key somewhere safe such as a password manager. An operator who wants a reset button that restores access to a locked-out user's files is looking at the wrong tool, because that button cannot exist without breaking the property Hoodik is built around.

What Actually Happens Between the Browser and the Disk

Each user gets an Ed25519 identity key pair for signing and an X25519 + ML-KEM-768 wrapping key pair for wrapping file keys at registration. File keys are wrapped under both algorithms at once, a hybrid the README describes as staying secure even if a future quantum computer breaks the elliptic-curve half. Login uses OPAQUE, so the password never crosses the wire, and private keys are stored envelope-encrypted under a key derived from the OPAQUE export_key. Accounts created before this scheme used RSA-2048 and are still supported; they migrate on the next login. On upload, a random symmetric key is generated for the file, the file is encrypted chunk by chunk with the file's cipher, and the cipher identifier plus the encrypted key are written to the database next to the file. That last detail matters more than it looks. Because the cipher is stored per file, changing the instance default does not strand older files, which is the failure mode that makes cipher migration painful in systems that record only a global setting. The default is AEGIS-128L, hardware-accelerated through WASM SIMD128 and relaxed-simd, with AEGIS-256, Ascon-128a and ChaCha20-Poly1305 also supported. Search is handled by tokenizing file names and note contents in the browser and tagging each token with HMAC under a key derived from the user's private key. Only the tags reach the server, so a query can be matched without the index being readable back into words by anyone holding the database.

Two Upload Paths, and the Integrity Check You Give Up

Chunks move over one of two HTTP endpoints. The first is POST /api/storage/{file_id}?chunk=N&checksum=... for a single encrypted chunk, where the server verifies a CRC16 per chunk before storing it. The second is POST /api/storage/{file_id}?format=tar, which uploads many chunks in one request as an uncompressed tar archive whose entries are named {index:06}.enc. The README is candid that the tar path skips the per-chunk integrity check, on the reasoning that TLS and the file-level hash still cover transport and content. Downloads mirror the split: GET /api/storage/{file_id}?chunk=N streams one chunk, GET /api/storage/{file_id}?format=tar streams all of them as a tar archive. The trade-off is real and worth stating without softening. On a slow or high-latency link, the tar path cuts round trips and will feel considerably faster. It also moves corruption detection from per-chunk to whole-file, so a single damaged chunk inside a large archive is discovered at the end rather than at the point of failure. Neither choice is wrong; they are different bets, and the endpoint query string is where you make it.

Running It: One Container, Two Environment Decisions

The README describes Hoodik as Docker-first, with a single container deployment and multi-arch images published for amd64, armv6, armv7 and arm64. The image lives at hudik/hoodik on Docker Hub, and the project points to a self-hosting guide at hoodik.io/get-started for the full procedure, so the exact compose file and volume layout are not reproduced in the repository README. Two configuration decisions are documented at the level of mechanism rather than command. Storage backend: encrypted chunks go to local disk by default, or to any S3-compatible service (the README names AWS, MinIO, Backblaze B2 and Wasabi) instead. Database: SQLite works out of the box, and PostgreSQL is enabled via a single environment variable. The default cipher is an admin setting, which is where you would switch away from AEGIS-128L if you wanted ChaCha20-Poly1305 or Ascon-128a. Two-factor authentication is optional per user and TOTP-based, and an admin dashboard handles users, sessions, invitations and application settings. Because the encryption is browser-side, the deployment question that usually dominates these projects (disk encryption, host hardening, backup confidentiality) is partly displaced: the stored chunks are ciphertext regardless of where they sit. The part that is not displaced is key custody, which lives in the browser and in whatever password manager the user already trusts.

Licence: NOASSERTION in the Metadata, CC BY-NC 4.0 in the Repository

The repository metadata reports the licence as NOASSERTION, which is GitHub's way of saying it could not classify the file. The README badge and the LICENSE.md link resolve that ambiguity: the project is licensed CC BY-NC 4.0. Non-commercial is the operative clause. For an individual running a personal drive, or a hobby project, that is unlikely to be a practical obstacle. For a company deploying Hoodik as internal storage, or for anyone building a product on top of it, the non-commercial restriction is the first question to put to whoever handles licensing, and this article cannot answer it for you. The mismatch between the metadata field and the actual licence is worth noting on its own: automated licence scanners that read the GitHub API will see NOASSERTION and may either flag the repository for manual review or wave it through, depending on how they are configured. Neither outcome reflects what LICENSE.md actually says. Read the file.

Where Hoodik Is the Wrong Tool

Sharing is the clearest boundary. Hoodik supports public sharing links, and the mechanism is well specified: a random link key is generated, the file metadata and file key are encrypted with it, the link key is itself wrapped under the sharer's current key type so only they can recover it, and the link key is appended to the URL as a fragment, as in https://.../links/{id}#link-key. The recipient's browser reads the fragment, decrypts the metadata and file key locally, and does all decryption itself; the fragment never reaches the server. That is a strong design for handing a file to someone outside the instance. It is not a permission system. The README describes no per-folder ACLs, no read-only versus read-write share roles, and no revocation semantics beyond what the admin dashboard implies for sessions and users. A team that needs to grant a contractor write access to one directory while keeping the rest invisible is not served by a single secret link. The second boundary is recovery. The README's warning about the private key is not boilerplate; it is the direct consequence of OPAQUE login and envelope-encrypted private keys. Any deployment where users will lose passwords and expect an administrator to restore their data is a deployment that will generate support tickets nobody can resolve. The third is the tar upload path, which is a deliberate weakening of per-chunk verification that some environments will not accept.

How Hoodik Differs From a Server-Side Encrypted Drive

The obvious comparison is Nextcloud with its end-to-end encryption app, and the difference is where the trust boundary sits rather than which features exist. In a server-side encrypted deployment, the server holds keys and can be made to decrypt on request; the encryption protects against disk theft and casual database access, not against the operator. Hoodik inverts that. The server stores ciphertext, the wrapping keys are derived from material only the user's password can produce, and search works by matching HMAC tags rather than by reading an index. The consequence is that server-side features which depend on reading content (thumbnail generation, server-side full-text search, virus scanning on upload, server-side transcoding) are structurally unavailable, not merely unimplemented. Hoodik's answer to search is the browser-side tokenization scheme, and its answer to previews is that the browser decrypts first. If your requirements include server-side processing of stored files, that is not a gap Hoodik plans to close; it is the property it was built to prevent. Against a plain object store with client-side encryption bolted on, Hoodik's advantage is that the key management, sharing, notes, 2FA and admin surface are already integrated rather than assembled by the operator.

Maintenance Cost and What to Watch

The release cadence visible in the repository is tight: v2.5.0 on 2026-08-26, v2.5.1 on 2026-08-28, v2.5.2 on 2026-08-29, three releases in four days. That pattern suggests active development and a low tolerance for leaving fixes unshipped, and it also means an operator who pins a version will fall behind quickly if the releases include security-relevant changes. The README does not describe a migration policy for the database schema, so the practical upgrade cost of moving between minor versions is not something this material establishes. What the material does establish is that cipher identifiers are stored per file in the files.cipher column, which is the mechanism that keeps old files decryptable after a default cipher change, and that legacy RSA-2048 accounts migrate automatically on next login. Both reduce long-term migration risk. The operational cost that does not go away is key custody: every user is responsible for their private key, and the project's own documentation treats that as a user obligation rather than a server responsibility. Budget for explaining that to whoever you deploy this for, because the alternative is a support burden with no resolution path. The Android app and the iOS and macOS app are listed in the README, so mobile access does not require a browser, though the article cannot speak to how those clients handle key storage.

Editorial conclusion

Adopt Hoodik if you want a single-container encrypted drive where the server never holds plaintext, you are comfortable with browser-side key handling, and you have read LICENSE.md rather than trusting the NOASSERTION metadata. Do not adopt it if you need per-folder sharing with distinct read and write roles, or if a non-commercial licence is a blocker for your organisation. Verify three things before committing: the exact terms in LICENSE.md, whether the tar-format upload path is acceptable given that it skips per-chunk CRC16 verification, and whether your existing accounts predate the X25519 + ML-KEM-768 scheme, since those still carry RSA-2048 keys until the next login migrates them.

Official sources

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