# sup3rS3cretMes5age: one-time secret messages backed by Vault cubbyholes

> The Algolia project is a self-destructing message service that stores a message in a HashiCorp Vault cubbyhole behind a token with exactly two uses, one to create and one to retrieve, so the message is gone after it is read once. It ships as a single Go binary, a Docker image and a Helm chart.

**algolia/sup3rS3cretMes5age** — Simple to use, simple to deploy, one time self destruct messaging service, with hashicorp vault as a backend

- Repository: https://github.com/algolia/sup3rS3cretMes5age
- Stars: 568 · Forks: 82
- Language: Go
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/algolia-sup3rs3cretmes5age

## The guarantee is one read, and nothing more

sup3rS3cretMes5age is described as a simple, secure, self-destructing message service that uses HashiCorp Vault as a backend for temporary secret storage. The promise in the README is that you can share sensitive information with confidence knowing it will be automatically deleted after being read once.

That single sentence defines the whole product, and it also defines its limits. This is a service for handing over one secret, once, to one recipient. It is not a password manager, not a team key store and not a way to move a file that has to arrive intact and be readable twice.

The security design is stated as Security First: messages are stored in Vault's cubbyhole backend with one-time tokens and automatic expiration. The cubbyhole is a Vault secret engine built for exactly this shape of problem, a namespace of secrets where each secret can be read and then removed, and the token that gates access is created with exactly 2 uses, create and retrieve, so the same token that writes the message is the one that reads it and then dies.

Around that core the feature list adds the practical details. The time to live is configurable, with a default of 48 hours and a maximum of 7 days. Files up to 50MB can be shared with base64 encoding. There is built-in rate limiting at 10 requests per second. TLS is supported through automatic certificates from Let's Encrypt, manual certificate configuration, or HTTP to HTTPS redirection. There is a CLI integration with shell functions for Bash, Zsh and Fish, and the whole thing has no external dependencies because all assets are self-hosted.

The primary language is Go, the licence is MIT, and the recent releases are v0.4.4 for CSP compliance and security updates on 2026-06-22, v0.4.3 in December 2025 and v0.4.1 in August 2025, the latter removing a jQuery dependency.

## Running it locally, and the Vault dev server it expects

The Quick Start claims you can be up and running in less than 2 minutes, and the commands are short.

```bash
# Clone the repository
git clone https://github.com/algolia/sup3rS3cretMes5age.git
cd sup3rS3cretMes5age

# Start with Docker Compose (recommended)
make run

# Access the application
open http://localhost:8082
```

The service starts with the application on http://localhost:8082 and a Vault dev server using in-memory storage with the token supersecret. That dev server detail is the thing to understand, because the dev server keeps everything in memory and accepts a fixed root token, so it is fine for a laptop and wrong for anything else.

If you would rather build the binary yourself, the alternative path starts a Vault container first and then runs the compiled application against it.

```bash
# Start Vault dev server
docker run -d --name vault-dev -p 8200:8200 \
  -e VAULT_DEV_ROOT_TOKEN_ID=supersecret \
  hashicorp/vault:latest

# Build and run the application
go build -o sup3rs3cret cmd/sup3rS3cretMes5age/main.go
VAULT_ADDR=http://localhost:8200 \
VAULT_TOKEN=supersecret \
SUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS=":8080" \
./sup3rs3cret
```

Three environment variables carry the configuration here. VAULT_ADDR points at the Vault server, VAULT_TOKEN is the authentication token, and SUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS sets the listen address. The same two Vault variables are the ones the production deployment section tells you to set, and the security notice is unambiguous: always run this service behind SSL or TLS in production, because secrets sent over HTTP are vulnerable to interception.

## The Make targets, and a comment about stale builds

The Makefile at the repository root is where the local workflow lives, and it reads well.

```bash
make run         # Start services (Vault + App)
make logs        # View logs
make stop        # Stop services
make clean       # Remove containers
```

The comments in the file explain one of them, and the reason is a bug worth avoiding. The run target always builds first, because docker compose up reuses an existing image without checking whether sources changed, so skipping the build step silently tests stale code. The build target also passes the VERSION, BUILD_DATE and VCS_REF arguments, which compose's implicit build does not, and without them the image ships with empty OCI labels.

That is a small thing that tells you how the project is maintained. The image build uses docker buildx with provenance and SBOM attestations enabled and builds for linux/amd64 and linux/arm64, tagging the result with the version, the commit and latest. The test target runs the Go test suite.

The compose file used by all of this is deploy/docker-compose.yml, and the application runs on port 8082 in HTTP mode by default. The README notes that you can edit that compose file to enable HTTPS, HTTP redirection or different ports.

There is also a direct compose path, if you would rather not go through the make targets at all.

```bash
docker compose -f deploy/docker-compose.yml up --build -d
```

## Deployment shapes, and the two TLS options

The deployment section covers four targets, and the table is the quickest way to see which one you want.

Kubernetes uses the included Helm chart. Docker Swarm uses the provided docker-compose.yml. AWS ECS uses the Docker image with an ECS task definition. On AWS more broadly, the AWS_DEPLOYMENT.md guide covers ECS with Fargate as the recommended option, EKS with the provided Helm chart, and EC2 with Docker Compose.

The image is published as algolia/supersecretmessage:latest on Docker Hub, for linux/amd64 and linux/arm64.

TLS is handled in one of two ways, and the choice is a real architectural decision. Option 1 is inside the container, which the README marks as recommended for simplicity: you configure it with environment variables and get automatic Let's Encrypt certificates. Option 2 is an external load balancer or reverse proxy, which gives simpler certificate management and offloads TLS processing, at the cost of having to ensure a secure network between the proxy and the container. The examples given are AWS ALB, Nginx, Traefik and Cloudflare.

