Skip to content

Cloud accounts and integrations

Connect the AWS accounts and the machines your organization already has, then switch on what DevBench may do in each.

Where
CloudIn the app (sign-in required), opens in a new tab.
Reading time
3 min read
Who
Can manage deployments to see it; adding or removing an account is owner-only.

How it works

Two halves, kept deliberately separate: credentials say who DevBench is in an account, and feature toggles say what it may build there.

Connections are organization-scoped, unlike a git token, which stands in for a person. An AWS account is shared infrastructure, the bucket a workspace is served from should not become unreachable because whoever pasted the key left. Secrets are encrypted at rest and have no read path in the API; identifiers like the access key id and account id are returned, because that is how you tell two credentials apart mid-rotation.

AWS. Credentials can be a plain IAM user's keys, or keys whose only right is to assume a role in the target account. What you can switch on: a static site in one bucket behind CloudFront, several sites pooled in one bucket, Lightsail, RDS, EC2, and Elastic Beanstalk. Switching one on runs a preflight against the real account first: IAM is asked to simulate that feature's required actions without performing any of them. If the account may not simulate its own policies, normal for a tightly scoped deploy user, a read-only probe runs instead and the result is recorded as a warning, never as ok: "the service answered" is a weaker claim than "the account is allowed". A denied action fails with the exact missing actions, which the page turns into a pasteable IAM policy.

Bring your own box. The other integration covers machines you already rent: any host over SSH, plus Hetzner, DigitalOcean and Vultr for the accounts machines come from, and Supabase and MongoDB for data. Checking a capability here asks whether the software is actually installed, Docker, Node, Python with venv, nginx and certbot, the Postgres client, and a missing package refuses the toggle and returns the command that installs it.

Host keys are verified, not accepted. The first successful SSH connection records the fingerprint; every one after that requires a match, and a mismatch fails loudly with both fingerprints rather than connecting. Re-trusting is a deliberate, owner-only, logged act, because a host key changes when a box is rebuilt and when someone is intercepting you.

Everything is re-checked on a schedule, and a failure reaches the owners' Inbox, throttled per account, with the throttle cleared the moment it recovers. Keys that start authenticating as a different AWS account bypass the throttle entirely.

Steps

Following along? Tick each number off as you go.

  1. Open Cloud from Ship in the top bar (or the search: Ctrl Ctrl, ⌘ ⌘ on a Mac).

  2. Press Connect and choose AWS or a provider.

    The form asks for exactly what that provider needs.

  3. Paste the credentials and save.

    They are verified against the real account before they are stored, a bad key fails here.

  4. Open the account and switch on the capabilities you want it used for.

    Each runs a preflight first.

  5. If a toggle is refused, copy the generated IAM policy (AWS) or the install command (SSH) and give it to whoever has the access.

    That is usually not the person looking at the screen, which is why it is generated rather than described.

  6. Use Resources to see what already exists in the account, and link each one to the part of a repo it serves.

    That is how DevBench knows this Amplify app serves web/ and that EC2 box houses services/api.

  7. Press Verify on an account after rotating a key.

Worth knowing

  • Destructive calls (Delete*, Terminate*, Stop*, IAM changes) are refused unless the workspace's grant allows them.

  • A connection whose last check failed contributes no deploy targets, which stops a picker offering something that cannot be reached.

Commands

The same job from a workspace's box, for people who live in the terminal.

devbenchinside the box
  • $ devbench cloud canWhat this workspace may do in the cloud, and how far.
  • $ devbench cloud listDeployments that already exist in the org's cloud accounts.
  • $ devbench cloud link <id> <repo>[/<dir>]Record which part a resource serves.
  • $ devbench cloud call <service> <Operation>One AWS call through DevBench, no credentials are ever given to a box.

Read next

Code and shippingDeploy and testRun this branch as live containers to click through it, and record where staging and production actually live.Code and shippingAppsThe repositories that make up one application, with the commands that build and run each part.Running the organizationTeam, roles and permissionsWho is in the organization, what each role reaches, who may spend money in the cloud, and how new people join.
Report a problem