Hemmelig

Client-side encrypted secret sharing, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source encrypted secret sharing — create a link containing a password, API key, or file, and it self-destructs after being viewed or expired [README].
• Who it’s for: Developers, sysadmins, and small teams who need to pass secrets (credentials, tokens, private notes) without leaving them in Slack DMs, email threads, or chat logs.
• Cost savings: Hosted services like OneTimeSecret charge for volume and team features. Hemmelig self-hosted runs on a $5–6/mo VPS with SQLite and unlimited secrets.
• Key strength: Zero-knowledge architecture with AES-256-GCM encryption happening entirely in the browser — the server stores only ciphertext, never the key or plaintext [README].
• Key weakness: Restricted license (O’Saasy, not MIT), a patched but notable SSRF vulnerability in earlier versions [1], and 1,137 GitHub stars — useful but not a category leader.

---

What is Hemmelig

Hemmelig is the Norwegian word for “secret,” which tells you exactly what the project is going for. You paste a password, API key, or private message into a web interface; it encrypts the content in your browser before anything leaves your machine; you get a shareable link. The recipient opens the link once, reads the secret, and the record is deleted. If they never open it, it expires on a timer you set.

The pitch is direct: keep sensitive information out of chat logs, emails, and other communication channels that aren’t designed to handle secrets [README]. That’s a real problem. If you’ve ever sent a database password via Slack or emailed an API key to a contractor, you’ve created a permanent record of that credential that you can’t unsend, can’t revoke from the platform’s logs, and can’t guarantee isn’t in someone’s search history. Hemmelig puts a time-limited, encrypted intermediary between the sender and recipient.

The project is maintained by Bjarne Øverli, a Norwegian developer, and appeared in the selfh.st self-hosted newsletter in December 2024 as one of the featured new directory apps [3]. As of this review it sits at 1,137 GitHub stars — a tool people actively use, not just star. The v7 release introduced significant changes, including a migration from the older stack to a new auth system (better-auth) and a move to SQLite by default.

---

Why people choose it

Third-party reviews of Hemmelig specifically are thin on the ground — the tool doesn’t have the review volume of something like n8n or Nextcloud. What exists in the public record comes mostly from the self-hosted community and one security blog.

The selfh.st newsletter [3] listed Hemmelig in December 2024 under “Latest Directory Apps” alongside tools like PsiTransfer and Checkmate, describing it simply as “Encrypted secret sharing for everyone.” That’s an accurate description. The audience for this tool is not non-technical founders evaluating platforms — it’s developers and small teams who need a one-click solution to the “how do I securely share a credential” problem.

The more substantive public record comes from a security angle. BitNinja documented an SSRF vulnerability in Hemmelig versions before 7.3.3 [1], which we’ll cover properly in the deployment section. The fact that it was researched, documented, and patched is actually a reasonable signal for an open-source project at this star count: someone cared enough to look at the security model seriously.

The implicit reasons people choose Hemmelig over alternatives come from the feature set and the zero-knowledge design:

Versus emailing credentials. No comparison. Email is permanent, indexed, and out of your control once sent.

Versus Slack/Teams DMs. Platform chat logs persist indefinitely, are searchable by admins, and are accessible to the platform operator. A Hemmelig link burns on first read.

Versus hosted services like OneTimeSecret. OneTimeSecret’s free tier limits secret size and adds branding. Self-hosting Hemmelig removes both constraints and keeps your credential-sharing infrastructure inside your own network.

Versus Bitwarden Send. If your team already runs Bitwarden, Send is functionally equivalent and integrated. If you don’t, Hemmelig is a lighter, more focused standalone option.

---

Features

Based on the README and project documentation:

Core secret mechanics:

• AES-256-GCM client-side encryption — the browser encrypts before the payload leaves your machine [README]
• Configurable expiration time (hours to days)
• View limits — burn the secret after N reads, not just the first
• Optional password protection on top of the encrypted link itself
• IP restrictions — limit who can open the link by IP range [README]
• QR code generation for mobile sharing [README]

Content types:

• Plain text secrets
• Rich text via a WYSIWYG editor [README]
• File uploads for authenticated users [README]

Secret Requests:

• Ask someone to submit a secret to you without you having to know the value first — useful for collecting credentials from contractors or clients [README docs reference]
• This feature is also the one that had the SSRF vulnerability in pre-7.3.3 versions [1]

Developer and ops features:

• REST API with OpenAPI spec and SDK generation support [README]
• CLI for creating secrets from the command line or CI/CD pipelines [README]
• Webhook notifications when secrets are viewed or burned [README]
• Prometheus metrics endpoint [README]
• Health check endpoints for container orchestration liveness/readiness probes [README]
• Social login via OAuth (GitHub, Google, etc.) [README]
• Multi-language support [README]

Infrastructure:

