Back to Blog
team@tinypod.app

Secrets Management for Self-Hosted Apps

Hardcoded passwords and API keys in config files are a security disaster. Proper secrets management keeps your infrastructure safe.

securitysecretsdevops

The Problem


Secrets are everywhere in self-hosted apps: database passwords, API keys, JWT secrets, SMTP credentials. Where do you put them?


What NOT to Do

  • Hardcode in source code
  • Commit to git repositories
  • Store in plain text config files on the server
  • Share via Slack or email

    • Environment Variables


    The simplest approach and sufficient for most self-hosters.


    How It Works

    Pass secrets as environment variables to containers. They're never stored in the image or source code.


    docker run -e DATABASE_URL=postgres://... -e JWT_SECRET=... myapp


    Or with docker-compose / podman:

    environment:

  • DATABASE_URL=postgres://user:pass@db:5432/mydb

    • Best Practices

  • Use a .env file (never commit it — add to .gitignore)
  • Set restrictive file permissions: chmod 600 .env
  • Different .env files per environment (dev, staging, prod)

    • Secret Stores


    For more advanced setups:


    HashiCorp Vault

    Enterprise-grade secret management. Secrets are encrypted at rest, access is audited, and secrets can auto-rotate.


    Infisical

    Open-source alternative. Self-hostable (naturally). Dashboard for managing secrets across environments.


    SOPS (Secrets OPerationS)

    Encrypt secret files with age, GPG, or cloud KMS. Store encrypted files in git safely.


    Secret Rotation


    Secrets should be rotated periodically:

  • Database passwords: every 90 days
  • API keys: every 90 days
  • JWT secrets: every 30 days
  • TLS certificates: auto-rotate with Let's Encrypt

    • TinyPod Secrets


    TinyPod stores your environment variables encrypted and injects them at container runtime. You manage secrets through the dashboard — they never appear in logs or container definitions.