How airepeat keeps your keys safe

airepeat works with your own accounts, so it holds keys that can buy servers, change DNS and write code. Here is how we look after them.

An encrypted vaultLink to this section: An encrypted vault

Every key you type into the dashboard goes into a vault:

• It's encrypted with AES-256-GCM under a master key that lives outside the database and can be rotated by version.
• What the rest of the platform sees is a reference, such as secret: followed by an id, never the key itself.
• It's decrypted only for the job that needs it, at the moment it runs.
• It's never shown again: not in the dashboard, not in logs and not in the audit log, which records keys by name only. To change a key, you replace it.

In production, airepeat refuses to use the vault at all without its master key, so a missing setting can't quietly leave keys unprotected.

Keys for your sitesLink to this section: Keys for your sites

Some keys belong to your sites rather than to airepeat: a payment provider's secret key, an SMTP password. Those take a shorter path. You type them in once, they're held in memory for the one operation that delivers them to your Coolify, and they're dropped as soon as it finishes, after 10 minutes at most. airepeat doesn't store them anywhere.

Workspaces are separateLink to this section: Workspaces are separate

airepeat is one platform with many workspaces. Each workspace brings its own keys, servers, Coolify, GitHub, DNS and AI keys, and every query is scoped to its workspace. A workspace is only live when its owner chooses live mode and allows each provider, using that workspace's own keys.

Permissions are checked on the server for every page and every action, against your role. The interface hides what you can't do, but it's never what stops you.

Requests that can't be turned aroundLink to this section: Requests that can't be turned around

airepeat calls addresses you choose: your Coolify, an Ollama server, an SMTP host. That's a classic way to trick a server into reaching places it shouldn't, such as a private network or a cloud metadata service. So every such request:

1. resolves the host name once;
2. refuses private, loopback, link-local and metadata addresses;
3. connects to exactly the address it checked, so a second DNS answer can't swap it;
4. doesn't follow redirects automatically.

Approvals as a safety netLink to this section: Approvals as a safety net

Even with a valid key, nothing paid or destructive happens on its own. Buying a server, changing DNS or launching a site waits for a person to approve the exact request, and nobody approves their own request except an owner.

What you can doLink to this section: What you can do

• Give each key only the permissions listed in Connect your accounts.
• Turn on two-factor sign-in.
• If a key leaks, revoke it at the provider and replace it in airepeat.

The full details are in Security and keys.