On this page you, an admin, give a new developer everything they need before they paste the setup line, keep the team's shared keys in place, and look after the AWS stage every machine gets. The developer's side is Set up your machine.
Run these from your own machine, set up with ./setup, in a terminal you are sitting at. An agent session can only preview them (--dry-run); the real run refuses, because it changes who can reach the company's code and AWS accounts.
gh signed in as an admin of the devstride GitHub organisation.ds team uses DEVSTRIDE_MGMT_PROFILE, else a profile named devstride-mgmt; pass --mgmt-profile <profile> to use another. If its sign-in has lapsed, the command says so: run aws sso login --profile <profile> and run it again.One command gives a new developer everything setup needs:
ds team add-developer --email jane.doe@devstride.com --github janedoe --name "Jane Doe" --dry-run
ds team add-developer --email jane.doe@devstride.com --github janedoe --name "Jane Doe"
Run it with --dry-run first: it checks everything and prints each change as would: ..., changing nothing. Then run it without. It is safe to run again: what is already in place prints as already: ..., and it only adds what is missing.
It does three things:
devstride/devstride and devstride/ds-docs with push access (no organisation membership).devstride-developers.devstride-developers and gives it AWSAdministratorAccess on the dev account only (809603945909). The group never reaches production. If the group has been given anything else by hand, the command refuses to add anyone to it until that is removed, so a new developer never inherits more than dev.The email must end devstride.com or creativecapsule.com; --any-domain allows another.
AWS sends no password email to a user created this way unless Identity Center is set to. So, unless IAM Identity Center → Settings → Authentication → "Send email OTP for users created from API" is turned on (AWS then emails them a code at their first sign-in):
The command prints this step at the end of every run.
The command also prints the steps to send the developer:
devstride/devstride and devstride/ds-docs (in their email, or at https://github.com/devstride/devstride/invitations).They also need their own claude.ai and ChatGPT accounts: those are theirs, never shared.
Two shared keys live in the agents' bundle (devstride/dev/agent-env/agent-api-keys in the dev account's Secrets Manager), and every machine gets them with ds secrets pull, which setup runs:
| Key | What needs it | Where you make it |
|---|---|---|
NEON_API_KEY | Every machine's AWS stage: setup's stage step makes each stage's database as a Neon branch with it, and ds neon runs with it. Without it, setup lists the stage under Needs you on every machine | Neon → organisation settings → API keys (an organisation key) |
SEED_TOKEN | Only ds seed deploy, a deliberate redeploy of a chosen commit. Deploys on merge need no key | Seed → organisation settings |
Add or replace one from your own machine, with the value on your clipboard, never on the command line:
pbpaste | ds secrets set agent NEON_API_KEY
ds secrets pull
Each machine picks it up on its next ds secrets pull (or ./setup). Both keys reach production today (owner decision, 2026-10-05), so treat them like production credentials. How to rotate them, and every other key's owner, is in Credentials and access.
Every machine setup runs on gets its own AWS stage in the dev account, named after the machine. Setup builds it once (about 30–40 minutes, unattended), and records it in that machine's secrets bundle (devstride/dev/agent-env/machine/<machine>). ds fleet status shows each machine's stage in its STAGE column. Besides the shared dev and prod stages, any stage that matches no machine there belongs to a machine that has been retired or wiped, and can be removed as below.
What a stage costs while idle is close to nothing:
stage-<stage>, made from golden-data) with a small compute (0.25 CU) that suspends after five minutes without queries, so it costs only while someone uses the stage;api-<stage>.devstride.dev).The hourly health check on agent machines reads the stage's records and stacks, never its database, so it does not keep the database awake.
When a machine is wiped, lost, handed on or simply no longer used, remove its stage from any machine signed in to the dev account:
ds stage remove --machine <its name> --dry-run # what it would delete
ds stage remove --machine <its name> # you retype the stage name to confirm
It deletes the stage's stacks, its config, its Neon branch, and the stage's keys in that machine's bundle. It is permanent: the stage's data and its sign-in users go with it. If the same Mac is set up again under the same name, setup builds it a fresh stage.
For an agent machine, also shut off its AWS identity, from a machine signed in to the management account with your own dev and production sign-ins:
ds machine revoke <its name> --confirm-production
The machine then gets no new AWS sessions; one it already holds ends within an hour. Every key it pulled before stays valid until rotated, so a lost machine also means rotating the shared keys: see A revoked machine still holds what it pulled.
ds team remove-developer --email jane.doe@devstride.com --github janedoe --dry-run
ds team remove-developer --email jane.doe@devstride.com --github janedoe
It removes their push access to both repositories (or cancels a pending invitation), takes their AWS sign-in out of devstride-developers and deletes it. You retype their email to confirm; it cannot be undone. Without --github, GitHub is left alone.
It refuses, and you finish by hand, when:
devstride GitHub organisation, not only a collaborator: remove them at https://github.com/orgs/devstride/people;Then finish offboarding:
ds fleet status lists their machines. For each, retire it as above: ds stage remove --machine <name>, and for an agent machine ds machine revoke <name> --confirm-production.An agent machine (one that runs Claude Code with nobody at the keyboard) gets its own AWS identity rather than a person's sign-in. Its setup needs one approval from someone who can sign with the management account, usually you, sitting at the machine while ./setup --agent <name> runs. Agent machines covers the run, the yearly renewal (ds machine enroll <name> --force, then ./setup --agent <name>) and, when you cannot be at the machine, the route where you sign its requests on your own machine.
Next: back to the Overview
Troubleshooting
What you see, why it happens and what to do, for the problems a DevStride machine or session meets most: sign-ins, Docker, credentials, demo data, machine identities, test runs and the logs to read.
How DevStride Is Built, and Why
The idea behind how DevStride is planned, built, reviewed and released — mostly by Claude Code agents walking a plan one item at a time — and why each rule exists. Read this before the mechanics.