KamalCloud reaches your infrastructure on your behalf: it logs in to your servers over SSH and calls your cloud provider's and git host's APIs. That makes it a sensitive place to keep credentials. This page describes what KamalCloud actually does today. It does not describe plans.
Not in your request path
Your applications run on your own servers, in your own cloud account, as ordinary Kamal containers. Traffic to them never passes through KamalCloud. If KamalCloud is unavailable or compromised, your sites keep serving. What an attacker would gain is the ability to act on your infrastructure, which is why the rest of this page matters.
Credentials at rest
These are encrypted in KamalCloud's database, at the application level, before they are stored:
- Cloud provider API tokens and secrets
- Git host integration keys, OAuth tokens and webhook secrets (GitHub, GitLab, Gitea, Bitbucket)
- Your applications' secret values
- Access keys for backup storage buckets
- The private halves of the account's SSH keys
- Your AI provider API key
- Notification channel destinations, such as Slack and Discord webhook URLs
A one-time password you give KamalCloud to install its key on a machine is used for that one session and never reused.
API tokens
- Only a digest of each token is stored. It is shown once, when it is created, and cannot be shown again.
- Tokens carry a
kc_prefix, so one that leaks into a log or a repository is easy to spot. - Tokens can be revoked at any time.
- A token cannot change your infrastructure directly. At most it can propose a change, and a person has to approve it in the browser. The approval is recorded against both the token and that person.
SSH access to your servers
- Each account has two SSH keys: a control key that KamalCloud uses to reach runners and servers, and a deploy key that Kamal uses. Keys are not shared between accounts.
- Your own keys and your own access to your machines are left untouched.
- Browser shells into running containers are available to account admins only. Each one is recorded with who opened it and when, and closes after an hour at most. What is typed is not stored.
- Deployment logs are kept so you can review them. Tokens embedded in git clone URLs are redacted from those logs.
Signing in
- Passwords are stored as bcrypt hashes.
- Sign-in, sign-up, password reset, join codes and invitations are rate-limited.
- Password resets use single-purpose, expiring tokens sent by email.
- Sessions use a signed,
HttpOnly,SameSite=Laxcookie. Each session records the IP address and browser it was started from. - All traffic to the app is served over HTTPS only.
- Passwords, tokens, secrets, keys and email addresses are filtered out of the application's request logs.
Accounts are isolated
Every request and every background job runs scoped to a single account. People, servers, apps, secrets and logs in one account are not visible from another. We test for this specifically.
What we do not have yet
Leaving these out would give a false impression:
- Two-factor authentication and single sign-on
- A history of configuration changes, such as who changed a secret or a role. Actions like deploys, backups, restores and shell sessions are already recorded.
- Third-party certifications or audits, such as SOC 2 or ISO 27001
Your part
- Give KamalCloud cloud tokens scoped to the project, team or account it should manage, rather than your whole organisation.
- Use a strong, unique password, and remove people from the account when they leave.
- Revoke API tokens you no longer use.
Reporting a vulnerability
Email ted@martinconsultants.business with "Security report" in the subject. Include enough detail to reproduce the issue. Please give us a reasonable chance to fix it before disclosing it publicly, and do not access data that is not yours or disrupt the service while testing. We will reply, keep you updated, and credit you if you want.