• Docker and Docker Compose deployment [README]
• Helm chart for Kubernetes [README]
• SQLite by default, with the DATABASE_URL environment variable for other databases [README]
• “Managed mode” — configure instance settings entirely via environment variables [README]

The CLI is worth flagging specifically because it solves a real workflow problem: if you’re running automated provisioning scripts that need to hand off a generated password or API key to a human, you can pipe it directly into a Hemmelig secret without any manual copy-paste step.

---

Pricing: SaaS vs self-hosted math

The hosted version at hemmelig.app exists as a public demo and presumably a paid tier, but the pricing page details weren’t available at scrape time. What’s clear from the README is that the self-hosted path costs nothing beyond infrastructure.

Hemmelig self-hosted:

• Software cost: $0 (with license caveats — see below)
• Infrastructure: SQLite means no separate database server is required; a $5–6/mo VPS on Hetzner or Contabo runs the full stack comfortably
• The README explicitly recommends Hetzner Cloud and links a referral [README]

License caveat: Hemmelig is not MIT. The O’Saasy License Agreement prohibits using the software “to compete with the original licensor as a hosted service” [README]. That means if you’re planning to build a hosted secret-sharing product on top of Hemmelig’s codebase and sell it to others, you need a commercial agreement. Internal self-hosting for your own team is fine. This matters less than you’d think for most self-hosters, but it’s worth knowing before you build a business on it.

Comparison to paying for a hosted service:

• OneTimeSecret Pro: approximately $5–15/mo depending on tier and volume
• Bitwarden (which includes Bitwarden Send): $10/mo for a team of 5
• Hemmelig self-hosted: effectively $6/mo total (VPS) with no per-secret limits

For a solo developer or small team passing secrets internally, the math is simple: one cheap VPS covers unlimited secrets indefinitely.

---

Deployment reality check

The v7 Docker deployment is straightforward. The README’s quick-start command is a single docker run with four environment variables: a SQLite path, a BETTER_AUTH_SECRET (generate with openssl rand -base64 32), a BETTER_AUTH_URL pointing to your domain, and the image tag [README]. Docker Compose is available for a slightly more structured setup.

What you actually need:

• A Linux VPS with 1GB RAM minimum (SQLite is the default backend, so no separate database process)
• Docker installed
• A domain and a reverse proxy (Caddy handles TLS automatically and takes about 10 minutes to configure)
• No external dependencies beyond the container itself

What can go sideways:

First, the v6 to v7 migration. The README explicitly links a migration guide (docs/upgrade.md). If you’re running an older version, don’t assume the Docker image update is a drop-in replacement — read the upgrade doc first.

Second, the SSRF vulnerability documented by BitNinja [1]. Before version 7.3.3, Hemmelig’s Secret Requests feature had a Server-Side Request Forgery filter bypass. Attackers who had authenticated user access could use DNS rebinding techniques to make the server perform unauthorized HTTP requests to internal resources — potentially reaching services on the same private network as your Hemmelig instance [1]. The fix is in 7.3.3+. If you’re deploying a fresh instance today, you get the patched version. If you’re running an old instance, update immediately. If you deploy Hemmelig on the same network as sensitive internal services and allow untrusted external users to register accounts, be aware that the Secret Requests feature specifically carried this risk [1].

Third, authenticated vs. anonymous usage. File uploads require authentication. If you want to share encrypted files (not just text), you need accounts. Anonymous secret creation works out of the box, but the richer features require setting up user registration or OAuth providers.

Realistic time for a technical user: 20–40 minutes from a fresh VPS to a working HTTPS instance. The Caddy reverse proxy + Docker Compose path is the fastest route. Non-technical users will need help with the VPS and domain setup, but the application configuration itself isn’t complex.

---

Pros and Cons

Pros

• Zero-knowledge architecture. AES-256-GCM encryption in the browser means the server is never a liability for your plaintext data [README]. Even if your Hemmelig instance is compromised, the attacker gets ciphertext only.
• Self-destructing by design. View limits and expiration are core, not an afterthought. You control exactly how many times a secret can be opened and how long it lives.
• Minimal infrastructure. SQLite default means no Postgres or Redis required — the entire stack is one container on a small VPS [README].
• CLI for automation. Pipe secrets directly from scripts and CI/CD pipelines without touching a browser [README].
• REST API + OpenAPI spec. Machine-readable, documented, with SDK generation support — not an afterthought bolted on later [README].
• Webhook notifications. Know when a secret was viewed or burned — useful for audit trails in security-conscious teams [README].
• Prometheus metrics and health checks. Production-grade observability built in, not optional [README].
• IP restrictions. Limit which IP ranges can open a given secret — a meaningful additional layer for high-value credentials [README].
• SSRF patched. The documented vulnerability was found, reported, and fixed in 7.3.3 [1]. The project is responsive to security issues.

Cons

