One Time Secret

Secure one-time secret sharing, honestly reviewed. Built for the use case that email was never designed for.

TL;DR

• What it is: Open-source (MIT) tool that generates single-use URLs for sharing passwords, API keys, and other sensitive data — the link self-destructs after one view [README][2].
• Who it’s for: IT admins, DevOps teams, and small companies that currently send credentials via Slack or email. Also anyone onboarding remote employees and handing over initial passwords [1][7].
• Cost savings: The hosted onetimesecret.com has a free tier. Self-hosted runs on a $5–10/mo VPS with Redis. The real saving isn’t money — it’s eliminating credentials that live forever in email threads and chat logs [2][7].
• Key strength: It does one thing, and it does it cleanly. The setup is two Docker commands. The mental model is simple enough to explain to a non-technical employee in one sentence [2][4].
• Key weakness: The mental model is simple but users still mess it up. A persistent r/sysadmin complaint: recipients open the link before they’re at their computer, or forward it to their manager who opens it first, and now you have to reset the password all over again [1].

---

What is One Time Secret

One Time Secret is a tool for sharing sensitive information through links that self-destruct on first view. You paste a password, API key, or any text into the interface, the tool generates a unique URL, you send that URL to the recipient, and when they open it, the secret is displayed once and then permanently deleted from the server [README][2].

The problem it solves is mundane but real: when you email someone a password, that password now lives in your Sent folder, their Inbox, potentially their email provider’s servers, and any backups of all the above. If either account is compromised a year from now, so is that credential. One Time Secret breaks that persistence chain [7].

The project lives at GitHub under onetimesecret/onetimesecret with 2,732 stars and an MIT license. The hosted version at onetimesecret.com has been running for years — the self-hosted option lets organizations run the same infrastructure on their own servers with their own branding and data policies [README][2].

The backend is Ruby with Redis for storage. The frontend is Node.js-built. It supports 12+ languages, custom domains, passphrase protection on individual secrets, and two authentication modes: Simple (Redis-only, suitable for smaller deployments) and Full (SQL database with MFA and WebAuthn support) [README][2].

The README is candid that AI tools (Claude, Gemini, Copilot) were used in development — a transparency note that’s still rare in open source but signals an active, maintained project rather than an abandoned one [README].

---

Why people choose it

The use case is narrow but the pain is widespread. System administrators, DevOps engineers, and anyone in IT who has ever sent a password via email or Slack has felt the discomfort of knowing that credential is now sitting in a log somewhere [7].

The r/sysadmin discussion [1] illustrates both why people reach for One Time Secret and the operational friction that comes with it. The poster deployed a self-hosted instance specifically for onboarding new remote employees — HR sends the link to a verified personal email, the employee opens it once, and the password is gone. Clean audit trail, no stored credentials in the ticketing system. The frustration isn’t with the tool; it’s with user behavior. Recipients open the link from their phone before they’re at their desk. Managers open it “just to check.” Links expire after 24–48 hours and the employee waits a week to ask for help. Now you need to reset the password again [1].

This is documented honestly because it’s the primary operational cost of using any one-time-secret tool. The tool works. The process requires user education and good workflow design — specifically: set short expiration windows, confirm receipt before the link expires, and explicitly tell recipients not to forward the link [7].

The DevOps and developer use case is stronger because the audience understands the mechanics. Sharing API keys, SSH keys, database credentials, and service tokens through One Time Secret instead of Slack DMs or email is a straightforward improvement with no workflow friction for technical users [6][7]. Source [6] covers OTS, a similar Go-based tool with client-side encryption — that comparison is worth noting: One Time Secret encrypts server-side, while OTS encrypts in the browser before it ever reaches the server. For maximum zero-trust paranoia, client-side encryption is technically stronger. For organizations running self-hosted One Time Secret on their own infrastructure, server-side encryption is usually sufficient [6][README].

The secrets management context from Cycode’s roundup [3] is worth calibrating against: One Time Secret is not a secrets manager in the HashiCorp Vault, Infisical, or Doppler sense. It does not rotate credentials, it does not inject secrets into CI/CD pipelines, it does not scan repositories for leaked keys. It is specifically and only a secure transmission layer — a way to get a credential from person A to person B without it being stored permanently anywhere [3]. Don’t buy it expecting Vault features. Buy it expecting a secure envelope.

---

Features

Based on the README, official docs, and deployment guides:

Core functionality:

• Single-use URLs — link is deleted on first view or on expiration, whichever comes first [README][2]
• Server-side encryption of stored secrets [README][2]
• Passphrase protection — recipient must enter a passphrase to view the secret [README][7]
• Configurable expiration — from minutes to days [README][7]
• Custom domains — organizations can brand the instance with their own domain [2][7]

Authentication modes:

• Simple mode (default): Redis-only storage, no user accounts, anonymous secret creation [README]
• Full mode: SQL database, user accounts, MFA, WebAuthn hardware key support [README]

API and integrations:

• REST API for programmatic secret creation and retrieval — documented in official docs [2]
• CLI-friendly for DevOps workflows [6]

Deployment:

