Security
How Tiller is built to keep your servers safe.
Tiller stores SSH credentials. We take that seriously. This page covers how we protect them — and what we ask of you to protect your account.
How credentials are stored
Every SSH credential — password or private key — is encrypted with AES-256-GCM using a key held in the Tiller server's environment file, separate from the database. Even a full database leak doesn't reveal credentials without the key.
How sessions work
- Login sets an HttpOnly Secure cookie,
sameSite=strict - Cookies cannot be read by JavaScript and don't traverse cross-site requests
- Sessions expire after inactivity; logging in elsewhere kicks the previous session
How the network is protected
- TLS via Let's Encrypt wildcard cert, renewed automatically every 30 days
- DNS managed via Cloudflare; cached and rate-limited at the edge
- Origin server: dedicated VPS with UFW, fail2ban, password-SSH disabled, root-key-only access
- OS updates applied automatically via "Run system updates" tooling within Tiller itself
What about the AI?
AI tools (Claude Code, Aider, Gemini, Ollama) run on your server, talk to their vendor (Anthropic, OpenAI, etc.), and never route through Tiller. Tiller can see what you see in the terminal, but doesn't intercept or store what the AI says back to you. If you're concerned about an AI vendor's data handling, that's a question for them, not us.
Reporting a vulnerability
If you discover a security issue in Tiller, please email security@tiller.run directly. Do not file a public issue. We aim to acknowledge reports within 48 hours and ship fixes for critical issues within 72 hours. We're a small team but we treat this seriously.
What we ask of you
- Use a strong, unique password for your Tiller account
- Use SSH keys instead of passwords for servers wherever you can
- Add servers only over networks you trust (if pasting a key from a coffee-shop laptop, rotate it after)
- Don't share account credentials
- If anything looks off, log out and email us