Push, pull, and air-gapped
A deployment model is how releases and commands reach a deployment after its initial setup, the one-time step the customer's admin runs with their own credentials. Each deployment uses push, pull, or air-gapped, depending on the platform it's deployed on.
Architecture diagram. Alien manager manages 4 remote environments: AWS account (customer-1), push · IAM role; Kubernetes (customer-2), pull · https 443; Linux hosts (customer-3), pull · https 443; Isolated site (customer-4), folder, carried in.
The models differ in who opens the connection. Alien's manager is the service that holds your releases and deployments.
- Push: the manager calls the cloud provider's APIs through a scoped management identity that initial setup created in the customer's account, such as an IAM role.
- Pull: a component inside the environment connects out to the manager over HTTPS. On Kubernetes it's the Operator; on Linux hosts, the machine agent.
- Air-gapped: there's no network path. An admin carries a folder of updates in and reports out.
The platform the admin deploys on sets the model, so one release can run push in one customer's AWS account and pull in another's Kubernetes cluster:
alien onboard customer-1 --platforms aws # push: Alien calls the cloud's APIs
alien onboard customer-2 --platforms kubernetes # pull: an Operator in the cluster connects out
alien onboard customer-4 --platforms kubernetes --airgapped # air-gapped: updates travel in a folderIn the deployment portal, the setup page Alien hosts for the admin, the deployment's page shows the model under Configuration → Delivery: Push, Pull, or Airgapped.
Who connects
| Push | Pull | Air-gapped | |
|---|---|---|---|
| Who opens the connection | Alien's manager calls the cloud provider's APIs | The Operator, a small service that runs in the environment, connects out over HTTPS about every 30 seconds | Nobody. An admin carries a folder in and out |
| Identity Alien uses | A management identity that initial setup creates in the customer's account: IAM role (AWS), service account with workload identity federation (GCP), managed identity (Azure) | The Operator's own local identity, for example a Kubernetes service account | The Operator's local identity |
| Cross-account access | Yes, scoped to the deployment's resources | None | None |
| Inbound network access | None. Calls go to the cloud provider's API, not into the customer's network | None | None |
| Platforms | AWS, Google Cloud, Azure | Kubernetes, including EKS, GKE, and AKS in a customer's cloud account; Linux servers | Kubernetes |
In both push and pull, the customer's admin runs the initial setup once with their own credentials. After that, releases roll out without the admin. See Deployment portal.
To run pull inside a customer's AWS, Google Cloud, or Azure account, the admin picks a Kubernetes cluster as the compute in the portal: a new or existing EKS, GKE, or AKS cluster. See Kubernetes.
Linux server deployments work like pull: an agent on each Linux host polls Alien over outbound HTTPS and keeps running the last plan it accepted if the connection drops.
How commands arrive
Commands are a separate axis from the deployment model. The target resource decides how a command is delivered:
| Command target | Push deployment | Pull deployment |
|---|---|---|
Worker | The manager invokes it through the cloud: Lambda (AWS), Pub/Sub (Google Cloud), Service Bus (Azure) | The Operator leases it over its outbound connection |
Container, Daemon | The workload's runtime polls the manager over outbound HTTPS | Same |
The Operator relays only Worker commands. Containers and Daemons reach the manager themselves over outbound HTTPS, through a receiver in your process. No command path needs an open port in the customer's network. See How delivery works.
Air-gapped
An air-gapped site has no network path to the manager. Releases go in, and status and logs come back, in one folder that the site's admin carries across the gap. The site runs the same Kubernetes chart as a connected deployment.
Air-gapped sites are onboarded from the CLI; the deployment portal doesn't offer them. Run alien onboard customer-4 --platforms kubernetes --airgapped. It registers the deployment and prints, for the site's admin:
- A sync token.
- Your manager's bundle key (
ed25519:...). Confirm it with the admin over a separate channel. - The command that starts the first sync.
The site shows up in alien deployments ls as customer-4/customer-4.
On a machine that can reach your manager, the admin downloads the update into a folder:
alien-deploy sync --token <sync-token> --manager <manager-url>This creates customer-4-sync/ and downloads the release the site should run. An update holds the application's images, the Operator's images, the Helm chart, and alien-deploy builds for the site. A manifest lists every file's SHA-256, and your manager signs it.
The token can only download this site's updates and send its reports. It stays on the online machine and is never written into the folder.
Inside the site, from the directory that holds the folder, the admin applies it:
alien-deploy sync \
--registry registry.internal/acme \
-f values.yaml \
--trusted-key ed25519:<bundle-key>sync then:
- Verifies the signature and every file's checksum.
- Pushes the images to the site's registry by digest.
- Installs the chart and waits up to 10 minutes for the rollout.
- Writes a report into the folder.
values.yaml maps the site's infrastructure the same way as a connected deployment. Registry credentials (--registry-username, --registry-password) become the image pull secret for the Operator and your application.
The site remembers the bundle key and refuses any update signed with another key. The registry, namespace, values, and Kubernetes context are remembered on that machine too.
Later runs need no options. Online, alien-deploy sync sends the reports and downloads the next update; inside the site, it applies it. On a machine that reaches both the manager and the cluster, one run does both.
Updates carry only image layers the site doesn't have yet. For a site whose reports never come back, alien-deploy sync --full includes every layer. alien-deploy sync --dry-run shows the release change, images, and chart resources an update would change, without changing anything.
A report holds the deployment's status and the logs the Operator collected from your application's pods since the last report. Once it reaches your manager, the site's status and logs show up like any other deployment's.
The Operator buffers up to 512 MiB of telemetry until a report is confirmed received; when the buffer is full, it drops the oldest batches. Set AIRGAP_TELEMETRY_BUFFER_BYTES on the Operator to change the limit.
To return the site to the release it ran before the last sync:
alien-deploy rollbackThe folder keeps the last three applied updates for rollback. Rollback writes a report, so your manager sees the change.
Every alien release that the site's channel receives reaches the site on its next sync. Release pins apply the same way.
The update includes the Operator version your manager runs, so the Operator updates with the application. See alien-deploy for every sync flag.
Choose a model
| Choose | When |
|---|---|
| Push | The customer is on AWS, Google Cloud, or Azure and accepts a scoped management identity. This is the default and needs nothing running in the environment besides your workloads. |
| Pull | The customer runs Kubernetes or plain Linux hosts, or their security team refuses any identity that an outside account can assume. In a cloud account, that means deploying into an EKS, GKE, or AKS cluster. |
| Air-gapped | The environment has no outbound path to the internet. Updates wait for someone to carry the folder. |
Security review
Pull deployments use only outbound HTTPS, which most environments already allow. The usual objection in a security review is cross-account access: an identity in the customer's account that an outside account can assume.
Push deployments limit that access:
- The management identity can touch only the deployment's own resources, not the rest of the account.
- The customer's admin creates the frozen resources, such as the bucket or database that holds the customer's data. The management identity can't change or delete them.
- On AWS, each customer's role requires its own ExternalId. See AWS.
- The customer can review the generated template before initial setup and revoke access by deleting the identity.
When that is still too much, pull removes cross-account access: the Operator acts with the environment's own identity, and the customer controls its permissions with their own IAM or RBAC.
Next
- Follow a deployment: statuses, reruns of initial setup, and removal
- Kubernetes: Helm install, then the Operator pulls updates
- AWS: the management role and ExternalId
- Permissions: what each identity can do