Skip to content

Organization and keys

Everything you create on Archil belongs to a personal account or an organization: its disks, sandboxes and images, and the bill for them. An organization lets a team share disks. Members manage them, and administrators also manage who the members are.

Inside it, each region keeps its own disks and sandboxes, and an API key works in one region only.

An API key decides where you deploy

Section titled “An API key decides where you deploy”

Alchemy calls Archil’s control plane with an API key. Create one in the console under API Keys, with the account or organization you deploy to selected. It starts with key-.

Then store it in a profile, with the region your disks live in:

Terminal window
alchemy profile edit --add Archil

The key picks the organization and the profile’s region picks where every disk, sandbox and image goes, aws-us-east-1 by default. Run code against disks only in the AWS regions: gcp-us-central1 stores disks but has no serverless exec or sandboxes.

Enter your organization id too if you keep disks on your own bucket. The bucket policy only trusts Archil on behalf of that organization. See Your own bucket.

One profile per environment

Section titled “One profile per environment”

A stage decides what you deploy. The profile decides where. Give production its own organization, or at least its own key, and its own profile:

Terminal window
alchemy profile create prod
alchemy profile edit --profile prod --add Archil
alchemy deploy --stage prod --profile prod

Archil has no tags, so Alchemy tells stages apart by name. Each stage’s disks and sandboxes get names generated from the app, stage and id.

Access narrower than your key

Section titled “Access narrower than your key”

Archil can’t scope an API key, and only creates new ones from a console session, so a deployed host never gets a key of its own. Bindings that touch one disk give their host a disk user instead: an S3 key pair for ReadDisk, WriteDisk and ReadWriteDisk, or a mount token for MountDisk on your own hosts. Archil checks each one, and destroying the Stack removes them.

const files = yield* Archil.ReadDisk(Dataset);

Bindings that call the control plane (ExecDisk, CreateDisk, BranchDisk, CreateSandbox, ConnectSandbox, CreateImage) run with the key you deploy with. Rotate it in the console and redeploy.

See Credentials and bindings.

In CI

Section titled “In CI”

When ARCHIL_API_KEY is set, Alchemy uses it instead of the profile. Set ARCHIL_REGION too unless you deploy to aws-us-east-1, and ARCHIL_ORGANIZATION for disks on your own bucket:

Terminal window
ARCHIL_API_KEY=key-... ARCHIL_REGION=aws-eu-west-1 alchemy deploy --stage prod

Use a separate key for CI, so you can delete it without touching yours. See CI.

Next

Section titled “Next”

What each host gets, and who owns what your app creates while it runs, is in Credentials and bindings. What a sandbox can reach is in Network.