hudikhq/hoodik: Self-Hosted Encrypted Storage in Rust

hudikhq/hoodik: Self-Hosted Encrypted Storage in Rust

Deploy hudikhq/hoodik for browser-based, end-to-end encrypted file storage that keeps plaintext data off your server entirely. Built in Rust with Vue 3, it runs in a single Docker^{↗ Bright Coding Blog} container with SQLite or PostgreSQL^{↗ Bright Coding Blog} and optional S3 backends.

Introduction

Cloud storage convenience comes with a persistent trade-off: your files live on someone else's infrastructure, readable by their systems and subject to their policies. For developers, DevOps^{↗ Bright Coding Blog} teams, and privacy-conscious organizations, this creates a tension between usability and data sovereignty. Self-hosted solutions exist, but many either lack genuine encryption or push complexity onto operators through sprawling dependencies.

hudikhq/hoodik addresses this directly. It is a lightweight, self-hosted storage server where all encryption and decryption happens in the browser—the server never sees plaintext data. Written in Rust (Actix-web) on the backend and Vue 3 on the frontend, it offers a Docker-first deployment with SQLite out of the box, PostgreSQL via configuration, and S3-compatible object storage for encrypted chunks. With 1,355 GitHub stars and active maintenance through mid-2026, it represents a pragmatic middle ground between consumer cloud services and heavyweight enterprise file servers.

This article examines what hudikhq/hoodik does, how its cryptography works, and how to deploy it based strictly on its documented capabilities.

What is hudikhq/hoodik?

hudikhq/hoodik is an open-source, self-hosted cloud storage server released under the CC BY-NC 4.0 license. It was created by [INTERNAL_LINK: open-source Rust projects] developer Hudik and is actively maintained, with the most recent commit dated July 15, 2026. The project sits in the intersection of personal cloud software and cryptographic storage tools, competing conceptually with solutions like Nextcloud (without its app ecosystem) or Cryptomator (without its virtual filesystem approach).

The architecture is deliberately simple: a Rust backend using Actix-web serves a Vue 3 frontend, with all cryptographic operations performed client-side via WebAssembly. This design choice means the server operates exclusively on opaque, encrypted bytes—it cannot decrypt user files even if compelled or compromised.

The project ships multi-arch Docker images (amd64, armv6, armv7, arm64) and emphasizes single-container deployment. It supports both SQLite for simplicity and PostgreSQL for production scale, with encrypted file chunks storable either on local disk or any S3-compatible service. An Android app extends access beyond the browser.

The 63 forks and steady star growth suggest a niche but engaged user base—primarily developers and privacy-focused individuals who value auditability over convenience. The non-commercial license is a deliberate constraint: personal and non-commercial use is free, while commercial deployment requires contacting the maintainer directly.

Key Features

End-to-end encryption with hybrid RSA + AEGIS-128L Each user receives an RSA-2048 key pair on registration. The private key is encrypted with the user's passphrase and stored server-side; the server cannot read it. File encryption uses a random symmetric key per file, with AEGIS-128L as the default cipher—hardware-accelerated via WASM SIMD128/relaxed-simd. Ascon-128a and ChaCha20-Poly1305 are also supported, with the cipher identifier stored per-file for future compatibility.

Secure metadata search File names and metadata are tokenized, hashed, and stored as opaque tokens. Search queries undergo the same transformation server-side, enabling matching without plaintext exposure. This is a non-trivial cryptographic feature that distinguishes Hoodik from simple encrypted-at-rest solutions.

Encrypted notes with WYSIWYG editing Beyond file storage, Hoodik includes a markdown^{↗ Smart Converter} note editor with encrypted, auto-saved content that participates in the same searchable encryption scheme as uploaded files.

