Cryptgeon

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

TL;DR

• What it is: Open-source (MIT) self-destructing note and file sharing service — think PrivNote, but the server is yours, the encryption key never leaves your browser, and nothing is ever written to disk [README][1].
• Who it’s for: Developers, sysadmins, and small teams who regularly share secrets (API keys, passwords, credentials, one-time tokens) and don’t want to trust a third-party service to handle them.
• Cost savings: PrivNote is free but closed-source and US-hosted. OneTimeSecret has paid team plans starting around $15/mo. Cryptgeon self-hosted runs on a $5–10/mo VPS with unlimited notes.
• Key strength: The encryption model is correct: client-side AES-256-GCM, 256-bit key never transmitted to the server, data stored only in Redis with no disk persistence. The server literally cannot read your notes even if subpoenaed [README].
• Key weakness: This is a focused single-purpose tool with 1,381 GitHub stars and limited third-party review coverage. No audit trail, no team features, no user accounts. If you need anything beyond “create and share an expiring secret,” look elsewhere.

---

What is Cryptgeon

Cryptgeon is a self-hosted web service for sharing notes and files that destroy themselves. You paste a secret, set a view count or time limit, get a link, send it. When the recipient opens the link, the note is gone. The server deletes it from Redis and has no copy [README].

The project was written by cupcakearmy (GitHub: @cupcakearmy) and is inspired directly by PrivNote, which is the dominant closed-source solution for the same use case. The GitHub description is exactly as plain as it should be: “cryptgeon is a secure, open source note / file sharing service inspired by PrivNote written in rust & svelte.” [README]

What makes it different from a basic “delete after read” implementation is the encryption model. When you create a note, the browser generates a 256-bit ID and a 256-bit encryption key. The ID goes to the server (so the note can be retrieved later). The key never does. The note is encrypted client-side using AES-GCM before being sent. When the recipient opens the link, the key is in the URL fragment — the part after # that browsers don’t send to servers — and the browser decrypts locally. The server sees only encrypted ciphertext it cannot read [README].

Three access points beyond the web UI: a CLI (npx cryptgeon send text "message"), an official Raycast extension for macOS users, and a REST API [README][1].

As of this review, the project sits at 1,381 GitHub stars [merged profile].

---

Why people choose it

The third-party review coverage for Cryptgeon is thin. AlternativeTo lists it with 5 likes and one verified user review. NicFab, a privacy-focused European blog, thought it worth writing a self-hosting guide [3] — which is a signal that the tool appeals to people who care about data residency, not just convenience.

The single AlternativeTo review [1] is short and accurate: “Simple, flexible, allows to share file, self-hostable, open source.” That’s the pitch in full. There are no breathless testimonials, no enterprise customer logos. This is a tool people choose because they’ve already decided they don’t want to send credentials through a closed-source US service, and they want to run something themselves.

The PrivNote comparison is the relevant one. PrivNote has been running since 2008 and has never had a public incident, but it’s opaque: closed-source, US-hosted, and you have no way to verify that notes are actually deleted or that encryption is actually client-side. Cryptgeon’s answer to that skepticism is an open codebase you can read, a Redis backend you can watch, and a cryptographic design where the server provably cannot read the contents [README].

The other category of people choosing Cryptgeon are teams with compliance reasons to keep secrets off third-party infrastructure — development teams sharing production API keys during onboarding, small agencies handing over client credentials after project handoffs, ops teams rotating database passwords without emailing them in plaintext.

---

Features

Based on the README, which is the most detailed public documentation available:

Core functionality:

• Share text notes or files (up to 512 MiB with SIZE_LIMIT configured) [README]
• Set view count limits — note self-destructs after N views [README]
• Set time limits — note expires after N minutes [README]
• Client-side AES-256-GCM encryption — server cannot read contents [README]
• Data stored in Redis only, never written to disk [README]
• No user accounts, no login, no history

Access methods:

• Web UI (the default experience)
• CLI via npx cryptgeon — useful for automation and scripts [README]
• Raycast extension for macOS [README]
• REST API for programmatic integration [README]

Self-host configuration (environment variables):

