Enclosed

Self-hosted secure note sharing, honestly reviewed. For teams tired of emailing passwords in plaintext.

TL;DR

• What it is: An open-source (Apache-2.0), end-to-end encrypted web app for sending self-destructing private notes and files — think OneTimeSecret, but you own the server [README][1].
• Who it’s for: Developers, security teams, and ops people who routinely share credentials, API keys, or sensitive text and want those secrets to never touch a third-party server or a Slack log [2].
• Cost savings: The public instance at enclosed.cc is free. Self-hosting costs $5–10/mo on a minimal VPS. Commercial alternatives like OneTimeSecret’s business plans charge monthly per user — data on their exact current pricing not available, but self-hosting eliminates that bill entirely [2][README].
• Key strength: Genuine AES-GCM 256-bit end-to-end encryption with zero server knowledge, a dead-simple UI that non-technical recipients can use without instructions, and Cloudflare Workers support that makes serverless deployment a single command [README][1].
• Key weakness: No team management, no audit logs, no access controls, no SSO. If you need to see who sent what secret to whom, Enclosed has no answer for that. It’s a single-purpose utility, not a secrets management platform [README][3].

---

What is Enclosed

Enclosed is a minimalistic web application for sending private, end-to-end encrypted notes and file attachments. The author introduced it on r/selfhosted [1] as “basically PrivateBin but simpler and with a focus on security” — which is an accurate and useful description. You write a note, optionally set a password and expiration, get a link, share the link. The recipient opens it, reads it, and it’s gone if you set it to self-destruct.

