Changelog
ChangelogInfrastructure

Public endpoints

Named HTTPS endpoints for Workers, Containers, and Daemons, with DNS and TLS handled per deployment in the customer's cloud.

Workers, Containers, and Daemons can now expose named HTTPS endpoints, declared in alien.ts next to the resource they serve.

Alien creates the DNS, TLS, and load balancing inside the customer's cloud. The customer's network decides who can reach each endpoint:

  • Behind the customer's VPN, for dashboards and admin tools their employees use
  • Internal only, for APIs that other services in the environment call
  • On the public internet, for webhook receivers and public APIs
const server = new alien.Container("server")
  .code({ type: "image", image: "ghcr.io/acme/server:v1" })
  .port(8080)
  .publicEndpoint("api", 8080, { protocol: "http", hostLabel: "@" })
  .publicEndpoint("app", 8080, {
    protocol: "http",
    hostLabel: "app",
    wildcardSubdomains: true,
  })
  .permissions("execution")
  .build()

Each deployment gets its own domain, and every endpoint becomes a hostname on it. In the example above, api is served at the domain itself, and app also covers *.app.<domain>, so one declaration handles per-customer subdomains. Your control plane reads the resolved URLs from the manager API instead of constructing them.

TLS works per deployment: every deployment runs in a different cloud account, so there is no shared certificate. Alien issues one for each deployment, imports it into the customer's cloud (ACM on AWS, Certificate Manager on GCP, Key Vault on Azure), and renews it automatically. Customers who manage their own certificates can bring their own domain instead; Alien never sees the private key.

Read the docs →

Alon Gubkin
Alon