ComputeCluster

A ComputeCluster is the set of machine pools in the customer's account that Containers and Daemons run on. Declare one to control the pools and their hardware; otherwise Alien adds a default.

import * as alien from "@alienplatform/core"

const cluster = new alien.ComputeCluster("compute")
  .pool("general", {
    requirements: { cpu: 4, memory: "16Gi", architecture: "arm64" },
    scale: { type: "autoscale", min: 2, max: 10 },
  })
  .build()

const api = new alien.Container("api")
  .code({ type: "image", image: "ghcr.io/acme/api:1.4.0" })
  .cluster("compute")
  .pool("general")
  .cpu(1)
  .memory("2Gi")
  .port(8080)
  .permissions("execution")
  .build()

export default new alien.Stack("acme")
  .add(cluster, "frozen")
  .add(api, "live")
  .permissions({ profiles: { execution: {} } })
  .build()

In this stack:

• .permissions("execution") names the Container's permission profile, the set of cloud permissions it runs with. execution grants nothing here, because the Container uses no other resource.
• "live" means Alien creates and updates the Container on every release. See Frozen and live.

Kubernetes rejects accelerators, nested virtualization, custom container CIDRs, provider instance types, and selected zones.

A ComputeCluster is always "frozen". The customer's admin creates it during initial setup. Afterwards, during ongoing management, Alien manages only the machines inside it (see Frozen and live).

On AWS, Google Cloud, and Azure, when a stack has Containers and no cluster, Alien adds one named compute with a general pool sized from the containers.

OptionsCopy Anchor Link

ComputeCluster has no .enabled().

PoolsCopy Anchor Link

You declare hardware requirements, not instance types. The deployer picks provider machine types in deployment settings.

Use it in codeCopy Anchor Link

A ComputeCluster has no runtime binding. Workloads reach it by setting .cluster(id) and .pool(name).

Behavior and limitsCopy Anchor Link

Machine counts are the deployer's choice within your bounds. A count given as { min, max, default } lets the deployer pick a value in range during initial setup.

For the general pool Alien generates, the counts are a recommendation sized from container replicas. Initial setup offers up to 100 machines, and the deployer can go higher.

Hardware is matched, not named. Alien turns requirements into a provider machine type when the deployment is set up. The pool's cpu, memory, and ephemeralStorage are machine totals, not what's left for containers.

Changes after initial setup. containerCidr can't change once set.

A pool's machine type can change only to another catalog machine in the same cloud with the same CPU architecture, because the stack's images are built for one architecture. Alien rolls the existing machines over to the new type.

Change a running deployment's pools from the CLI:

alien deployments set-compute customer-1/customer-1 --pool general --machines 3
alien deployments set-compute customer-1/customer-1 --pool general --min 2 --max 6
alien deployments set-compute customer-1/customer-1 --pool general --machine m6i.large

The update replaces the deployment's whole pool map, so the CLI sends the other pools back as it read them. Container CPU and memory aren't sent and keep their values. Scaling a pool to 0 machines asks for confirmation; pass --yes in scripts.

What Alien manages. Initial setup creates the machine groups, identities, and network boundary. After that, with compute-cluster/management, Alien:

• changes machine counts within the declared bounds,
• rolls out new machine images,
• on AWS, changes the machine type within one architecture.

Kubernetes uses existing nodes. Pool CPU, memory, disk, machine counts, autoscaling, and failure-domain spread are the cluster administrator's. Alien enforces only architecture, through Pod scheduling, and warns that the rest isn't enforced.

PermissionsCopy Anchor Link

NextCopy Anchor Link

• Container
• Daemon
• Machines