Apps and collaborators

An app is the top-level unit you release updates to. You create one with aether app add MyApp, which also creates its Staging and Production deployments.

Ownership

Every app has exactly one owner: the account that created it. You can hand that ownership to another registered account. Which path you use depends on whether the destination lives in the same workspace.

Same workspace

When the destination account shares your workspace, ownership moves immediately:

aether app transfer MyApp teammate@example.com

That call hits POST /v1/apps/{appName}/transfers. The new owner must already have an Aether account with that email. The previous owner becomes a Developer collaborator on the app.

Across workspaces

Most accounts registered today sit alone in their own workspace, so a teammate on another email is usually a different workspace. For that case the server creates a pending invite instead of moving ownership at once:

1. The current owner creates the invite with aether app-transfer create MyApp other@example.com (or POST /v1/app-transfers). Owner-only (app.transfer); the apps scope is required on an API key.
2. The invite stays pending for seven days. The destination account accepts with aether app-transfer accept <transferId> (or POST /v1/app-transfers/{transferId}/accept). List and accept need a browser login session. v1 sends no email; the recipient has to accept from the CLI or the dashboard.
3. The owner can cancel an outbound pending invite with aether app-transfer cancel <transferId> (or DELETE /v1/app-transfers/{transferId}). List inbound and outbound pending invites with aether app-transfer ls.

Create returns soft warnings when the destination would be over its app quota (quotaExceeded) or already has an app with the same name (nameConflict). The invite is still created. Accept runs those checks hard: a 400 leaves the invite pending until the destination frees a slot, renames the clash, or the invite expires.

On accept the app tree moves into the destination workspace. The previous owner and every other collaborator leave the app; only the new Owner remains. Monthly active device counts and overage for the billing period that was already underway stay on the old workspace; see Plans, quotas, and MAD.

CLI reference: aether app-transfer. Same-workspace moves stay on aether app transfer.

Collaborators

The owner can invite other accounts to work on the app, but only when that account already shares the app’s workspace. Signup creates a solo workspace per account, so two people who each register on their own sit in different workspaces. There is no join path yet, and the server refuses a collaborator whose account lives elsewhere with Cannot add a collaborator from an account outside this app's workspace. Cross-workspace ownership uses app transfer, not collaborator add; accepting a transfer leaves only the new Owner on the app.

aether collaborator add MyApp teammate@example.com
aether collaborator ls MyApp
aether collaborator rm MyApp teammate@example.com

Collaborators can release updates, patch release metadata, promote, roll back, and read deployments, keys, history, and metrics. These operations stay with the owner:

• Delete, rename, or transfer the app.
• Add or remove collaborators. The one exception: a collaborator can remove themselves.
• Create, delete, or rename deployments.
• Clear a deployment’s release history.

Your plan limits how many collaborators an app can have. See Plans, quotas, and MAD.