I built a self-hosted one-time secrets service in Node — here's the threat model

Sharing an API key in Slack feels wrong. Password managers work great inside a team — less great when you need a one-off secret for a contractor.

I built Seal: paste a secret, get a link, burn after read.

What it does

• AES-256-GCM ciphertext on disk
• Optional passphrase (bcrypt gate)
• Expiry + max views
• Shared rate limits across processes
• CSP + secret scrubbing in the UI
• Docker Compose one-command deploy

What it is not

It is not zero-knowledge. If you run the server, you hold SEAL_MASTER_KEY and can decrypt. That honesty belongs in the README — and it does.

Trust	Reality
Transport	Use HTTPS in production
At rest	AES-256-GCM with a server master key
Passphrase	Gates reveal — does not encrypt the payload by itself
Server operator	Can decrypt seals with the master key

Run it

git clone https://github.com/mamyan2001-gif/seal.git
cd seal
export SEAL_MASTER_KEY="$(openssl rand -hex 32)"
docker compose up --build
# → http://localhost:5080

Why I care about this shape of project

I'm a full-stack developer in Yerevan (UTC+4), open to remote roles. I like tools that are small enough to understand, honest about security tradeoffs, and runnable in under a minute.

Related open-source tools I shipped:

• Hookbox — webhook inbox + HMAC verify + replay
• Pulseboard — self-hosted HTTP uptime monitoring
• WebMask — OWASP-style website checks

Feedback on the threat model and rate-limit design is welcome — especially if you self-host PrivateBin or similar.

GitHub: mamyan2001-gif/seal