What matters technically: the encryption happens in the browser before anything hits the server. The server stores ciphertext only. The decryption key lives in the URL fragment (#key), which browsers don’t send to servers in HTTP requests. So even if the Enclosed server is compromised, the attacker gets encrypted blobs with no keys attached [README].

The cryptography stack: AES-GCM with a 256-bit key derived via PBKDF2 with SHA-256. When you optionally add a password, that password combines with the base key to derive the master key — meaning even someone with the link can’t read the note without the password [README]. This isn’t novelty cryptography; it’s standard browser-native WebCrypto API implementation.

As of this review, the project has 1,963 GitHub stars and an Apache-2.0 license — meaning free for commercial use, modification, and distribution without restriction [merged profile]. The live demo at enclosed.cc is run by the author and available for immediate use without an account.

---

Why people choose it

The Reddit thread [1] that launched the project shows the clearest picture of why people reach for it. The recurring answer: “I want to share a password or API key with someone without putting it in Slack, email, or a chat tool that stores it forever.”

The direct alternative people mention is PrivateBin. The difference Enclosed’s creator emphasizes is UI minimalism and cleaner UX for non-technical recipients. PrivateBin is functional but its interface reads like a developer tool. Enclosed looks like something you’d hand to a client who has never opened a terminal [1][README].

The Hostinger page [2] lays out the use cases that actually drive adoption:

• Security teams sharing passwords, API keys, and credentials with colleagues or external partners
• Developers exchanging configuration secrets, connection strings, and deployment tokens during handoffs
• Healthcare and regulated industries needing encrypted transmission with expiration controls
• Customer support sending temporary credentials via password-protected, expiring links

The common thread: information that needs to travel over an untrusted channel (email, Slack, SMS) and self-destruct once delivered. These are the moments when “just copy-paste it into a message” is genuinely risky, and Enclosed is the simplest possible solution.

The Cloudflare deployment option [1][README] is worth calling out. You can deploy Enclosed to Cloudflare Workers with Cloudflare KV as storage — meaning zero server management, near-zero cost at low volume, and global edge distribution. For someone who doesn’t want to manage a VPS, this is a meaningful alternative to spinning up a Docker container.

---

Features

Based on the README and official documentation:

Core functionality:

• End-to-end encryption using AES-GCM 256-bit keys derived with PBKDF2 SHA-256 [README]
• Zero knowledge server — ciphertext only, decryption key never leaves the client [README]
• Configurable note expiration (1 hour, 1 day, 1 week, 1 month, or no expiration) [3][README]
• Self-destruct after reading option [README][2]
• Password protection as an additional authentication layer before decryption [README]
• File attachments — share files alongside notes [README]
• Maximum encrypted payload: 50MB by default, configurable [3]

Sharing and access:

• Shareable links with the decryption key embedded in the URL fragment [README]
• REST API for programmatic note creation [merged profile]
• CLI (@enclosed/cli on npm) for creating notes from the terminal [README]
• Optional email/password authentication to restrict who can create notes on your instance [README][3]

Deployment options:

• Docker (single container, minimal resources) [README][2]
• Docker Compose [README]
• Cloudflare Workers + KV (serverless, no VPS required) [README][1]
• npm for custom node deployments [merged profile]

Customization and UX:

• Multi-language UI (English, Indonesian, Vietnamese, and others) [README][2]
• Dark mode [README]
• Responsive design, works on mobile [README]
• Configurable defaults (default TTL, whether no-expiration is allowed, default self-destruct behavior) [3]

What it doesn’t have:

• Team management or user roles
• Audit logs showing who sent what
• SSO or LDAP integration
• Secret versioning or a secrets vault pattern
• Any server-side search or note history

The configuration documentation [3] shows a mature set of environment variables — CORS settings, HTTPS configuration, periodic cleanup tasks, storage backend options. This isn’t a weekend hack; the configuration surface is well-considered for a self-hosted deployment.

---

Pricing: SaaS vs self-hosted math

Enclosed hosted at enclosed.cc:

• Free, no account required, run by the project author [README]

Self-hosted:

• Software: $0 (Apache-2.0) [merged profile]
• Cloudflare Workers deployment: free tier covers significant volume; Cloudflare KV costs cents at low note volumes [README]
• VPS deployment: $5–10/mo (Hetzner, Contabo, or DigitalOcean smallest tier) [2]
• Your time: 15–30 minutes with Docker, faster with the official Cloudflare deploy path

Why self-host instead of using enclosed.cc: The public instance is run by an individual developer. If it goes down, changes behavior, or gets shut down, your workflow breaks. Organizations in regulated industries or with data residency requirements can’t use a third-party instance regardless of cost [2]. And if you’re sharing internal credentials, even an encrypted note on someone else’s server means your ciphertext lives in a place you don’t control.

SaaS comparison context: For teams already using tools like OneTimeSecret’s business plans, Bitwarden Send (Bitwarden Premium at $10/year includes Send), or enterprise password managers with secure sharing — the cost equation varies by existing stack. Specific current pricing for OneTimeSecret’s commercial plans is not available in the sources for this review. What’s clear is that self-hosted Enclosed on a $6 VPS costs $72/year regardless of note volume, and the Cloudflare path can cost less than that at modest usage [2][README].

The honest math: if you’re not already paying for a secrets-sharing service, the cost argument is less about saving money and more about not starting to pay for something you can self-host for almost nothing.

---

Deployment reality check

The fastest path to a running instance is one Docker command [README]:

docker run -d --name enclosed --restart unless-stopped -p 8787:8787 corentinth/enclosed

That gives you a working instance in under a minute. For persistent storage, you mount a volume. For HTTPS, you put Caddy or nginx in front. The documentation [3] covers Docker Compose, persistent volumes, rootless images, and native HTTPS configuration through environment variables.

What you actually need for a VPS deployment:

• A Linux VPS with 512MB–1GB RAM minimum (very lightweight) [2]
• Docker installed
• A reverse proxy for HTTPS (Caddy is the simplest option — automatic certificate management)
• No external database required — Enclosed uses filesystem storage by default

The Cloudflare path is genuinely zero-infrastructure. Deploy to Workers, bind a KV namespace, done. No server to patch, no container to update. The periodic cleanup task that deletes expired notes isn’t available in the Cloudflare environment [3], which means expired notes sit in KV until the next access or manual cleanup — a minor operational consideration, not a blocker.

Configuration gotchas from the docs [3]:

• The default JWT secret is literally change-me — you must set AUTHENTICATION_JWT_SECRET before exposing a public instance with authentication enabled
• HTTPS is optional (you can terminate TLS at a reverse proxy instead) but native browser WebCrypto APIs require a secure context — so HTTP-only deployments for anything other than localhost testing don’t work
• The AUTHENTICATION_USERS variable expects bcrypt hashes, not plaintext passwords — the docs provide a generator utility, but it’s an extra step that catches people on first setup

Realistic time to production:

• Technical user with Docker experience: 20–30 minutes including domain setup
• Non-technical user following a guide: 1–2 hours
• Cloudflare Workers deploy: 10–15 minutes

The r/selfhosted thread [1] drew 0 deployment complaints — the setup experience isn’t a pain point people flag, which is itself a good signal.

---

Pros and Cons

Pros

• Real cryptography, properly implemented. AES-GCM 256-bit, PBKDF2 key derivation, encryption in the browser, key in the URL fragment. This isn’t security theater — it’s standard WebCrypto API used correctly [README].
• Zero knowledge by design. The server stores ciphertext. There’s nothing to subpoena, breach, or accidentally expose except blobs the server can’t read [README][2].
• Extremely low resource footprint. Single container, filesystem storage, no database dependency. Runs on the smallest VPS tier or free Cloudflare Workers. This is not a resource hog [2][README].
• Apache-2.0 license. Genuinely free for commercial use, modification, or embedding. No “fair-code” restrictions, no commercial clause surprises [merged profile].
• Cloudflare Workers support. Serverless deployment path is a real differentiator — no server management, global edge performance, near-zero cost [README][1].
• CLI included. @enclosed/cli lets developers script note creation — useful for deployment pipelines that need to pass secrets to external parties [README].
• REST API. Programmatic access for custom integrations [merged profile].
• Non-technical recipients don’t need an account. The UX is share-a-link, open-the-link — no friction for the person receiving a secret [1][2].
• Rated A+ on websitecarbon.com. Minor but genuine — the app is as lightweight in the browser as it is on the server [README].

Cons

• No audit trail, ever. You cannot see who created which note, when it was read, or by whom. For teams with compliance requirements, this is a hard blocker [README][3].
• No team management. No roles, no groups, no per-user note visibility. Authentication is a binary (can create notes / cannot create notes) [3].
• No SSO or directory integration. User management is a static list of email:bcrypt-hash pairs in an environment variable [3]. Adding a user means editing config and redeploying.
• Single-purpose utility, not a platform. There’s no dashboard of sent notes, no integrations with password managers, no search. If you want a secrets management system, this isn’t it — it’s a one-shot sharing mechanism [README].
• Expired notes cleanup doesn’t work on Cloudflare. Notes don’t auto-delete in the Cloudflare KV backend [3] — minor but worth knowing if you’re running a high-volume instance on that path.
• No notification when a note is read. You send a link, you don’t know if or when it was opened. Read receipts would require server-side logging, which conflicts with the zero-knowledge design — but it’s a real operational gap for some use cases [README].
• Young project, one primary maintainer. 1,963 GitHub stars is a healthy signal of interest, but the project depends on a single developer’s continued attention. Not a knock against it — just the reality of an individual open-source project [merged profile].

---

Who should use this / who shouldn’t

Use Enclosed if:

• You or your team regularly shares credentials, API keys, or sensitive text over Slack, email, or chat and want a better pattern.
• You need encrypted sharing with clients or external contractors who can’t be given access to your internal tools.
• You want self-destruct-after-reading so secrets don’t persist in a recipient’s inbox.
• You’re deploying on Cloudflare Workers and want zero-maintenance infrastructure.
• You want Apache-2.0 licensed software you can embed in your own product or white-label for clients.
• Your organization has data residency requirements that rule out third-party services.

Skip it if:

• You need to audit who shared what and when — Enclosed has no answer here.
• You need SSO, LDAP, or integration with your identity provider — the static user list won’t scale past a handful of accounts.
• You want a full secrets management system (HashiCorp Vault, Infisical, Doppler) — Enclosed is a one-shot sharing tool, not a secrets vault.
• You need read receipts or confirmation that a note was opened.
• You’re in a regulated environment that requires detailed access logs — Enclosed’s zero-knowledge design means there are no logs to produce.

Consider the hosted version at enclosed.cc if:

• You’re an individual who needs this occasionally and has no data residency requirement.
• You want to evaluate the tool before committing to self-hosting.

---

Alternatives worth considering

• PrivateBin — the direct predecessor Enclosed positions itself against [1]. More feature-complete (discussions, syntax highlighting, attachments), but the UI is denser and less approachable for non-technical recipients. Also self-hostable, also zero-knowledge, also free.
• Yopass — similar concept (one-time encrypted secrets), backed by Redis, simpler feature set than Enclosed, less polished UI.
• Bitwarden Send — included with Bitwarden Premium ($10/year). If your team already uses Bitwarden as a password manager, Send is the least-friction path. Doesn’t require self-hosting, but you’re dependent on Bitwarden’s infrastructure unless you self-host Bitwarden (which is a larger operational commitment).
• Snappass — Pinterest’s open-source tool, Python-based, Redis-backed. Functional but less actively maintained than Enclosed.
• OneTimeSecret — the commercial reference point in this category. Hosted service with paid business plans. Zero self-hosting effort, but your secrets touch their servers.
• Infisical / Doppler / Vault — if you’ve outgrown one-shot sharing and need a proper secrets management platform, these are the next tier up. Significantly more complex to operate, significantly more capable.

For the “I just need to send a password to someone without it sitting in their email forever” use case, the realistic shortlist is Enclosed vs PrivateBin. Pick Enclosed if you want a cleaner recipient experience and simpler self-hosting. Pick PrivateBin if you need discussion threads or advanced formatting.

---

Bottom line

Enclosed does one thing: lets you send a secret that can’t be read by the server, expires on a schedule, and optionally disappears after being opened once. It does that one thing correctly — real AES-GCM encryption, real zero-knowledge architecture, real browser-native WebCrypto — and it does it with enough UI restraint that a non-technical recipient can open a link and read a note without needing to understand what happened. For developer teams that have normalized sending credentials over Slack or in plain-text emails, this is the tool you deploy once and stop thinking about. A $6 VPS, 20 minutes, and the pattern is fixed permanently. The trade-offs are real — no audit logs, no team management, no read receipts — but those are features of a different product category. If you need a secrets vault, look at Infisical. If you need to share a secret once and have it vanish, Enclosed is the answer.

---

Sources

1. r/selfhosted — “Enclosed - Minimalistic web app for sending private and secure notes” (author introduction post). https://www.reddit.com/r/selfhosted/comments/1f068u9/enclosed_minimalistic_web_app_for_sending_private/
2. Hostinger — “Enclosed VPS Docker Hosting | One-Click Deployment” (deployment guide and feature overview). https://www.hostinger.com/au/vps/docker/enclosed
3. Enclosed official docs — “Self-Host Configuration” (environment variables, configuration reference). https://docs.enclosed.cc/self-hosting/configuration

Primary sources:

• GitHub repository and README: https://github.com/corentinth/enclosed (1,963 stars, Apache-2.0 license)
• Official website and live demo: https://enclosed.cc
• Self-hosting documentation: https://docs.enclosed.cc/self-hosting/docker
• CLI package: https://www.npmjs.com/package/@enclosed/cli