• Docker (recommended, two-command setup) [README][2][4]
• Docker Compose with bundled Redis [README]
• Manual installation on Linux/BSD/macOS [4]
• One-click deployment on Railway [4]
• Homebrew for local/dev use [README]

Localization:

• 12+ languages supported [2]

What’s not included:

• No client-side (zero-knowledge) encryption — secrets are encrypted on the server, not in your browser before transmission. A compromised server could theoretically read secrets before they’re encrypted. For a self-hosted instance on your own infrastructure this is usually an acceptable trade-off [6][README].
• No built-in secret scanning, rotation, or vault features [3]
• No mobile app — browser only

---

Pricing: SaaS vs self-hosted math

onetimesecret.com (their hosted service): The official pricing page wasn’t accessible during research. The free tier exists and covers basic use. Data not available for specific plan limits or paid tier pricing.

Self-hosted (MIT, free):

• Software: $0
• Redis: bundled in Docker Compose or $0 on the same VPS
• VPS (minimum 2 cores, 1GB RAM, 4GB disk): $4–8/mo on Hetzner or Contabo [4]
• Domain: $10–15/year if you want custom branding

Concrete scenario: A 20-person company using one-time links for employee onboarding, contractor credential sharing, and internal API key hand-offs might generate 50–200 secrets per month. On the hosted free tier that’s likely covered. Self-hosted on a $5/mo Hetzner VPS, the annual cost is $60, you own the data, and credentials never leave your network. If your compliance requirements mandate data residency (GDPR, HIPAA, SOC 2), self-hosting moves from “nice to have” to “necessary” [2][7].

What you’re actually paying to avoid: The real math isn’t SaaS-vs-self-hosted — it’s the cost of a credential breach from Slack or email. One exposed AWS key that spins up crypto miners for a weekend runs $1,000–$10,000 in unexpected cloud bills. Source [7] cites that over 100,000 valid AWS keys have been found in public GitHub repositories. One Time Secret doesn’t prevent all of that, but it eliminates one large category of exposure [7].

---

Deployment reality check

This is the easiest self-hosted deployment in the communications/security category. The README’s quickstart is literally two Docker commands: one to start Redis, one to start the application [README][4].

docker run -p 6379:6379 -d redis:bookworm
docker run -p 3000:3000 -d \
  -e REDIS_URL=redis://host.docker.internal:6379/0 \
  -e SECRET="$(openssl rand -hex 32)" \
  onetimesecret/onetimesecret:v0.24.6

That’s it for a local or internal deployment. For production you add HTTPS via a reverse proxy (Caddy or nginx), point a domain at it, and set SSL=true in the environment. The README explicitly warns: “⚠️ WARNING: Set SSL=true for production deployments” [README].

Minimum requirements per Railway’s documentation [4]:

• 2 core CPU
• 1GB memory
• 4GB disk
• Redis 5+
• Ruby 3.4+ (for manual install)
• Node.js 22+ (for frontend development only — not needed if using Docker)

What can go wrong:

• The SECRET environment variable must be generated once and persisted. If you lose it and regenerate it, all existing encrypted secrets become unreadable. The README calls this out explicitly and tells you to back it up [README].
• Upgrading from v0.22 or v0.23 requires following specific migration guides — the README links to them. Blindly pulling the latest image on an old install will break things [README].
• The “Full” authentication mode (SQL + MFA + WebAuthn) requires a database migration and additional configuration. If you start in Simple mode and switch later, there’s a documented process [README].

Realistic time estimate: 15–30 minutes for a technical user on a fresh VPS. 1–2 hours for a non-technical founder following the official docs, including HTTPS setup. The Docker Compose path removes most of the complexity.

---

Pros and cons

Pros

• Solves the problem completely. If your goal is “stop sending passwords in Slack and email,” this tool does that with minimal overhead [README][7].
• Two-command Docker setup. The fastest path to a running self-hosted security tool in this list. You can be live in under 10 minutes [README][4].
• MIT licensed. Fork it, brand it, embed it in your client-facing onboarding portal. No commercial agreement needed [README].
• Custom domains and branding. Run it as secrets.yourcompany.com with your logo. Looks professional in client and employee communications [2][7].
• Passphrase protection. Two-factor delivery: the link is one channel, the passphrase is another. Even if someone intercepts the link, they can’t read the secret without the passphrase [README][7].
• REST API. Automatable — you can generate one-time links from scripts, onboarding workflows, and Terraform outputs without touching the UI [2][6].
• Full auth mode with MFA and WebAuthn. For organizations that want user accounts and hardware keys, it’s built in — not an add-on [README].
• Genuinely no data retention. Secrets are deleted after first view. There’s no “deleted but archived” trap [README].

Cons

