What permissions we need & how we keep them safe
Connecting your cloud and git accounts gives The Deployer real access, so it's fair to ask exactly what it uses, how that access is stored, and what you should do on your side. This page lays out the current model plainly, including the parts we plan to improve.
What each connection uses today
Every connection is a credential you create at the provider and paste in (or, for GitHub, authorize with a button). These are long-lived credentials: they keep working until they expire or you revoke them.
| Provider | Credential The Deployer stores |
|---|---|
| AWS | An IAM user access key (Access Key ID + Secret Access Key) |
| Google Cloud | A service-account JSON key |
| Microsoft Azure | A service principal (app registration) with a client secret |
| DigitalOcean | A personal access token |
| GitHub | An OAuth authorization (Connect with GitHub, scopes repo, admin:repo_hook, workflow) or a classic personal access token with repo |
| GitLab.com | A personal access token with the api scope |
| Bitbucket Cloud | An app password or Atlassian API token (with your username or email), or an access token |
Why cloud access is currently broad
A single deployment creates many kinds of resources in sequence: servers, networking, storage, DNS, certificates, and sometimes managed databases. We don't yet publish a least-privilege policy for each architecture, so a narrowly scoped credential is the most common reason a deploy stops partway with "access denied". For now, broad permissions (for example AdministratorAccess on AWS, Owner or Editor on Google Cloud, Owner on Azure, a full-access token on DigitalOcean) are what make deploys finish reliably.
Broad access is a real risk, so contain it:
- Use a dedicated cloud account, project or subscription for The Deployer's resources. A separate AWS account, Google Cloud project, Azure subscription or DigitalOcean team means a broad credential can't reach unrelated production systems.
- Create a dedicated key just for The Deployer. Don't reuse a personal key or one used by other tools.
- Set expirations where the provider supports them (GitHub tokens, GitLab tokens, Azure client secrets) and rotate the rest on a schedule.
You can scope a credential down if your organization requires it. The trade-off is that a policy missing a permission a deploy needs will make that deploy fail.
How stored credentials are handled
- Encrypted before storage. Every credential is encrypted before it's written to the database.
- Used by the deployment engine, not placed in AI prompts. Provider credentials are decrypted and used only by the deployment engine, the non-AI part that runs deploy steps. Deployment plans carry references to secrets rather than the values, and credentials are not placed in AI model prompts.
- The project copilot can run commands on your app server. The copilot chat can connect to your app's server over SSH to investigate problems. Commands matching a blocked list are refused, changes it proposes (such as enabling a service or redeploying) need your one-click confirmation, and command output is redacted for known secret values before the model sees it. Redaction catches known values, not every possible secret, so avoid printing secrets on your server.
- Masked on the Connections page. Cards show only a masked hint (the last few characters).
- Full credentials can be revealed. After you re-enter your account password, the View credentials action shows the full stored credential. Wrong-password attempts are rate-limited, and each reveal is recorded in an internal audit log. There is no audit view in the app yet. See Viewing & replacing your credentials.
- Verify-before-replace. A replacement credential is tested first; a bad one is rejected and the old one keeps working.
Revoking access
- Delete or deactivate the credential at the provider. This disables it immediately, wherever it's stored.
- Delete the connection in The Deployer (the trash icon on its card). A connection still used by a project can't be deleted until that use is removed.
Deleting a connection doesn't delete resources already created in your cloud account. Tear those down from the project first if you no longer need them.
If a credential may have leaked, revoke it at the provider first, then create a new one and use Replace credentials.
What's planned
These are planned and not available yet:
- Role-based AWS access through STS (a cross-account role instead of an IAM user key)
- Google Cloud workload identity federation instead of service-account JSON keys
- Azure federated credentials instead of client secrets
- A GitHub App that you install on selected repositories only
- Write-only stored credentials: once saved, a credential can be replaced or revoked but not revealed
- Published least-privilege policies per provider and architecture
Until then, the dedicated account and dedicated key above are the most effective way to limit what a connection can reach.