Public sharing without key exposure Shared links embed the decryption key in the URL fragment (#link-key), which browsers do not send to servers. The recipient's browser decrypts locally; the server sees only encrypted bytes.

Two-factor authentication Optional TOTP-based 2FA per user adds account-level protection independent of the encryption scheme.

Flexible storage backends SQLite requires zero configuration. PostgreSQL is enabled via DATABASE_URL. Encrypted chunks can reside on local disk or any S3-compatible service (AWS S3, MinIO, Backblaze B2, Wasabi) through standard environment variables.

Chunked transfers for performance Files split into encrypted chunks enable concurrent upload and download. Two HTTP endpoints support either individual chunk access or batched tar archive transfer for high-latency networks.

Use Cases

Personal privacy-first file server Individuals with technical aptitude can replace consumer cloud storage (Google Drive, Dropbox) with infrastructure they control. The browser-based encryption means even a compromised server exposes no plaintext, and the self-hosted model eliminates third-party data processing agreements.

Small team document collaboration The admin dashboard supports user management, session control, and invitations. Combined with encrypted notes and file sharing, small teams in legal, medical, or research contexts can share sensitive documents without trusting a SaaS provider's security claims.

Development and staging artifact storage Teams already running Docker infrastructure can deploy Hoodik as an internal store for build artifacts, logs, or database backups. S3 backend support integrates with existing object storage, while chunked transfers handle large files efficiently.

Air-gapped or edge deployments The single-container design, ARM architecture support, and SQLite default make Hoodik viable for edge devices, offline networks, or jurisdictions with data residency requirements. No external authentication services or cloud APIs are mandatory.

Encrypted note-taking with file attachment The integrated markdown editor^{↗ Smart Converter} with encrypted auto-save suits users who want a unified encrypted workspace rather than separate tools for files and notes.

Installation & Setup

The documented quickstart uses Docker with automatic TLS certificate generation:

# Basic Docker deployment with self-signed TLS
docker run --name hoodik -d \
  -e DATA_DIR='/data' \
  -e APP_URL='https://my-app.example.com' \
  --volume "$(pwd)/data:/data" \
  -p 5443:5443 \
  hudik/hoodik:latest

This command:

• Runs Hoodik in detached mode with container name hoodik
• Sets DATA_DIR to /data inside the container (mounts host ./data there)
• Configures the public URL for link generation and cookies
• Exposes port 5443 with auto-generated self-signed TLS certificates

For production with custom TLS and SMTP email:

# Production deployment with custom certificates and Gmail SMTP
docker run --name hoodik -d \
  -e DATA_DIR='/data' \
  -e APP_URL='https://my-app.example.com' \
  -e SSL_CERT_FILE='/data/my-cert.crt.pem' \
  -e SSL_KEY_FILE='/data/my-key.key.pem' \
  -e MAILER_TYPE='smtp' \
  -e SMTP_ADDRESS='smtp.gmail.com' \
  -e SMTP_USERNAME='you@gmail.com' \
  -e SMTP_PASSWORD='your-app-password' \
  -e SMTP_PORT='465' \
  -e SMTP_DEFAULT_FROM_EMAIL='you@gmail.com' \
  -e SMTP_DEFAULT_FROM_NAME='Hoodik Drive' \
  --volume "$(pwd)/data:/data" \
  -p 5443:5443 \
  hudik/hoodik:latest

Critical configuration notes from the documentation:

• Set JWT_SECRET to a stable random string or all sessions invalidate on container restart
• SSL_DISABLED=true is documented for development only
• Behind a reverse proxy like Nginx Proxy Manager is recommended for production TLS termination

Real Code Examples

The README provides two primary deployment patterns. This section reproduces them with context.

Example 1: MinIO S3 Backend Configuration

# Deploy with MinIO as encrypted chunk storage
docker run --name hoodik -d \
  -e DATA_DIR='/data' \
  -e APP_URL='https://my-app.example.com' \
  -e STORAGE_PROVIDER='s3' \
  -e S3_BUCKET='hoodik' \
  -e S3_ENDPOINT='http://minio:9000' \
  -e S3_ACCESS_KEY='minioadmin' \
  -e S3_SECRET_KEY='minioadmin' \
  -e S3_PATH_STYLE='true' \
  --volume "$(pwd)/data:/data" \
  -p 5443:5443 \
  hudik/hoodik:latest

Explanation: This switches encrypted chunk storage from local filesystem to S3-compatible object storage. S3_PATH_STYLE='true' is required for MinIO and similar self-hosted S3 implementations that use path-style rather than virtual-hosted-style URLs. DATA_DIR remains necessary for SQLite database and local state even with S3 chunks.

Example 2: Storage Migration Command

# One-off container to migrate local chunks to S3
docker run --rm \
  -v hoodik-data:/data \
  -e DATA_DIR=/data \
  -e S3_BUCKET=my-bucket \
  -e S3_REGION=eu-central-1 \
  -e S3_ACCESS_KEY=... \
  -e S3_SECRET_KEY=... \
  hudik/hoodik migrate-storage

Explanation: The migrate-storage subcommand uploads all local chunk files to S3. It is idempotent—already-uploaded files are skipped, making interruption safe. The README explicitly warns: stop the Hoodik server before migration to prevent inconsistency from concurrent uploads.

The README contains these two deployment examples. No additional code samples are provided in the current documentation.

Advanced Usage & Best Practices

Session persistence across restarts The default JWT_SECRET is randomly generated per container start. In any production deployment, explicitly set this variable or users will be logged out on every restart or redeployment. This is documented but easily overlooked in quickstarts.

Cross-domain API access trade-off When frontend and backend run on different domains, USE_HEADERS_FOR_AUTH=true switches from HttpOnly cookies to localStorage-based tokens with Authorization: Bearer headers. The README is explicit about the security implication: this exposes tokens to XSS attacks and should only be used when cookie-based authentication is architecturally impossible.

Database backend selection timing SQLite and PostgreSQL are not interchangeable after data is written. The README states this bluntly: "Switching after data has been written will result in data loss." Plan this decision before production deployment.

Chunked transfer strategy For high-latency networks, the tar archive endpoint (?format=tar) reduces HTTP round-trips at the cost of per-chunk CRC16 verification. TLS and file-level hashes still provide transport and content integrity. Choose based on network characteristics rather than defaulting to individual chunks.

Backup strategy for encrypted private keys The README warns explicitly: "Store your private key somewhere safe (e.g. a password manager). If you forget your password, the private key is the only way to recover your account and decrypt your files." No server-side password reset exists for encrypted accounts—this is a feature, not a bug, but requires user education.

Comparison with Alternatives

Trade-off analysis: Nextcloud offers broader app ecosystem and proven enterprise deployment but carries heavier resource requirements and more complex security surface. Cryptomator provides stronger client-side isolation (no server to compromise) but lacks a native web interface and requires separate cloud storage. Hoodik occupies a middle ground: simpler than Nextcloud, web-native unlike Cryptomator, with the explicit non-commercial license as a distinguishing constraint.

FAQ

Q: Can I use Hoodik for commercial purposes? A: No—the CC BY-NC 4.0 license restricts use to personal and non-commercial contexts. Contact hello@hudik.eu for commercial licensing.

Q: What happens if I lose my password? A: Without your encrypted private key backup, account recovery is impossible. The server cannot decrypt your data.

Q: Does Hoodik support iOS? A: The README mentions only an Android app; iOS support is not documented.

Q: Can I switch from SQLite to PostgreSQL later? A: No—the README explicitly states this causes data loss. Choose before production.

Q: Is the self-signed TLS certificate production-ready? A: No—it is auto-generated for quickstart only. Use proper certificates or a reverse proxy.

Q: How does search work if filenames are encrypted? A: Tokenized metadata is hashed into opaque tokens; query tokens are matched server-side without plaintext exposure.

Q: What Rust version is required for development? A: The README does not specify; see DEVELOPMENT.md in the repository.

Conclusion

hudikhq/hoodik delivers precisely what its documentation claims: a lightweight, browser-encrypted, self-hosted storage server with credible cryptography and minimal deployment friction. It is best suited for privacy-focused individuals, small technical teams, and developers already comfortable with Docker who need file storage without trusting third-party infrastructure.

The non-commercial license is a genuine constraint—this is not drop-in replacement software for enterprise file sharing without negotiation. The 1,355-star repository shows modest but real adoption, and the active maintenance through mid-2026 suggests continued viability.

If your requirements align with self-hosted, client-encrypted storage and you accept the license terms, Hoodik offers a cleaner architecture than many alternatives. Evaluate it against your specific threat model and infrastructure constraints.

Explore the repository, read the full configuration reference in .env.example, and deploy with the commands above: https://github.com/hudikhq/hoodik