• Users open the link wrong. The r/sysadmin thread [1] documents this at length: recipients open the link from their phone before they’re at their computer, forward it to someone else, or just sit on it until it expires. This isn’t a software bug — it’s a human behavior problem — but it generates real operational overhead.
• Server-side encryption, not zero-knowledge. Secrets are encrypted on the server. If the server is compromised, secrets in transit could theoretically be read. The alternative (OTS, with client-side AES-256 encryption) is architecturally stronger for maximum paranoia [6]. For self-hosted instances on your own infrastructure, this is typically fine.
• Redis as the only storage for Simple mode. Redis is in-memory by default. Without persistent storage configuration, a server restart loses all pending secrets. Requires explicit Redis persistence setup for production [README].
• Ruby backend. Not a problem per se, but Ruby is less common in modern DevOps stacks. If you need to customize or extend the backend, your team needs Ruby skills [4][README].
• No built-in secret scanning. It’s not trying to be Vault or Infisical, but worth stating: this does not detect leaked credentials in your repos or CI/CD pipelines [3].
• Upgrade friction between major versions. v0.22→v0.23 and v0.23→v0.24 each have separate migration guides. Not a dealbreaker, but plan maintenance time around upgrades [README].

---

Who should use this / who shouldn’t

Use One Time Secret if:

• You’re an IT admin or ops team sending passwords to new hires and you want to stop using email for credentials.
• You’re a developer or DevOps engineer sharing API keys, database passwords, or SSH keys with teammates.
• You need GDPR/HIPAA-compatible credential sharing with a provable “secret was viewed and deleted” audit trail.
• You want custom-branded secret sharing at secrets.yourcompany.com for client-facing use.
• You’re already running Docker and want this done in 15 minutes.

Skip it if:

• You need a full secrets manager — dynamic secret rotation, CI/CD injection, vault with access policies. Use Infisical, Vault, or Doppler instead [3].
• You need zero-knowledge architecture where even the server operator can’t read secrets. Look at OTS (Go, client-side AES-256 encryption) [6].
• Your team primarily uses a password manager with secure sharing built in (1Password, Bitwarden) — those already solve this at the storage layer.
• You want passwordless or SSO-only authentication without any setup. Simple mode has no user accounts at all.

---

Alternatives worth considering

• Password Pusher — similar concept, Ruby-based, also self-hostable. Slightly more feature-rich UI, supports file sharing. Direct competitor [7].
• Bitwarden Send — if your team already uses Bitwarden, Send is built into the same app. No separate deployment needed. End-to-end encrypted.
• Yopass — open-source, Go-based, client-side encryption using AES in the browser. Stronger zero-knowledge story than One Time Secret [7].
• OTS — Go-based client-side encryption alternative. AES-256 in the browser, server never sees the plaintext. 519 stars, simpler codebase [6].
• Privnote — hosted-only, no self-hosting. Fine for personal use, not appropriate for organizational credential sharing [7].
• Infisical — if you need One Time Secret plus secrets management, vault, and CI/CD injection, Infisical is open source and self-hostable. More complex, more powerful [3].

For a non-technical founder or IT admin who just wants to stop emailing passwords, the realistic shortlist is One Time Secret vs Password Pusher. One Time Secret wins on community size (2,732 stars vs Password Pusher’s roughly similar range) and documentation quality. Password Pusher has a slightly more polished UI and supports file attachments. Both are solid.

---

Bottom line

One Time Secret is the curl of security tooling: small, focused, does one thing correctly, and is genuinely useful even when the alternative seems “good enough.” The alternative being email and Slack, which are not good enough for credential sharing. The tool’s MIT license, two-command Docker setup, and passphrase support make it a straightforward self-hosted deployment for any team that’s currently pasting passwords into chat logs. The main operational challenge isn’t the software — it’s user training. Recipients will open links at the wrong time, forward them to the wrong person, and wait too long. That’s documented and real [1]. Plan for it with short expiration windows and a clear “do not forward” instruction in your process. If you need zero-knowledge architecture or a full secrets vault, look elsewhere. If you need “stop sending passwords in email, right now, this week,” One Time Secret deploys in an afternoon and solves the problem permanently.

---

Sources

1. r/sysadmin — “Explaining a ‘One Time Secret’ to users is infuriating…” — reddit.com. https://www.reddit.com/r/sysadmin/comments/1jtqw7c/explaining_a_one_time_secret_to_users_is/
2. Self-Hosting Overview | Onetime Secret - Docs — docs.onetimesecret.com. https://docs.onetimesecret.com/en/self-hosting/
3. Cycode Team — “The Best Secrets Management Tools of 2026” — cycode.com. https://cycode.com/blog/best-secrets-management-tools/
4. Railway — Deploy and Host Onetime Secret — railway.com. https://railway.com/deploy/one-time-secret
5. Spiceworks Community — “A good selfhosted application to share password?” — community.spiceworks.com. https://community.spiceworks.com/t/a-good-selfhosted-application-to-share-password/941235
6. GitHub Open Source — “OTS: Your One-Time Secret Sharing Solution” — dev.to. https://dev.to/githubopensource/ots-your-one-time-secret-sharing-solution-secure-simple-and-self-destructing-38ch
7. “OneTimeSecret Use Cases — Share Passwords Securely” — onetimesecret.info. https://onetimesecret.info/use-cases.php

Primary sources:

• GitHub repository and README: https://github.com/onetimesecret/onetimesecret (2,732 stars, MIT license)
• Official documentation: https://docs.onetimesecret.com