Onboarding Customers
Once you've released your app, onboarding a customer is two steps:
- You create a deployment group and mint a deployment link.
- The customer's admin opens the link in their browser and picks a deployment method.
After that, the admin is done. Updates roll out automatically on every alien release.
Create a deployment group
A deployment group is one customer. It can hold a single deployment or many (prod, staging, regional). All deployments in the group share the same release stream and configuration.
alien onboard acme-corp✓ Ready to deploy.
Customer acme-corp
Share with the customer's admin:
https://alien.dev/deploy/#dg_abc123...The link is short-lived — mint a fresh one any time with alien onboard acme-corp. If the group already exists, re-running fails with a name conflict; mint a new token from the existing group in the dashboard.
In the dashboard:
- Open Deployments → New deployment → Generate deployment link
- Enter a name (e.g.
acme-corp) - Copy the deployment link and send it to the customer
The same link works from both flows.
What the customer sees
The deployment link opens a white-labeled portal branded for your project — your name, logo, and accent color (customize in the Portal Studio). Alien generates a project-specific CLI, Terraform module, CloudFormation template, and Helm chart from your stack — the portal presents them as four deployment methods the admin can pick from.
| Method | Best for |
|---|---|
CLI — a project-branded binary (e.g. acme-deploy) | One-command setup; smallest blast radius |
| Terraform | Customer's platform team already uses Terraform |
| CloudFormation | One-click AWS launch via the AWS console |
| Helm | Installing into an existing Kubernetes cluster |
All four produce the same result: the isolated area, the deployment identity, and the initial deployment of your code. The portal renders project-branded instructions and the exact commands to run.
Watch it come up
Open the Deployments tab in the dashboard, or from the CLI:
alien deployments lsNAME GROUP PLATFORM STATUS LAST SEEN
acme-prod acme-corp aws running 2m agoOnce the status is running, the deployment is live in the customer's cloud.
Pre-configuring environment variables
Pass plain or secret env vars at onboarding time — they apply to every deployment created from this group:
alien onboard acme-corp \
--env LOG_LEVEL=info \
--secret OPENAI_API_KEY=sk-...In the dashboard, configure the same under Deployments → New deployment.
Multiple deployments per customer
A deployment group can hold many deployments — useful when a single customer runs production, staging, and regional instances. The admin runs the same setup once per environment, each with its own --name:
acme-deploy deploy --token <token> --name acme-prod --platform aws --region us-east-1
acme-deploy deploy --token <token> --name acme-staging --platform aws --region us-east-1
acme-deploy deploy --token <token> --name acme-eu --platform aws --region eu-west-1All three show up in the same group in the dashboard.
Pre-baking env vars per environment
Target specific deployments using :targets syntax:
alien onboard acme-corp \
--env LOG_LEVEL=debug:acme-staging \
--env LOG_LEVEL=info:acme-prod,acme-euTroubleshooting
Deployment link says "expired"
Deployment links are short-lived. Mint a fresh one with alien onboard <name>, or open the deployment group in the dashboard and generate a new token.
Deployment stuck in "provisioning"
Check the deployment detail page in the dashboard — it shows live resource-by-resource status with any errors from the cloud provider.
Customer's admin says the cloud command failed
Cloud errors usually come from missing permissions in the credentials the admin used during setup. The portal shows the minimum required role at the top of each method's instructions.