Teploy
Security

Security by architecture

Teploy's self-hosted tools run on infrastructure you operate. There is no Teploy-operated deployment control plane and no usage telemetry sent to Teploy. Model, Git, webhook, and observability integrations communicate only with the endpoints you configure.

Auditable source

MIT / AGPL on GitHub — read the code, build it yourself.

No Teploy telemetry

CLI, Dash, and Observe do not report usage to Teploy.

Operator-controlled credentials

SSH, secrets, and deployment state stay on infrastructure you operate.

Reproducible builds

GitHub Actions builds the releases. SHA256 published with every tag.

Production controls

Teploy supports private mesh networking, JIT enrollment, OpenBao-backed secrets, host hardening, image scanning, audit events, staged rollouts, and restore verification. See the operations guide for the implemented controls and their boundaries.

How the CLI handles credentials

  • SSH: the CLI uses your local SSH agent and ~/.ssh keys. Connections go directly from your machine to your server. Nothing routes through teploy.com.
  • Registry credentials: Docker registry logins are written to ~/.teploy/registry.yml on your machine, with file permissions 0600.
  • Secrets: the built-in provider encrypts values with age. You can also keep deployment input encrypted in Git with age or SOPS, or use OpenBao for scoped application access and dynamic database credentials.
  • State files: deploy state lives at /deployments/<app>/ on your server. The CLI writes it and Dash reads it - no separate deployment database or out-of-band control channel.

Build & supply chain

  • Releases are built by GitHub Actions from a tagged commit on the public repo.
  • Every release ships with SHA256 checksums and, where applicable, signed Homebrew formulae.
  • Dependencies are pinned in go.mod / go.sum and reviewed before bumps.
  • Anyone can rebuild the binary from source and compare digests.

What's on your end

Because there's no managed Teploy service, your security posture is largely about how you run the tools and operate your servers. teploy setup can configure a hardened baseline, but review it against your own policy. The basics that matter most:

  • Use SSH keys, not passwords. Disable password auth on your servers.
  • Keep your server OS patched. Teploy can enable unattended security updates, but the SSH, Docker, Caddy, and application stacks still need your patch process.
  • Lock down the Caddy admin API (default: bound to localhost only — leave it that way).
  • Dash requires login by default — don't run it with --no-auth (local dev only) on a host reachable from the public internet.
  • Store age keys for encrypted secrets somewhere you'd store SSH keys — not in the repo.
  • Enable scan: true when you want Trivy to block a deploy on fixable CRITICAL image findings.

Reporting a vulnerability

If you find a security issue in any Teploy binary or in this website, please report it privately first:

  • Email [email protected] with details and reproduction steps.
  • Don't open a public GitHub issue for security bugs until a fix is shipped.
  • We'll acknowledge within a couple of business days and work with you on a coordinated disclosure timeline.
  • Good-faith research is welcome. We won't pursue legal action for testing against your own infrastructure or for finding bugs in published binaries.

There's no bug bounty program right now — this is a small project. We'll credit reporters in release notes where appropriate.