Variable	Default	What it controls
REDIS	redis://redis/	Redis connection [README]
SIZE_LIMIT	1 KiB	Max note/file size, up to 512 MiB [README]
MAX_VIEWS	100	Max allowed view count [README]
MAX_EXPIRATION	360	Max expiration in minutes [README]
ALLOW_ADVANCED	true	If false, forces all notes to one-view-only [README]
ALLOW_FILES	true	Enable/disable file sharing [README]

The ALLOW_ADVANCED: false setting is worth highlighting for high-security environments: it removes configuration options from users entirely and forces every note to single-view destruction regardless of what the sender requests. This is the right default for ops teams where “someone set the view limit to 50 by accident” is a real risk.

What it doesn’t have:

• User accounts or authentication
• Admin dashboard
• Note templates
• Audit logs
• Team management
• Recipient confirmation or read receipts

This is by design. Adding user accounts would mean the server knows who created which notes, which undermines the zero-knowledge property.

---

Pricing: SaaS vs self-hosted math

Cryptgeon’s economics are simple because the tool is simple.

Cryptgeon self-hosted:

• Software license: $0 (MIT) [README][1]
• VPS: $5–10/mo (Hetzner, Contabo, DigitalOcean)
• Redis: included in Docker Compose setup
• Your time to set up: under an hour for a technical user

Cryptgeon live demo (cryptgeon.org):

• Free to use, operated by the project author
• No SLA, no guarantees, fine for personal use [README]
• Not suitable for business-critical secret sharing

PrivNote:

• Free, closed-source, no self-host option
• No commercial tier

OneTimeSecret:

• Free tier: limited, US-hosted
• Individual paid plan: ~$15/mo
• Team plan: pricing not publicly listed, contact sales
• Open-source version exists but is less polished than Cryptgeon

Concrete math: If your team is using OneTimeSecret’s paid plan at $15/mo to share production credentials, a Hetzner VPS at $5.50/mo running Cryptgeon replaces that permanently. That’s roughly $115/year saved — not a dramatic headline number, but the security posture improvement is the real reason to switch, not the cost.

---

Deployment reality check

The deployment is Docker Compose with Redis. The README provides a working compose file out of the box. There is no database migration, no external state beyond Redis, and no persistent volume to manage (Redis is in-memory by design) [README].

What you actually need:

• A Linux VPS (512 MB RAM is enough — this is a lightweight Rust binary)
• Docker and docker-compose
• A domain and HTTPS via Caddy or nginx
• Nothing else — no PostgreSQL, no S3, no SMTP

What can go sideways:

The README includes an important caveat: “View counts are guaranteed with one running instance of cryptgeon. Multiple instances connected to the same Redis instance can run into race conditions, where a note might be retrieved more than the view count allows.” [README] This means you cannot horizontally scale Cryptgeon behind a load balancer without accepting that a race condition could allow a note to be read twice. For most use cases this is irrelevant — you’re not running Cryptgeon at traffic volumes that require horizontal scaling. But it’s worth knowing if you’re designing infrastructure for it.

The size limit defaults to 1 KiB, which is extremely conservative — enough for a password or API key, not enough for anything larger. You’ll want to set SIZE_LIMIT explicitly if you plan to share files. The README notes the frontend displays the limit including ~35% encoding overhead, so a 10 MiB practical limit requires setting SIZE_LIMIT to approximately 14 MiB [README].

Realistic setup time for a technical user: 20–30 minutes including domain and HTTPS. For someone following a guide with no Linux experience: 1–3 hours.

---

Pros and Cons

Pros

• Cryptographically sound design. Client-side AES-256-GCM, key in URL fragment, server never sees plaintext. This isn’t “we promise to delete it” — it’s “we mathematically cannot read it” [README].
• Zero disk persistence. Redis stores everything in memory. No database file, no backup exposure, no forensic recovery of old notes [README].
• MIT licensed. You can fork, embed, and run it commercially without legal review [1][README].
• Lightweight. Rust backend means the binary is small and the resource requirements are minimal. Runs fine on the cheapest VPS tier available.
• Multiple access methods. Web UI, CLI, Raycast, REST API covers most workflows [README].
• ALLOW_ADVANCED: false lockdown mode. Useful for teams where you want to enforce one-view-only policy at the server level [README].
• File sharing included. The same cryptographic model covers files up to 512 MiB — not just text [README].

