Whole product
A whole-product deployment puts every service and its storage in their environment, including air-gapped sites. Unlike a self-managed installer, it stays connected to you, so you still ship releases and operate it.
Architecture diagram. Left: Your cloud, Alien manager, Releases. Right: Customer's environment containing web; api; workers; Postgres.
When it fits
- It fits when the buyer requires every component in their environment, for example on-prem, or when your product needs the host itself, such as sandboxes with nested virtualization or data on local disks.
- It's more than you need when only part of the product touches the content the requirement is about. Ask which part of the requirement is about the data. If it's the data, a data plane keeps the rest hosted.
- Remote Operator may be enough when you already ship a Helm chart, Terraform module, or ECS task and the problem is operating it across customers. Add Remote Operator, one outbound-only container, to what you already ship.
What you give up
- Every component runs in every environment. Each one is something you support in every customer's account, cluster, or data center.
- Shared services are hard to run per customer. Sign-in, analytics, and billing were built to run once. If the customer allows it, keep those hosted, so you still operate one product.
- A bigger initial setup. The customer's admin creates more frozen resources, and a release that needs to change one waits for the admin.
- Air-gapped updates wait for a person. Each release reaches the site only when someone carries it in.
What runs where
Everything in alien.ts runs in the customer's environment. The same file deploys to an AWS, Google Cloud, or Azure account, a Kubernetes cluster, or Linux servers.
If you already ship a Helm chart or container images, describe the same services in alien.ts instead of rewriting them. See Bring an existing app.
When your product needs the host itself, a Daemon runs on every machine and work is scheduled onto it. See Linux servers.
What crosses
Releases come in, and health, status, and logs go out, over the deployment's outbound connection. Your product's data stays in the customer's environment, unless your code sends it somewhere.
Logs go to the Alien manager, so treat log lines as a path that can carry content. See Paths that leak.
Updates and operations
After initial setup, the one-time step the customer's admin runs, each alien release reaches every deployment without the admin:
- Cloud accounts. Alien applies it through the cloud's APIs.
- Kubernetes and Linux hosts. The Operator, Alien's agent inside the environment, pulls it over outbound HTTPS, so nobody runs
helm upgrade.
If the connection drops, the deployment keeps running; releases and commands wait. See Push, pull, and air-gapped.
Air-gapped
An air-gapped site has no network path to Alien. It runs the same Kubernetes chart as a connected cluster. Each release, and the status and logs coming back, travel in one signed folder that the site's admin carries across the gap.
Architecture diagram. Left: Your cloud, Alien manager, Releases. Right: Air-gapped site containing Operator; your app.
Onboard an air-gapped site from the CLI. The deployment portal, the setup page Alien hosts for connected deployments, doesn't cover it:
alien onboard customer-4 --platforms kubernetes --airgappedEach update then crosses the gap in two steps:
- The admin runs
alien-deploy syncon a machine that can reach your manager, to download the update. - The admin runs it again inside the site, to verify and apply it.
Once a report comes back, the site's status and logs show up like any other deployment's. See Air-gapped.
Examples
- Full application: a gateway, dashboard, API, workers, Postgres, and Redis as one Kubernetes stack.
- Run in customer Kubernetes: a file service in connected and air-gapped clusters.
Next
- Bring an existing app: move a Helm chart or compose file onto Alien.
- Where the data plane runs: a cloud account, Kubernetes, machines, or air-gapped.
- Push, pull, and air-gapped: how releases reach each environment.
Agent or connector
Run a small agent on the customer's machines, cluster, or network that reaches their private systems and connects out to your cloud.
Classify your data
Sort every field your product stores or sends into content, derived data, describing text, credentials, and metadata, and decide with the buyer what may leave.