Keep passwords and other sensitive information out of your inboxes and chat logs.

A onetime secret is a link that can be viewed only once. A single-use URL.

Try it out on OnetimeSecret.com!

When you send people sensitive info like passwords and private links via email or chat, there are copies of that information stored in many places. If you use a Onetime link instead, the information persists for a single viewing which means it can't be read by someone else later. This allows you to send sensitive information in a safe way knowing it's seen by one person only. Think of it like a self-destructing message.

• What is a Onetime Secret?
  • Why would I want to use it?
• Latest releases
  • Get the Latest Release (Recommended)
  • Older releases
• Installation
  • System Requirements
  • Docker Installation
  • Running the Container
  • Manual Installation
• Configuration
  • Basic Setup
  • Configuration Options
  • Important Notes
  • Generating a Secure Random Key
• Miscellaneous
  • Docker-related Tips
  • Development Tips
  • Production Deployment
• Similar Services

This is the actively developed and maintained version with the most recent features and security updates.

Ruby 3 without Node.js: v0.15.0

• If you prefer a simpler setup with just Ruby dependencies (i.e. without Node.js dependencies) this is the most recent version.
• No security updates or bug fixes will be provided for this version.

Ruby 2.7, 2.6 (Legacy - Not Supported): v0.12.1

• ⚠️ Warning: This version is no longer maintained or supported.
• Only use if you absolutely cannot run Ruby 3+.
• No security updates or bug fixes will be provided for this version.

We strongly recommend using the latest release with Ruby 3+ for the best performance, security, and feature set. Legacy Ruby 2.x versions are provided for reference only and should be avoided in production environments.

• Any recent linux distro (we use debian) or *BSD or MacOS
• System dependencies:
  • Ruby 3.1+ (3.0 may work but is not officially supported)
  • Redis server 5+
  • Node.js 22+ (for front-end development)
  • pnpm 9.0.0+
• Additional packages:
  • build-essential
  • libyaml-dev
  • libffi-dev
• Minimum specs:
  • 2 core CPU (or equivalent)
  • 1GB memory
  • 4GB disk

There are multiple ways to run OnetimeSecret using Docker. Choose the method that best suits your needs:

We offer pre-built images on both GitHub Container Registry and Docker Hub.

# Pull from GitHub Container Registry
docker pull ghcr.io/onetimesecret/onetimesecret:latest

# OR, pull from Docker Hub
docker pull onetimesecret/onetimesecret:latest

If you prefer to build the image yourself:

git clone https://github.com/onetimesecret/onetimesecret.git
cd onetimesecret
docker build -t onetimesecret .

For environments requiring multi-architecture support:

git clone https://github.com/onetimesecret/onetimesecret.git
cd onetimesecret
docker buildx build --platform=linux/amd64,linux/arm64 . -t onetimesecret

We also offer a "lite" version of the Docker image, which is optimized for quicker deployment and reduced resource usage. To use the lite version:

# Pull the lite image
docker pull ghcr.io/onetimesecret/onetimesecret:latest-lite

# OR, build it locally
docker build -f Dockerfile-lite -t onetimesecret:lite .

For more information on the lite Docker image, refer to the DOCKER-lite.md documentation.

Regardless of how you obtained or built the image, follow these steps to run OnetimeSecret:

1. Start a Redis container:

   docker run -p 6379:6379 -d redis:bookworm

2. Set essential environment variables:

   export HOST=localhost:3000
   export SSL=false
   export [email protected]
   export REDIS_URL=redis://host.docker.internal:6379/0
   export RACK_ENV=production

   Note: The COLONEL variable sets the admin account email. It's a playful combination of "colonel" (someone in charge) and "kernel" (as in Linux), representing the system administrator.

3. Run the OnetimeSecret container:

   docker run -p 3000:3000 -d --name onetimesecret \
     -e REDIS_URL=$REDIS_URL \
     -e COLONEL=$COLONEL \
     -e HOST=$HOST \
     -e SSL=$SSL \
     -e RACK_ENV=$RACK_ENV \
     onetimesecret/onetimesecret:latest

   Note: Replace onetimesecret/onetimesecret:latest with your image name if you built it locally.

