Astrolift standalone (AWS)¶

Astrolift on its own: a dedicated VPC, Aurora cluster, Temporal, load balancer and EKS tenant cluster, with the control plane (API, console, worker, Temporal) on ECS beside the cluster. Nothing is shared with anything else in the account, and it tears down on its own.

Not yet validated end to end

Written from the installer source as of release 0.1.57. No step on this page has been run end to end on a clean AWS account yet. Read the known blockers first: they stop a clean-account run before the first plan applies.

What you need¶

The common prerequisites, and these values for What we need from you:

Field	Example	Notes
Deployment name	`acme-prod`	Up to 16 characters; prefixes every resource
Domain	`apps.example.com`	The control plane answers here; apps answer under it
Hosted zone ID	`Z1D633PJN98FT9`	The public Route 53 zone for the domain, dedicated to this deployment
VPC CIDR	`10.40.0.0/16`	The network Astrolift creates

Optional groups: Astrolift application images (backend and frontend image references; the Deployment Manager pins its own otherwise), managed IDE runtime, app sign-in (a separate apps domain and zone, or an existing Cognito client), and Advanced: footprint (NAT, log retention, node types and counts, Spot share, GPU nodes, cluster autoscaler, task sizes).

Choose it¶

Choose what to install: Standalone, tick Astrolift.
Pick the cloud: AWS and a region.
Pick a footprint.
Review the drawing: the defaults build the shape above. "Where the Astrolift controller runs" stays ECS, beside the cluster. Under Advanced, "Tenant runtime" stays Create a cluster.
Fill in the values above, review Before we start, and finish setup.

The card resolves to one unit, Astrolift, with its state at astrolift-deployment.tfstate.

Apply¶

On Install:

Dry run Plan Astrolift, read the plan, then Deploy it.
The apply runs the post-apply phases, including the database bootstrap task, and fails the job if the bootstrap fails. A failed bootstrap keeps the apply evidence; the phases can be retried without applying the plan again.

Verify¶

With the default answers the control plane answers at the domain itself (the apps domain), and astro.<domain> and astrolift.<domain> redirect to it. Apps get names under the same domain.

Status shows the deployment and its services.
The control plane's health route, which the load balancer also checks:
```
curl -fsS https://<domain>/healthz
```
In the AWS console, the EKS cluster <deployment>-astrolift exists and its node groups are active.

First app and first agent run¶

Once you can sign in to the console:

Configure the CLI against https://<domain>.
Register a first app, then deploy and verify it.
Author and register an agent, then dispatch and observe a run.

Undo¶

Teardown, Astrolift, keep data or with data; type the deployment name (and destroy data for the latter); read and deploy the destroy plan. The hosted zone you delegated and the records Astrolift left in it are kept. Then remove the state store and the Deployment Manager as in Undo.