The best practices list at the end of the deployment section is a sensible checklist: use HTTPS or TLS in production, use a production Vault server rather than dev mode, rotate Vault tokens regularly, enable rate limiting, monitor Vault audit logs, use strong Vault policies, and keep dependencies updated.

The production deployment section makes the Vault requirement explicit. You should deploy alongside a production Vault server and configure VAULT_ADDR with your Vault server URL and VAULT_TOKEN with the Vault authentication token.

## A frontend with no CDN, and why that matters here

The frontend section is short and its logic is specific to a service that carries secrets.

The web interface is built with modern vanilla JavaScript and has minimal external dependencies. ClipboardJS v2.0.11 at 8.9KB provides copy to clipboard, a self-hosted Montserrat font at 46KB provides typography, and custom CSS at 2.3KB does the styling. The total JavaScript bundle size is 8.9KB, previously 98KB with jQuery.

The important part is the reason. There are no external CDNs or tracking, and all dependencies are self-hosted for privacy and security. For a service whose entire purpose is carrying a secret that must not be intercepted or logged by a third party, a page that fetches its font and its JavaScript from somebody else's CDN would defeat the point. The same reasoning explains the TLS requirement, the rate limit and the instruction to use a production Vault rather than the in-memory dev server.

The dependency set in go.mod is consistent with a service that wants to own its whole stack. The Vault client and API are there, along with the Echo web framework, golang.org/x/crypto, and the testify test library. The Go version declared is 1.26.1.

The repository layout also shows the shape of the project: cmd/ for the entry point, internal/ for the service code, web/ for the frontend, deploy/ for the compose file, the Dockerfile and the Helm chart, plus AWS_DEPLOYMENT.md, CLI.md, SECURITY.md and a Makefile.

## Where the design stops working

There are three limits, and the first is a consequence of the one-read guarantee.

The first is that the model has no way to express a second read. If the recipient opens the link and does not read the message, the token is spent anyway, because the two-use token is consumed by the attempt. There is no read receipt, no way to release a message back, and no way to know whether the intended person got it. For a one-time password handoff that is exactly right, and for anything where the message might need to be retrieved twice, it is unusable.

The second is the base64 file path. Files up to 50MB are shared with base64 encoding, which means the payload is inflated by roughly a third before it is stored, and it has to live inside a Vault secret alongside the text. A 50MB file becomes a larger stored secret, and Vault is not a blob store. The size limit is what keeps this from becoming a problem, but it also means the file path is for small attachments rather than for anything substantial.

The third is the operational dependency on Vault. The application is not a standalone binary that stores its own messages, it is a client of a secret backend, and the security properties you get are the properties of that backend. That is why the README insists on a production Vault with strong policies, token rotation and audit log monitoring, and why the dev server with a fixed root token is presented as a development convenience.

On the question of how this compares to the alternatives, the honest framing is that the usual alternatives do something different. A one-time link service built on a paste site gives you a URL and an expiry but keeps the secret in that service's database. A PGP message with a passphrase gives you strong encryption without a server at all, at the cost of the recipient having tooling. What sup3rS3cretMes5age adds is the combination of a server you control, an audit trail in Vault, and the deletion as a property of the storage engine rather than as a scheduled cleanup that might not run.

## Conclusion

Adopt sup3rS3cretMes5age if you need to hand a credential or a secret to someone over the network and want the copy to disappear after a single read, since the Vault cubbyhole plus a two-use token gives you that guarantee without writing the storage layer yourself. Do not adopt it as a general password manager or a team secret store, since one read is the entire design. Before you deploy it, run it against a production Vault rather than the dev server, put it behind TLS, and note the last push was on 2026-10-20 with release v0.4.4 from 2026-06-22.

## FAQ

### What is sup3rS3cretMes5age and how does it delete messages?

It is a self-destructing message service that stores messages in HashiCorp Vault's cubbyhole backend behind one-time tokens with automatic expiration. Messages are deleted after the first read, and the token used to create a message has exactly 2 uses, create and retrieve.

### How do I run sup3rS3cretMes5age locally?

Clone the repository and run make run, which starts the Vault dev server and the application, then open http://localhost:8082. The alternative is to run a Vault container yourself, build the binary with go build and start it with VAULT_ADDR, VAULT_TOKEN and SUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS set.

### How long does a message live before it expires?

The time to live is configurable, with a default of 48 hours and a maximum of 7 days. The application also rate limits at 10 requests per second.

### Does sup3rS3cretMes5age need to run behind TLS in production?

Yes. The security notice says to always run the service behind SSL or TLS in production, because secrets sent over HTTP are vulnerable to interception. TLS can terminate inside the container with automatic Let's Encrypt certificates or at an external load balancer or reverse proxy such as an ALB, Nginx, Traefik or Cloudflare.

### What are the deployment options for sup3rS3cretMes5age?

Kubernetes with the included Helm chart, Docker Swarm with the provided docker-compose.yml, and AWS ECS with the Docker image. The AWS Deployment Guide also covers ECS with Fargate, EKS, and EC2 with Docker Compose, and the image is published for linux/amd64 and linux/arm64.

## Sources

- [algolia/sup3rS3cretMes5age on GitHub](https://github.com/algolia/sup3rS3cretMes5age)
- [Issues](https://github.com/algolia/sup3rS3cretMes5age/issues)
- [License: MIT](https://github.com/algolia/sup3rS3cretMes5age/blob/master/LICENSE)
- [README](https://github.com/algolia/sup3rS3cretMes5age/blob/master/README.md)
- [Releases](https://github.com/algolia/sup3rS3cretMes5age/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/algolia-sup3rs3cretmes5age