Hemmelig archives its repo: what the end of a solo-maintainer project teaches self-hosters
On October 5, 2026, Hemmelig, the open-source encrypted secret-sharing platform, archived its GitHub repository and stopped all fixes, while leaving the hosted service running in a separate direction. For a self-hoster, it is a concrete reminder that a tool’s longevity depends on a maintainer, not its popularity — and that you need an exit plan.
October 5, 2026. The GitHub repository of Hemmelig is archived by its owner: no more fixes, no more features, no more releases. 1,235 commits. That is the volume of work the project accumulated before archiving — and it froze, read-only, overnight. October 10, 2026. The news spreads through the Self-Host Weekly newsletter. Why it matters: Hemmelig illustrates a structural risk of self-hosting that few tools document — dependence on a single maintainer, whose decision to continue or not conditions the security of everyone who installed the software.
What Hemmelig did, and how
Hemmelig is an encrypted secret-sharing service: it lets you pass a password, an API key or a sensitive note through a one-time link that self-destructs after reading, instead of leaving the information in a chat or an email. Its architecture is zero-knowledge: encryption happens in the browser, the server stores only encrypted data and never sees the secret or the key. The user sets an expiry, a maximum read count and an optional password, then shares the link.
Self-hosted deployment ran through Docker, with no additional container, and the project shipped most of what you expect from a modern service: a REST API with an OpenAPI spec, Prometheus metrics, health probes and SDK generation. In short, a mature, well-kept tool — until the archive.
# Hemmelig via Docker (repo archived, image still on Docker Hub)
docker pull hemmeligapp/hemmelig:latest
docker run -d -p 3000:3000 -e SECRET_LOCAL_HEMMELIG_KEY="change-me" hemmeligapp/hemmelig:latestThe nuance is in the archive notice itself. The repository is read-only and will receive no more fixes, but forks remain allowed, provided they keep the terms of the O’Saasy license — an MIT-derived license that forbids competing with the publisher by offering a hosted SaaS. Crucially, the hosted service at hemmelig.app keeps running, but “now develops in its own direction, separate from this repository.” In other words: the public code stops, the private service continues.
The alarm signal: license, maintainer and divergence
This setup — frozen public code, a proprietary service that carries on — is the episode’s most instructive signal. When an open-source project archives itself while keeping a hosted service active, the self-hoster loses more than patches: they lose traceability between what they install and what keeps evolving on the vendor side. Future security fixes, if any, will go to the hosted service, not to the repository you cloned.
The O’Saasy license adds a layer to understand. A fork is legally possible, but the “no SaaS competition” clause restricts what a successor can do with it. In practice, the project’s 124 forks are so many potential starting points, but none has the momentum, contributors or legitimacy of the original. The outcome is classic in solo open source: the code survives, the maintenance dies.
That is the heart of the problem. Hemmelig did not fail for lack of quality — the project was clean, tested and documented. It reached the end of an individual lifecycle: its maintainer, Bjarne Øverli, decided to stop public development. In an ecosystem where dozens of self-hosted tools rest on one person, that decision is the number-one risk, far ahead of the vulnerabilities everyone fears.
How to assess a tool’s maintenance risk
The Hemmelig episode provides a concrete checklist before adopting a self-hosted tool. First, look at who maintains it: a repository with a single active contributor carries a bus factor of one — any absence suspends patches. Second, measure the release cadence and security fixes over the past twelve months: a living project ships regularly, a moribund one rarely answers security issues. Third, read the license through the lens of succession: a permissive license leaves the door open to a community fork, while a restrictive license like O’Saasy complicates it.
For a service that handles secrets, the question is even sharper. An unmaintained secrets manager or encrypted-sharing tool is not software that “still works”: it is a surface that will receive no more patches, and whose dependencies — Node, Prisma, the crypto libraries — will pile up flaws with no one closing them. Hemmelig’s client-side encryption protects the content, but it does not protect the server itself from exploitation through an outdated dependency.
The alternatives worth knowing
The good news is that the ephemeral secret-sharing niche is well served in self-hosting. Yopass, PrivateBin, Password Pusher and Onetime Secret all cover the same need — client-side encryption, one-time link, expiry — with varying degrees of maturity. Password Pusher is notably active and simple to deploy; PrivateBin is a veteran of encrypted text sharing; Yopass remains popular with technical teams. For a minimal need, an encrypted note in PrivateBin often suffices where Hemmelig offered more options (files, QR, webhooks).
Choosing a replacement should apply the same checklist as above: multiple maintainers if possible, a recent patch history, a clear succession license. Migrating from an archived tool to another single-maintainer tool only moves the risk.
Verdict
If you used Hemmelig self-hosted, do not panic, but do not stay on an archived repository either: secrets you already shared have expired or are encrypted, but the instance will receive no more patches — plan a migration to Yopass, PrivateBin or Password Pusher in the coming weeks, exporting your usage patterns rather than your data. If you depend on the hosted service at hemmelig.app, know that its roadmap is now separate from the public code and decide whether you accept that divergence. And before adopting any self-hosted tool, ask the maintainer question before the feature question: software that handles your secrets is worth its maintenance continuity, not the richness of its interface. The lesson of Hemmelig fits in one sentence — a repository can die on a Tuesday, and your patches with it.