• Not MIT. The O’Saasy License prohibits competing with the original hosted service [README]. For internal use this doesn’t matter; for building products on top of it, check the license first.
• SSRF history. Pre-7.3.3 had a real SSRF vulnerability in the Secret Requests feature [1]. Patched now, but a notable incident for a security-focused tool.
• 1,137 stars — small project. Not a concern for functionality, but for longevity: this is a solo-maintainer project without a company or significant community behind it. If development stalls, you own the maintenance burden.
• No team governance features. No RBAC, no audit logs tied to user accounts, no centralized secret management history. It’s ephemeral sharing, not a secrets manager.
• Not a secrets manager. Hemmelig doesn’t store long-lived secrets, rotate credentials, or integrate with your infrastructure as a vault. If you’re looking for something like HashiCorp Vault or Infisical, this is the wrong category.
• Limited third-party documentation. Community tutorials, guides, and troubleshooting resources are sparse compared to more established tools. You’re mostly working from the official docs.
• File upload restricted to authenticated users. Anonymous text sharing works; encrypted file sharing requires accounts [README].

---

Who should use this / who shouldn’t

Use Hemmelig if:

• You regularly pass credentials, tokens, or private notes via Slack, email, or chat and want those transmissions to burn on read.
• You’re a developer or sysadmin who wants a lightweight, self-hosted secret-sharing link with a CLI and API.
• You’re running CI/CD pipelines that generate secrets and need a clean handoff mechanism to humans.
• You want zero-knowledge guarantees — the server should never see your plaintext.
• You’re comfortable with basic Docker deployment or have someone who can handle it.

Skip it if:

• You need a secrets manager that stores, rotates, and audits long-lived credentials. Look at Infisical, Vault, or Doppler instead.
• You’re looking for a team password manager. That’s Bitwarden, Vaultwarden, or 1Password.
• Your team already has Bitwarden and Bitwarden Send covers your needs — adding another tool adds friction.
• You need an MIT license to embed this in a commercial product or service. The O’Saasy License prohibits competing hosted use.
• You’re deploying for untrusted external users and running Hemmelig on the same network as sensitive internal services — understand the Secret Requests SSRF history [1] and ensure you’re on 7.3.3+.

---

Alternatives worth considering

• OneTimeSecret — the original hosted service in this category. Free tier exists, open source, MIT licensed. Less feature-complete than Hemmelig (no file uploads, no webhooks, no IP restrictions) but the hosted version requires no maintenance.
• Yopass — minimal, MIT-licensed, uses Redis for storage. Simpler than Hemmelig, fewer features, easier to audit.
• PrivateBin — encrypted pastebin with configurable expiry and burn-on-read. More pastebin-oriented than secret-sharing, but similar use case.
• PsiTransfer — simple open-source file sharing solution listed alongside Hemmelig in the same selfh.st directory update [3]. Different focus (file transfer rather than secret text), but worth comparing if file sharing is the primary need.
• Bitwarden Send — if you already run Vaultwarden or Bitwarden, Send is built in and covers most of the same use cases without a separate deployment.
• Infisical — if what you actually need is a proper secrets manager for development teams, not ephemeral sharing. Larger project, more infrastructure, different category.

---

Bottom line

Hemmelig does one thing and does it well: it gives you a self-hosted, zero-knowledge link for passing secrets that disappears after the recipient reads it. The AES-256-GCM client-side encryption model is sound, the CLI and REST API make it genuinely useful in automated workflows, and the infrastructure footprint (single Docker container, SQLite) is as minimal as this category gets. The SSRF vulnerability in pre-7.3.3 versions [1] is worth knowing about but is patched. The license is not MIT, which matters if you’re building products on top of it, but not for internal self-hosting.

What Hemmelig is not: a secrets manager, a team vault, or a replacement for Bitwarden. If you’re sending credentials through chat because you haven’t found a better option, this is a better option. If you’re running 50-person engineering teams with compliance requirements, you need a different category of tool.

If the deployment is the barrier, that’s what upready.dev deploys for clients. One-time setup, you own the instance.

---

Sources

1. BitNinja Security — “Server Security Alert: Bypass Vulnerability in Hemmelig” — bitninja.com. https://bitninja.com/blog/server-security-alert-bypass-vulnerability-in-hemmelig/
2. Mariushosting — Referenced for Synology NAS self-hosted deployment context (page did not contain Hemmelig-specific content) — mariushosting.com. https://mariushosting.com/page/102/
3. selfh.st — “This Week in Self-Hosted (13 December 2024)”, Ethan Sholly — selfh.st. https://selfh.st/weekly/2024-12-13/

Primary sources:

• GitHub repository and README: https://github.com/hemmeligorg/hemmelig.app (1,137 stars, O’Saasy License)
• Official website: https://hemmelig.app
• Docker Hub: https://hub.docker.com/r/hemmeligapp/hemmelig