Hemmelig: A Self-Hostable Secret Sharing Tool With a Maintainer Vacancy

The Problem Hemmelig Solves, and Why Chat Is the Wrong Channel

Passwords, API keys and personal data get pasted into chat logs and email threads because those are the channels already open. Hemmelig exists to break that habit by turning a secret into a link that expires or burns after a set number of views. The README states the goal directly: keep sensitive information out of chat logs and emails with encrypted secrets, and the repository topics list gdpr, privacy-enhancing-technologies and self-hosted alongside onetimesecret. That topic list is the honest description of the niche. This is a OneTimeSecret-style tool, not a password manager and not an end-to-end encrypted messenger. The intended user is someone who controls a server and wants the secret to pass through infrastructure they own, with the server unable to read it. A second audience is CI/CD: the README ships a CLI, and the CLI documentation covers automation and CI/CD integration examples, which is where a secret link generated from a build pipeline makes more sense than a secret pasted into a ticket.

Client-Side AES-256-GCM and What the Server Actually Holds

The architecture claim is zero-knowledge: all encryption happens in the browser, and the server only stores encrypted data and never sees the secrets or the encryption keys. The README names the primitive as client-side AES-256-GCM. The consequence worth stating plainly is that the decryption key must travel in the link fragment rather than in a request body, because anything sent to the server would defeat the design. The README does not spell out the fragment handling in the text available here; it points to docs/encryption.md for the mechanism, so treat the key-in-URL detail as something to confirm there rather than assume. The same caution applies to the optional password layer. The feature list calls it an additional security layer, which implies it is separate from the AES key rather than a replacement for it, but the derivation path is not described in the README. On top of encryption sit the operational controls: configurable expiration and view limits, IP restrictions to specific ranges, QR codes for mobile handoff, and webhook notifications fired when secrets are viewed or burned.

Docker Is the Intended Deployment Path

The README labels Docker the recommended route and gives a single run command. It maps two volumes, hemmelig-data to /app/database and hemmelig-uploads to /app/uploads, sets DATABASE_URL to file:/app/database/hemmelig.db, and requires BETTER_AUTH_SECRET plus BETTER_AUTH_URL pointing at your domain. The BETTER_AUTH_SECRET value in the example is generated with openssl rand -base64 32, and the image tag is hemmelig/hemmelig:v7. A Docker Compose path is also documented: clone the repository, edit docker-compose.yml, then run docker compose up -d. The presence of BETTER_AUTH_* keys tells you the v7 auth stack is Better Auth, and both variables are mandatory in the example, so a deployment that omits BETTER_AUTH_URL will not match the documented shape. Beyond the container, the repository documents a Helm chart for Kubernetes, environment variables in docs/env.md, a managed mode that configures instance settings through environment variables, health checks with liveness and readiness probes, and Prometheus metrics. That is a lot of operational surface for a secret-sharing app, and it is the clearest signal that the project is aimed at teams running containers, not at someone who wants a single binary on a laptop.

The CLI Is the Part That Fits a Pipeline

Two installation routes are documented. A binary download from the releases page, shown as curl -L against the cli-v1.0.1 asset for linux-amd64 followed by chmod +x, and an npm global install with npm install -g hemmelig. The README recommends the binary for CI/CD, which makes sense: a static download avoids pulling a Node toolchain into a build image. Creating a secret is a single argument, hemmelig "my secret message", and the option flags shown are -t for a title, -e for expiry (7d in the example) and -v for a view limit. So hemmelig "API key: sk-1234" -t "Production API Key" -e 7d -v 3 produces a titled, week-long, three-view link. Note the version skew: the CLI asset is tagged cli-v1.0.1 while the server is at v7.4.x. The README does not state a compatibility matrix between CLI and server versions, so if you pin the binary, test it against your server before wiring it into a release job. The docs/cli.md file is listed as covering all platforms and CI/CD integration examples, which is where the platform matrix and any environment-variable auth for the CLI would live.

The Maintainer Notice Is the First Line of the README

