Configuration generator

Choose settings for your self-hosted Onetime Secret installation. The generated files update as you make changes. This tool covers common choices; other settings use the application's defaults.

The settings below reflect Onetime Secret v0.26.19. Have your installation method and datastore connection details ready. You won't enter passwords or API keys here: add those values on your server after downloading the files. You can bookmark or share this page to save your choices.

The interactive generator has not loaded yet. If this message stays visible, reload the page or use the configuration reference. The controls and exports will become available when it is ready.

View generated filesHow to apply them

Deployment

Deployment mode

Simple mode stores accounts and secrets in Redis or Valkey. Choose Full mode for additional sign-in methods; it also needs a SQL database.

Simple: Redis/Valkey onlyFull: additional sign-in methods (adds SQL)

Email delivery

How outgoing mail (verification, notifications, password reset) is sent.

Generic SMTPAmazon SESSendGridLettermintSMTP2GO

Sign-in

Requires Full deployment mode.

Single sign-on (SSO)

External identity providers: OIDC, Entra ID, Google, GitHub, GitLab, and Apple. Enabling SSO also requires provider-specific settings.

Find your provider’s SSO settings

SAML 2.0

Let people sign in through a SAML identity provider, such as Okta or ADFS.

Requires Single sign-on (SSO).

Two-factor authentication

Codes from an authenticator app (TOTP), with recovery codes.

Passkeys and security keys

WebAuthn sign-in with a passkey, biometrics, or a hardware key.

Sign-in links by email

Passwordless sign-in through a one-time link sent by email.

Features

Custom domains

Let users share secrets from their own domain instead of the default host.

Multi-region / jurisdictions

Show the regional deployments you operate. Set their names and addresses in JURISDICTION and JURISDICTIONS; this option does not deploy them.

Markdown secrets

Senders can mark a secret as Markdown, which the recipient sees rendered and sanitized.

Error tracking (Sentry)

Report backend, frontend, and worker exceptions to Sentry.

Secret behavior

Require a passphrase on every secret

Default secret lifetime

5 minutes30 minutes1 hour4 hours12 hours1 day3 days7 days14 days30 days

Network

Behind a reverse proxy / load balancer

Trust X-Forwarded-For from an upstream proxy (nginx, Caddy, ALB, k8s ingress) when resolving client IPs.

Require TLS to Redis/Valkey

Require an encrypted connection to your datastore. Set its address with rediss:// or valkeys:// in VALKEY_URL or REDIS_URL.

Generated files

etc/auth.yaml

Copy Download

mode: simple

etc/config.yaml

Copy Download

emailer:
  mode: smtp
features:
  domains:
    enabled: false
  regions:
    enabled: false
  markdown:
    enabled: false
diagnostics:
  enabled: false
site:
  network:
    trusted_proxy:
      enabled: false
  secret_options:
    passphrase:
      required: false
    default_ttl: 604800
redis:
  require_tls: false

.env

Copy Download

# Secrets and connection details your selections need.
# Complete the blank values on your server and keep this file private.
# Most feature switches are in config.yaml and auth.yaml.
SECRET=
FROM_EMAIL=
SMTP_HOST=
SMTP_USERNAME=
SMTP_PASSWORD=

Fill in the blank values in .env on your server and keep the completed file private. The page URL saves your option choices, so you can bookmark it or share a setup without credentials.

Apply configuration

These files are a starting point for the options above. They do not install databases, configure an identity provider, or replace the setup steps for your Docker or Linux installation.

1. Save the YAML settings. For a new source installation, save the generated files as etc/config.yaml and etc/auth.yaml in the application directory. The application merges these settings with its shipped defaults. For an existing installation, back up your files and merge the generated keys into the matching sections; preserve your other settings and avoid duplicate YAML keys. Leave etc/defaults/ unchanged.
2. Complete your environment. Add the generated entries to your existing server environment or .env file, filling in blank values and preserving existing secrets. Full authentication mode needs a SQL database connection and the independent AUTH_SECRET, ARGON2_SECRET, and ACCOUNT_ID_SECRET values. The Docker setup guide explains secret generation and additional Compose requirements, including VALKEY_PASSWORD. Keep the completed file private and out of version control.
3. Finish any provider or network setup. For SSO, add the variables for the provider you use; the SSO switch alone does not configure a provider. For multiple regions, set JURISDICTION to this deployment's identifier and JURISDICTIONS to a list such as EU:eu.example.com,CA:ca.example.com. Set VALKEY_URL or REDIS_URL for your datastore; requiring TLS also needs a TLS-capable server and a valkeys:// or rediss:// URL. See the environment variable reference for provider credentials and connection settings.
4. Make the files available to the application. A source installation reads YAML from its application directory; ensure its service also receives your environment values. In Docker, host files are not automatically available inside the container. Bind-mount your YAML files at /app/etc/config.yaml and /app/etc/auth.yaml for the application and any workers using them. Use read-only file mounts and retain existing data volumes. Follow your installation guide to pass environment values to each service; the generator's .env snippet is not a complete Compose environment.
5. Reload and check the result. Restart the application and workers after changing their configuration. Recreate Docker containers when changing their environment or mounts. Follow Verify your install, then create and retrieve a test secret and try any sign-in method you enabled.

For settings beyond this tool, use the configuration files and precedence reference.