OnetimeSecret should now be running and accessible at http://localhost:3000.

Ah yes, the classic sudo paradox! Here's my attempt to handle this clearly:

This guide covers installing OnetimeSecret manually, whether you're working with an existing development environment or starting from a fresh system.

Required components:

• Redis Server (version 5 or higher)
• Ruby (version 3.1 or higher)
• Bundler (version 2.5.x)
• Node.js (version 20 or higher)
• pnpm (version 9.2 or higher)
• Essential build tools and development libraries

First, verify if you have the required dependencies:

ruby --version       # Should be 3.1+
bundler --version    # Should be 2.5.x
node --version       # Should be 20+
pnpm --version       # Should be 9.2+
redis-server -v      # Should be 5+

For a fresh system installation, follow these steps:

# Only if starting as root on a minimal system
apt update && apt install -y sudo

Install system dependencies:

# For Debian/Ubuntu systems:
sudo apt update
sudo apt install -y git curl build-essential libyaml-dev libffi-dev redis-server ruby3.1 ruby3.1-dev

# Install package managers
sudo gem install bundler
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
sudo npm install -g pnpm@latest

# Start Redis server
sudo service redis-server start

Note: If you see audit-related errors when installing pnpm with sudo, this is normal in containers or minimal systems where audit capabilities are limited.

git clone https://github.com/onetimesecret/onetimesecret.git
cd onetimesecret

# Install Ruby dependencies
bundle install

# Install Node.js dependencies
pnpm install

git rev-parse --short HEAD > .commit_hash.txt
cp -p ./etc/config.example.yaml ./etc/config.yaml

You can run the application in two ways:

Best for production or development without frontend changes:

1. Build frontend assets (optional, pre-built assets included):

pnpm run build:local

2. Set development mode to false in etc/config.yaml:

:development:
  :enabled: false

3. Start the server (choose environment as needed):

# For production
RACK_ENV=production bundle exec thin -R config.ru -p 3000 start

# Or for backend development
RACK_ENV=development bundle exec thin -R config.ru -p 3000 start

Best for active frontend development with live reloading:

1. Enable development mode in etc/config.yaml:

   :development:
     :enabled: true

2. Start the main server:

   RACK_ENV=development bundle exec thin -R config.ru -p 3000 start

3. Start the Vite dev server (in a separate terminal):

   pnpm run dev

When running in development mode (Option B), the application uses Vite's dev server for dynamic asset loading and hot module replacement. Here's how it works:

• In development mode (development.enabled: true), the application loads assets dynamically from the Vite dev server:

  {{#frontend_development}}
  <script type="module" src="{{ frontend_host }}/dist/main.ts"></script>
  <script type="module" src="{{ frontend_host }}/dist/@vite/client"></script>
  {{/frontend_development}}

• In production mode (development.enabled: false), it uses pre-built static assets:

  {{^frontend_development}}
  {{{vite_assets}}}
  {{/frontend_development}}

This setup enables features like hot module replacement and instant updates during frontend development, while ensuring optimal performance in production.

OnetimeSecret requires a config.yaml file for all installations. Environment variables can be used to override specific settings, but the config.yaml file must always be present.

1. Create the configuration file:

   cp -p ./etc/config.example.yaml ./etc/config.yaml

2. Review and edit ./etc/config.yaml as needed. At minimum, update the secret key and back it up securely.

The ./etc/config.yaml file is the primary configuration method. It uses ERB syntax to incorporate environment variables, allowing for flexible configuration:

---
:site:
  :host: <%= ENV['HOST'] || 'localhost:7143' %>
:domains:
  :enabled: <%= ENV['DOMAINS_ENABLED'] || false %>

In this format:

• If an environment variable (e.g., HOST) is set, its value will be used.
• If the environment variable is not set, the fallback value (e.g., 'localhost:7143') will be used.
• If you remove the ERB syntax and environment variable reference, only the literal value in the config will be used.

Key areas to configure in config.yaml:

• SMTP or SendGrid for email
• Redis connection details
• Rate limits
• Enabled locales

For quick setups or container deployments, you can use environment variables to override config.yaml settings:

export HOST=localhost:3000
export SSL=false
export [email protected]
export REDIS_URL=redis://username:password@hostname:6379/0
export RACK_ENV=production

For various deployment scenarios, including Docker setups and local development, you can use a .env file to set environment variables:

1. Create the .env file:

   cp -p .env.example .env

2. Edit the .env file with your desired configuration.

3. Usage depends on your setup:

   • For local development, load the variables before running the application:

     set -a
     source .env
     set +a

   • For Docker deployments, you can use the --env-file option:

     docker run --env-file .env your-image-name

   • In docker-compose, you can specify the .env file in your docker-compose.yml:

     services:
       your-service:
         env_file:
           - .env

The .env file is versatile and can be used in various deployment scenarios, offering flexibility in how you manage your environment variables.

• The config.yaml file is always required, even when using environment variables.
• Choose either direct environment variables or the .env file method, but not both, to avoid confusion.
• If you remove environment variable references from config.yaml, only the literal values in the config will be used.

For a full list of available configuration options, refer to the comments in the config.example.yaml file.

To generate a secure, random 256-bit (32-byte) secret key, you can use the following command with OpenSSL:

openssl rand -hex 32

If OpenSSL is not installed, you can use the dd command as a fallback:

dd if=/dev/urandom bs=32 count=1 2>/dev/null | xxd -p -c 32

Note: While the dd command provides a reasonable alternative, using OpenSSL is recommended for cryptographic purposes.

If you encounter the error "The container name '/onetimesecret' is already in use":

# If the container already exists, you can simply start it again:
docker start onetimesecret

# OR, remove the existing container
docker rm onetimesecret

After removing the container, you can run the regular docker run command again.

For Docker Compose setup, see the dedicated Docker Compose repo.

To run in debug mode:

ONETIME_DEBUG=true bundle exec thin -e dev start

When running the Vite server in development mode, it will automatically reload when files change. Ensure that RACK_ENV is set to development or development.enabled in etc/config is set to false.

We use the pre-commit framework to maintain code quality. To set it up:

1. Install pre-commit:

   pip install pre-commit

2. Install the git hooks:

   pre-commit install

This will ensure that the pre-commit hooks run before each commit, helping to maintain code quality and consistency.

To see the layers of an image and optimize your builds, use:

docker history <image_id>

When deploying to production, ensure you:

1. Protect your Redis instance with authentication or Redis networks.
2. Enable Redis persistence and save the data securely.
3. Change the secret to a strong, unique value.
4. Specify the correct domain it will be deployed on.

Example production deployment:

export HOST=example.com
export SSL=true
export [email protected]
export REDIS_URL=redis://username:password@hostname:6379/0
export RACK_ENV=production

docker run -p 3000:3000 -d --name onetimesecret \
  -e REDIS_URL=$REDIS_URL \
  -e COLONEL=$COLONEL \
  -e HOST=$HOST \
  -e SSL=$SSL \
  -e RACK_ENV=$RACK_ENV \
  onetimesecret

Ensure all sensitive information is properly secured and not exposed in your deployment scripts or environment.

This section provides an overview of services similar to our project, highlighting their unique features and how they compare. These alternatives may be useful for users looking for specific functionalities or wanting to explore different options in the same domain. By presenting this information, we aim to give our users a comprehensive view of the available options in the secure information sharing space.

Note: Our in-house legal counsel (codium-pr-agent-pro bot) suggested adding this introduction and the disclaimer at the end.

Summarized, fetched, and collated by Cohere Command R+, formatted by Claude 3.5 Sonnet, and proofread by GitHub Copilot.

The inclusion of these services in this list does not imply endorsement. Users are encouraged to conduct their own research and due diligence before using any of the listed services, especially when handling sensitive information.