Supporting resources

Supporting resources are the image registry, build jobs, and cloud identities behind a stack: ArtifactRegistry, Build, and ServiceAccount. Most stacks never declare them, because Alien adds what a stack needs.

You declare one directly when a workload (a Worker, Container, or Daemon) pushes or pulls images itself, starts build jobs in the customer's cloud, or needs an identity with an inline permission set.

All three are always "frozen": the customer's admin creates them during initial setup (see Frozen and live). None has .enabled().

Names in deployment status lists what every resource Alien adds is called in the portal and the dashboard.

ArtifactRegistryCopy Anchor Link

An ArtifactRegistry is a set of container image repositories in the customer's cloud, with shared identity and access control. You provision one per stack, and Alien's build and release flow creates repositories inside it and pushes images into them.

ArtifactRegistry("images")     provisioned once: the cloud registry and its pull and push identities
  ├── images/app-a             repositories created as images are built and pushed
  ├── images/app-b
  └── images/app-c

Declare one when your stack builds and runs container images, for example for Container, Daemon, or Build resources, and you want Alien to own the registry, its IAM, and cross-account image distribution.

import * as alien from "@alienplatform/core"

const images = new alien.ArtifactRegistry("images")
  .replicationRegions(["us-west-2", "eu-west-1"]) // AWS only
  .build()

export default new alien.Stack("acme")
  .add(images, "frozen")
  .build()

The management identity can still create repositories inside a frozen registry and manage access.

OptionsCopy Anchor Link

ArtifactRegistry has no SDK client, and your code doesn't resolve it at runtime. Alien's release flow and Build resources that link it push images into it.

To push or pull with the cloud's own tools from a workload, grant a permission set:

.permissions({
  profiles: { builder: { images: ["artifact-registry/push"] } },
})

Registry platformsCopy Anchor Link

The registry is created during initial setup. Repositories are created inside it as images are built and released.

A repository is addressed by its routable name: the full, cloud-specific path used for credentials and cross-account grants.

A project id like prj_abc123 works on every cloud.

Registry guaranteesCopy Anchor Link

• Short-lived credentials. Generated credentials carry the requested permission, pull or push-and-pull, and expire. On AWS they're scoped to one repository. On GCP they reach the whole Artifact Registry repository, since every name is an image path inside it.
• Isolated cross-account grants. A grant names specific accounts, service accounts, and service types. Granting pull access to one account doesn't affect any other.
• No widened grants on GCP. Artifact Registry has no IAM below a repository, so a grant on one name would reach every name's images. Alien refuses such a grant with OPERATION_NOT_SUPPORTED instead of widening it.
  • Only the registry's own pull and push service accounts can be named.
  • To give tenants separate access, use a separate ArtifactRegistry per tenant.
• Old images stay readable after a rename. On AWS, when the registry's repository prefix changes, images released under the old prefix stay readable and keep their cross-account grants. Pushes to the old prefix are refused.

Cross-account accessCopy Anchor Link

On AWS and GCP, Alien can let other cloud accounts pull images from the registry, for example when compute in a customer's account runs images released from yours.

Grants stay cloud-specific because AWS and GCP use different identity models, and a single abstraction would lose one side.

Replication is AWS-only for a similar reason. ECR has native cross-region replication; GCP offers multi-region repositories through a different mechanism.

Registry limitsCopy Anchor Link

Per-cloud details:

• AWS. Pulls aren't throttled per repository for authenticated requests.
• GCP. No presigned URLs: layers are fetched through the registry API with a bearer token. Alien uses only the Docker format.
• Azure. The tier sets limits:
  • Basic: 10 GB, 10 writes a minute, 1,000 reads a minute. Alien's direct provisioning creates Basic.
  • Standard: 100 GB, 100 writes, 3,000 reads.
  • Premium: 500 GB, 2,000 writes, 10,000 reads. The Terraform setup template creates Premium with admin access turned off.
• Local. A local registry with basic auth and no cross-account access, for development and tests.

PricingCopy Anchor Link

The customer pays the cloud provider for the registry on their own cloud bill. Alien lists ArtifactRegistry as a free resource on Pricing.

Prices are list prices as of October 2026 in AWS us-east-1, GCP us-central1, and Azure East US.

For 10 GB of images a month:

• Pulls within the same region are usually free or close to it. Cross-region and internet egress follow standard data transfer pricing.
• On AWS, replicated images are billed as storage in each region.
• ACR Basic's 10 writes a minute can slow down release pipelines.

Sources: Amazon ECR pricing, Artifact Registry pricing, Azure Container Registry pricing.

Registry permissionsCopy Anchor Link

BuildCopy Anchor Link

A Build resource is a build project in the customer's cloud that runs a bash script in a container image on demand, for compiling, testing, or packaging code.

import * as alien from "@alienplatform/core"

const images = new alien.ArtifactRegistry("images").build()

const builder = new alien.Build("builder")
  .computeType("large")
  .environment({ TARGET: "release" })
  .link(images)
  .permissions("builder")
  .build()

