Security
Cloud permissions and provider support
What can The Deployer access inside your cloud account? This page answers that for each provider: the credential you create, what it allows, how long it lasts, what we store, how to revoke it, and what each provider supports today.
The short version
- Four cloud providers are supported today: AWS, Google Cloud, Microsoft Azure and DigitalOcean. Hetzner is planned and can't be used for deployments yet.
- Every connection currently uses a long-lived key or token that you create at the provider. None of them is short-lived or federated yet.
- Deployments currently need broad permissions to finish reliably. Give The Deployer a dedicated account, project or subscription, and a key used for nothing else.
- Keys are encrypted before storage. Delete the key at the provider to revoke access instantly.
1. Provider support matrix
One deployment workflow across supported providers. The exact services and features differ by provider.
| Capability | AWS | Google Cloud | Azure | DigitalOcean | Hetzner |
|---|---|---|---|---|---|
| Status | Available | Available | Available | Available | Planned |
| Apps and APIs | Yes | Yes | Yes | Yes | No |
| Managed static hosting | S3 + CloudFront | Cloud Storage | Blob static hosting | App Platform | No |
| Custom domains with HTTPS | Fully automated | May need a guided nameserver step | May need a guided nameserver step | May need a guided nameserver step | No |
| Managed databases, caches, queues, buckets | Yes | Yes | Yes | Yes | No |
| Email sending | Amazon SES | No native option | Azure Communication Services | No native option | No |
| Cost estimate before deploy | Yes | Yes | Yes | Yes | No |
| Teardown of what it created | Yes | Yes | Yes | Yes | No |
| Current credential | IAM user access key | Service-account JSON key | Service principal client secret | Personal access token | n/a |
Your provider's own quotas and regional availability still apply. See provider limits.
2. What The Deployer does with access
- Creates and changes the resources for projects you set up: servers, networking and firewall rules, load balancers, DNS zones and records, certificates, storage buckets, managed databases and caches, container services, and the IAM roles those services need to run.
- Deletes resources when you tear down a project or a service, limited to what it tagged as belonging to that project. Adopted (pre-existing) resources are never tagged, so they are never torn down.
- Reads resource state to show health, cost and status, and, if you use brownfield adoption, to discover what already exists.
- Connects to servers it created over SSH, with a key generated for the project, to deploy containers and, when you use them, to run copilot or recovery commands.
- Does not change billing settings, account-level security settings or resources outside your projects as part of its operations. That is how the software is written; the key itself would allow more, which is why a dedicated account matters.
3. AWS
| Credential mechanism | IAM user with an access key ID and secret access key, plus a default region |
|---|---|
| Identity created | You create the IAM user. The Deployer creates IAM roles for services that need one (for example CodeBuild, App Runner or an EC2 instance profile) inside your account. |
| Permissions | Broad. We do not yet publish a least-privilege policy per architecture; an AdministratorAccess user in a dedicated AWS account is what currently finishes deployments reliably. A narrower policy works for simple architectures but is the most common cause of failed deploys. |
| Can create IAM identities? | Yes, service roles for resources it deploys. |
| Can delete resources? | Yes, resources tagged to a project, on teardown. |
| Duration | Until you delete the access key. |
| What we store | The key ID and secret, encrypted; the region. |
| Revoke | IAM → Users → Security credentials → delete the access key. |
| Planned | A role in your account assumed through STS with an external ID, so no permanent key is stored. |
Step-by-step: connect AWS.
4. Google Cloud
| Credential mechanism | Service-account JSON key, project ID and region |
|---|---|
| Identity created | You create the service account. The Deployer may create service accounts for services it deploys. |
| Permissions | Broad (Editor or Owner on a dedicated project) currently finishes deployments reliably; the same least-privilege caveat as AWS applies. |
| Can delete resources? | Yes, resources it created for a project, on teardown. |
| Duration | Until you delete the key. |
| What we store | The JSON key, encrypted; project ID and region. |
| Revoke | IAM → Service accounts → Keys → delete the key (or delete the service account). |
| Planned | Workload Identity Federation, so no service-account key is stored. |
Step-by-step: connect Google Cloud.
5. Microsoft Azure
| Credential mechanism | Service principal: tenant ID, client ID, client secret and subscription ID |
|---|---|
| Permissions | A broad role (Owner or Contributor) on a dedicated subscription currently finishes deployments reliably; the same least-privilege caveat as AWS applies. |
| Can delete resources? | Yes, resources tagged to a project, on teardown. |
| Duration | Until the client secret expires. Azure makes you choose an expiry. |
| What we store | The client secret, encrypted; the IDs. |
| Revoke | Microsoft Entra ID → App registrations → Certificates & secrets → delete the secret. |
| Planned | Federated credentials or certificates instead of a client secret. |
Step-by-step: connect Azure.
6. DigitalOcean
| Credential mechanism | Personal access token and default region |
|---|---|
| Permissions | Read and write (full access). Custom-scoped tokens can work but are the most common cause of a failed deploy. |
| Can delete resources? | Yes, resources tagged to a project, on teardown. |
| Duration | Until the token expires (you choose the expiry when you create it) or you delete it. |
| What we store | The token, encrypted; the region. |
| Revoke | API → Tokens → delete the token. |
| Planned | Narrowest available token scopes, published per architecture. |
Step-by-step: connect DigitalOcean.
7. Git hosts
| Host | Credential | Why |
|---|---|---|
| GitHub | "Connect with GitHub" (OAuth app, scopes repo, admin:repo_hook, workflow) or a classic personal access token with repo (plus workflow if you want CI files committed) | Read repositories and branches, commit deploy-readiness changes you accept, register the push webhook |
| GitLab.com | Personal access token with api scope | Same |
| Bitbucket Cloud | App password, API token or access token, with your username where required | Same |
These scopes give access to every repository the account can reach, not only the ones you deploy. A GitHub App with access to the repositories you select is planned. Self-managed GitLab and Bitbucket Server are not supported.
8. Revoking access
- Delete the key or token at the provider. Access stops immediately.
- Delete the connection on the Connections page in The Deployer. The app tells you if a project still uses it.
- Resources already created stay in your account. Tear them down from The Deployer first if you want them removed, or delete them at the provider afterwards.
See also: Security and trust and permissions and security in the docs.