From Local to Cloud

Sign in

Install the CLI if you haven't already, then sign in. The browser opens for OAuth — pick the workspace you want to use.

curl -fsSL https://alien.dev/install | sh
alien login

Link the project

From inside the my-worker directory you created in the quickstart:

alien link

This creates a project on alien.dev (if it doesn't exist) and links this directory to it. Releases and deployments now show up in the dashboard.

Build and release

alien release

Alien builds your worker, pushes the image to a managed registry, and creates a release. Takes ~30s. Nothing is deployed to a customer's cloud yet — the release is just sitting on the platform, ready to be pulled.

Onboard a customer

You onboard each customer by minting a deployment link. In production, you'd send this to the customer's cloud admin.

alien onboard acme-corp

✓ Ready to deploy.
Customer    acme-corp

Share with the customer's admin:
  https://alien.dev/deploy/#dg_abc123...

The link opens a white-labeled deployment portal branded for your project. Alien auto-generates a project-specific CLI, Terraform module, CloudFormation template, and Helm chart from your stack — the portal lets the admin pick whichever fits their workflow.

The customer deploys

In production, the customer's admin opens the link in a browser and gets a project-branded portal with four deployment methods:

• CLI — a project-branded binary (e.g. acme-deploy) that runs the setup in one command
• Terraform — a module they drop into their existing Terraform workspace
• CloudFormation — a one-click stack launch for AWS
• Helm — for installing into an existing Kubernetes cluster

The portal renders project-branded instructions for each. For this guide, pick CLI — it's the most concise.

Since you're playing both roles, run it yourself in a terminal with credentials for your target cloud (swap aws for gcp or azure to deploy elsewhere):

curl -fsSL https://alien.dev/acme/install | sh    # one-time
acme-deploy deploy \
  --token <token-from-the-portal> \
  --name acme-corp \
  --platform aws

This provisions the compute, storage, and IAM resources native to that cloud — auto-generated from your stack definition with least-privilege roles. On AWS that means Lambda, S3, and IAM roles; on GCP it's Cloud Run, GCS, and service accounts; on Azure it's Container Apps, Blob Storage, and managed identities.

Open the dashboard's Deployments tab to watch it come up. Once it shows running, the worker is live in that cloud account.

You can also check from the CLI:

alien deployments ls

Send a command

Send a command to the worker running in the customer's cloud:

alien commands invoke \
  --deployment acme-corp \
  --command execute-tool \
  --params '{"tool": "write-file", "params": {"path": "hello.txt", "content": "Hello from the cloud!"}}'

{ "written": true, "path": "hello.txt" }

Same command you used in local dev — but this time it executed on the customer's cloud (Lambda on AWS, Cloud Run on GCP, Container Apps on Azure), writing to a real bucket in their account.

Push an update

This is where it clicks. Remember alien dev release from local dev? This is the production version.

Change your worker code — add a new tool to src/index.ts:

"list-files": {
  description: "List all files in the customer's workspace",
  execute: async () => {
    const store = await storage("files")
    const files = []
    for await (const obj of store.list()) {
      files.push(obj.location)
    }
    return { files }
  },
},

Release it:

alien release

The platform picks up the new release and rolls it out to every deployment subscribed to this project — no redeployment, no customer involvement, no downtime. Watch it in the dashboard, or:

alien deployments ls

Once it's running, try the new tool:

alien commands invoke \
  --deployment acme-corp \
  --command execute-tool \
  --params '{"tool": "list-files", "params": {}}'

{ "files": ["hello.txt"] }

You changed code on your machine, ran one command, and the worker running in the customer's cloud account was updated.

Clean up

How you tear down depends on how the customer provisioned. Pick the tab matching the deployment method used in step 3:

acme-deploy destroy --name acme-corp

aws cloudformation delete-stack --stack-name acme-corp

terraform destroy

helm uninstall acme-corp

This removes all cloud resources created for this deployment.