Before the banner, the README says: looking for serious maintainer(s), with a link to issue 536. That is not a footnote. A project asking for maintainers is telling you the current maintainer is at capacity, and for a security-adjacent tool that matters more than for a formatting library. The practical risk is not that the code stops working tomorrow; it is that a vulnerability report sits unreviewed, or that a dependency in the auth and encryption path goes unpatched. The release history shows v7.4.6, v7.4.7 and v7.4.8 all landing within roughly a day of each other in March 2026, which reads as rapid patch churn rather than a calm cadence, and the last push recorded is September 2026. Neither pattern tells you anything about code quality. What it does tell you is that you should read issue 536 yourself and decide whether the project has a succession plan before you make it load-bearing for your team.

The O'Saasy Licence Changes Who Can Use This

The licence is not plain MIT. The README describes it as the O'Saasy License Agreement, a modified MIT licence that prohibits using the software to compete with the original licensor as a hosted SaaS product. The repository metadata reports the licence as NOASSERTION, which means automated tooling could not classify it, so do not rely on a licence badge or an SPDX scanner to tell you what you have. For most readers this is a non-issue: running Hemmelig internally, or self-hosting it for your own clients, is not competing with hemmelig.app. It becomes a real constraint if your product is secret sharing as a service, or if you embed Hemmelig in a commercial platform where the secret-sharing capability is the thing you sell. The exact boundary of compete is defined in the LICENSE file and in the licence text, not in the README summary, and this is a legal question rather than a technical one. Read LICENSE and get your own advice before building a business on it.

Where Hemmelig Is the Wrong Tool, and What to Use Instead

Hemmelig is the wrong tool when the secret needs to be read more than a handful of times, when the recipient has no browser, or when you need an auditable record of who read what and when. Expiration and view limits are the core mechanic, so a credential that a team needs to retrieve repeatedly belongs in a secrets manager such as HashiCorp Vault or a cloud provider's secret store, where access is identity-bound and every read is logged. The difference in approach is structural: Hemmelig hands out a bearer link and destroys the payload, while a secrets manager keeps the payload and authenticates each request. That distinction also defines the failure mode. Anyone who obtains the link before the recipient does can consume it, and the view limit is spent. IP restrictions narrow that window but require you to know the recipient's address in advance, which is impractical for most one-off sharing. The optional password is the mitigation the README offers, and it is worth using whenever the link travels over a channel you do not fully control. Choose Hemmelig for one-shot handoffs; choose a secrets manager for anything durable.

Upgrade Cost, Configuration Surface and What to Check Before Committing

The repository ships docs/upgrade.md as a migration guide from v6 to v7, and the default branch is named v7, which means the older line is a different codebase with a different auth stack. If you are already running v6, that guide is the first document to read, not the Docker one. Ongoing cost is the configuration surface: DATABASE_URL, BETTER_AUTH_SECRET, BETTER_AUTH_URL, the managed-mode environment variables in docs/env.md, the optional webhook endpoint, and the Prometheus metrics and health-check endpoints if you run it under an orchestrator. Each of those is a thing to keep working across releases, and the March 2026 patch run shows releases can arrive in clusters. The SQLite default in the example keeps the database simple but ties you to the /app/database volume, so your backup story is a file copy. Verify three things before adopting: the encryption key handling described in docs/encryption.md, the CLI-to-server compatibility statement that the README does not provide, and the maintainer status in issue 536. If any of those three comes back empty, you are adopting a tool whose security model and support model you cannot yet describe to your own team.

Editorial conclusion

Adopt Hemmelig if you need a self-hosted one-time secret link service and can live with a project whose README opens by asking for serious maintainers. Do not adopt it if your business model depends on offering secret sharing as a hosted service, because the O'Saasy licence prohibits competing with the licensor as a hosted SaaS product, and do not deploy it without first reading docs/upgrade.md if you are coming from v6, since the v7 data model and auth stack changed. Before anything else, verify the maintainer situation in issue #536 and confirm that the release cadence still matches your support expectations.

Official sources

1. HemmeligOrg/Hemmelig.app on GitHub
2. Issues
3. Project website
4. README
5. Releases