Cons

• No audit trail. There is no record of who created a note, when it was accessed, or by whom. If you need compliance evidence that credentials were shared and received, Cryptgeon provides nothing [README].
• Race condition on scale. Multiple instances against the same Redis can serve a note more than once [README]. Not a practical problem for small teams, but worth knowing.
• Small project. 1,381 stars, one primary maintainer. The GitHub shows no recent commit date in the scraped data, and the AlternativeTo page was last updated April 2024 [1]. This is not a dead project — it’s being maintained — but it’s also not a team with a roadmap and a support channel.
• No user management. Anyone with the URL can create notes. For internal-only deployments you’ll want to put the service behind authentication (Authelia, Cloudflare Access) yourself — Cryptgeon doesn’t provide this.
• Conservative defaults require adjustment. The 1 KiB default size limit will surprise users who try to share anything larger than a password [README]. You’ll need to explicitly configure this on setup.
• No received-confirmation. You have no way to know if the recipient actually opened the note or if the view was triggered by a link scanner or proxy. This is a fundamental limitation of the single-link model, not a Cryptgeon-specific bug.

---

Who should use this / who shouldn’t

Use Cryptgeon if:

• You routinely share passwords, API keys, or credentials with teammates or clients and you’ve been doing it over Slack, email, or Notion.
• You have a compliance or security policy that prohibits sending secrets through third-party infrastructure.
• You want a self-hosted PrivNote alternative where you can verify the encryption model by reading the source.
• You’re running a small team (1–20 people) and “no user accounts” is a feature, not a limitation.

Skip it (use PrivNote or OneTimeSecret) if:

• You need something you can send someone today without a server. The hosted demo at cryptgeon.org works for personal use, but you shouldn’t rely on someone else’s demo instance for business secrets.
• You need audit logs or delivery confirmation.
• The default setup is too minimal — you want branding, templates, or organization-level settings.

Skip it (build a proper secrets manager) if:

• You’re sharing secrets across a development team regularly enough that you need rotation policies, access controls, and audit history. That’s what Vault, Infisical, or Doppler are for. Cryptgeon solves the “send this one time” problem, not the “manage ongoing access to credentials” problem.

---

Alternatives worth considering

• PrivNote — the original inspiration. Free, closed-source, well-established. Use it if you have no server and no privacy requirements. Avoid it if data residency matters.
• OneTimeSecret — more polished, has an open-source version, has a paid team tier. If you want managed hosting with some team features, this is the stronger commercial option.
• Infisical — not a direct alternative, but worth mentioning if you’re solving a broader secrets management problem. Infisical handles ongoing access to secrets across applications; Cryptgeon handles one-time sharing.
• Vault (HashiCorp) — enterprise-grade secrets management. Massively more complex, massively more capable. Not a replacement for Cryptgeon’s use case, but the answer if your problem has grown beyond “send this password once.”
• vanish.so, BurnChat, Retriever — listed on AlternativeTo as alternatives [1]; less established than Cryptgeon with smaller communities.

---

Bottom line

Cryptgeon does one thing: lets you share a secret that destroys itself, encrypted in a way the server cannot read. It does that thing correctly, with an open codebase you can verify, an MIT license you can use commercially, and a deployment footprint that fits on the cheapest VPS you can find. It is not a platform, it is not a team product, and it does not try to be. For developers and small ops teams who currently share credentials over Slack or email and know they shouldn’t, Cryptgeon is the right level of tool — small, auditable, and out of the way. The gap in third-party reviews reflects the tool’s nature: it works, people use it, and there is not much to argue about.

If setting up the VPS and reverse proxy is the blocker, that’s exactly the kind of one-time deployment that upready.dev handles for clients. Done once, you own it.

---

Sources

1. AlternativeTo — Cryptgeon listing (5 likes, 1 user review, 12 alternatives listed). https://alternativeto.net/software/cryptgeon/about/
2. NicFab Blog — List of posts (mentions “Cryptgeon: A short guide to self-hosting” as a published article). https://www.nicfab.eu/en/notes/

Primary sources:

• GitHub repository and README: https://github.com/cupcakearmy/cryptgeon (1,381 stars, MIT license)
• Official live service and documentation: https://cryptgeon.org