export default new alien.Stack("acme")
  .add(images, "frozen")
  .add(builder, "frozen")
  .permissions({
    profiles: { builder: { images: ["artifact-registry/push"] } },
  })
  .build()

Build optionsCopy Anchor Link

Start a buildCopy Anchor Link

Build has no TypeScript or Python binding. Rust workloads start runs through the alien-bindings build binding:

The resource output identifier is the provider's project id (ARN on AWS, project id on GCP, resource id on Azure). See the Rust SDK.

Build platformsCopy Anchor Link

Compute typesCopy Anchor Link

On AWS the CodeBuild project takes the compute type from .computeType(). On GCP and Azure each run applies compute_type from its config.

RunsCopy Anchor Link

• Script. Each run executes script with bash. Alien wraps it to forward logs to the optional monitoring OTLP endpoint (path /v1/logs by default, TLS on and verified by default).
• Image. On GCP, Azure, and Kubernetes the run uses image from the run's config. On AWS the CodeBuild project uses the Alien builder image (ghcr.io/alienplatform/alien-builder) set at initial setup.
• Timeout. timeout_seconds bounds the run on GCP, Azure (replica timeout), and Kubernetes (activeDeadlineSeconds). On AWS the project's CodeBuild timeout applies.
• Retries. Kubernetes doesn't retry a failed run (backoffLimit: 0). Azure allows one replica retry.
• Logs. On AWS, logs go to CloudWatch Logs. On GCP, to Cloud Logging only.

Build permissionsCopy Anchor Link

ServiceAccountCopy Anchor Link

A ServiceAccount is a non-human cloud identity that workloads run as: an IAM role, a GCP service account, or an Azure managed identity.

You rarely declare one. Alien creates a ServiceAccount for each permission profile in the stack, and every workload with .permissions("<profile>") runs as it:

import * as alien from "@alienplatform/core"

const files = new alien.Storage("files").build()

const api = new alien.Worker("api")
  .code({ type: "source", src: "./api", toolchain: { type: "typescript" } })
  .permissions("execution")
  .build()

// Alien adds a ServiceAccount for the "execution" profile
export default new alien.Stack("acme")
  .add(files, "frozen")
  .add(api, "live")
  .permissions({ profiles: { execution: { files: ["storage/data-read"] } } })
  .build()

To declare one directly with an inline permission set:

const reader = new alien.ServiceAccount("reader")
  .stackPermissionSet({
    id: "custom/read-objects",
    description: "Read objects from every bucket in the stack",
    platforms: {
      aws: [{ grant: { actions: ["s3:GetObject"] }, binding: { stack: { resources: ["*"] } } }],
    },
  })
  .build()

ServiceAccount optionsCopy Anchor Link

ServiceAccount has no SDK binding. Workloads get its credentials automatically from the platform.

ServiceAccount platformsCopy Anchor Link

OutputsCopy Anchor Link

Identity behaviorCopy Anchor Link

• One identity per profile. A profile named execution becomes a ServiceAccount with id execution-sa. The cloud identity is named after the stack prefix and that id.
• Stack-wide grants. Permission sets under "*" in the profile attach to the identity directly. On AWS they're an inline policy on the role.
• Resource-scoped grants. Sets scoped to one resource are applied by that resource when it's created, so the grant names the exact bucket, queue, or secret.
• Grants survive their profile. A frozen ServiceAccount keeps the grants captured during initial setup, even after the profile that produced them is removed from alien.ts. Changing them takes the customer's admin running initial setup again.
• Impersonation. service-account/impersonate lets one identity act as another. On AWS it grants sts:AssumeRole on roles with the stack prefix, and the target role's trust policy lists the callers.

ServiceAccount permissionsCopy Anchor Link

Names in deployment statusCopy Anchor Link

The deployment portal and the dashboard show each resource Alien adds under a built-in name, next to its ID. A stack gets only the ones it needs, each in the category for its type (see Categories).

AWSCopy Anchor Link

Google CloudCopy Anchor Link

Google Cloud APIs appear only when the stack needs them: Artifact Registry API, Cloud Build API, Cloud Firestore API, Cloud KMS API, Cloud Quotas API, Cloud Resource Manager API, Cloud Run API, Cloud SQL Admin API, Cloud Storage API, Compute Engine API, IAM Service Account Credentials API, Identity and Access Management (IAM) API, Kubernetes Engine API, Pub/Sub API, Secret Manager API, Security Token Service API, and Vertex AI API.

AzureCopy Anchor Link

Provider registrations appear only when the stack needs them: Microsoft.App, Microsoft.ContainerRegistry, Microsoft.ContainerService, Microsoft.DBforPostgreSQL, Microsoft.EventGrid, Microsoft.KeyVault, Microsoft.Network, Microsoft.ServiceBus, and Microsoft.Storage.

KubernetesCopy Anchor Link

Kubernetes on a cloud can also get a Network. See Network.

Your machinesCopy Anchor Link

NextCopy Anchor Link

• Permissions: profiles and the identities they become
• Releases: how images are built and published
• Permission sets: every built-in set by resource