Remote operator
The AI agent for BYOC operations.
One container. Zero open ports. Customer-approved.
- #ext-customer-1D
ingestion has been slow since this morning
👀33 repliesLast reply 2 hours ago - #ext-customer-2N
queries time out after the upgrade
👀33 repliesLast reply 2 hours ago - #ext-customer-3R
we upgraded Postgres to 16 and it won't start
👀33 repliesLast reply 2 hours ago - #ext-customer-4B
any update? this is blocking our launch
👀33 repliesLast reply 2 hours ago - #ext-customer-5M
getting 503s on the internal endpoint
👀11 repliesLast reply 2 hours ago - #ext-customer-6A
disk is at 92% on the data node
👀11 repliesLast reply 2 hours ago
A lightweight container in each customer deployment,
connected over outbound HTTPS to your control plane.
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
├── service.yaml
+ └── operator.yaml
# values.yaml · one block per installation
+operator:
+ registrationToken: <shown once>
Add it to the Helm chart, Terraform, Pulumi, or ECS task your customers already install. Enable it one customer at a time.
Not broad access and not credentials,
but a list of predefined operations each customer can review.
Built-in operations.
Ready to use on the stack your product runs on.
See all operationskubernetes/get-podskubernetes/restart-podYour own operations.
Turn your runbooks into operations for your product. One function per operation, published under your name. Same policy and approvals as the built-in ones.
Build custom operations// Read-only. Runs on its own under most customer policies.
async fn shard_status() -> PluginResult {
let shards = indexer::shards().await?;
PluginResult::success_json(&json!({ "shards": shards }))
}
// Mutating. Waits for the customer's approval.
async fn rebuild_index(shard: &str) -> PluginResult {
indexer::rebuild(shard).await?;
PluginResult::success_json(&json!({ "rebuilt": shard }))
}
Every operation is declared read-only or mutating, and each customer’s policy is written in those terms.
Start with the built-in ones, or scaffold your own plugin with alien operations init.
Give your own agents the superpower of fixing customer deployments,
with one customer approval per fix.
every query is timing out since the upgrade this morning, opened a ticket with the vendor
Over CLI and MCP. One time-boxed access request covers the operations a fix needs, and the customer approves it once, in Slack or with kubectl.
Reads their policy allows run right away. Everything inside the window is recorded.
Or just tag Alien’s agent in Slack.
Follows every install and every release.
It follows every install to healthy and watches every release. When one fails, it reads your repo at that commit.
What it watchesNew deployment customer-7/prod registered from your CloudFormation stack. Following the rollout.
Answers when you tag it.
Same operations, same policy, same approvals. It opens a scoped session, traces the failure, and tells you whose side it’s on.
See an investigation@Alien what’s going on with Customer 1’s deployment? checkout is down
Thought for 34s
checkout is in CrashLoopBackOff: AccessDenied: dynamodb:GetItem. Its IAM role lost that permission at 8:52, changed in their account. Nothing on our side changed.
Sent their DevOps the one-line policy fix in #ext-customer-1. I’ll confirm here once the pods are Ready. 🤦♂️
Each customer decides which operations run on their own
and which wait for their approval.
Same operations, three answers. Access expires on its own. A bigger action never inherits approval from a smaller one.
Approved where the customer already works.Time-bound and scoped to named operations.
Slack, kubectl, and more.
The request names the operations, the reason, and how long. Approval unlocks exactly those.
How approvals work6-hour access request
Why: ingestion latency reported this morning
Scope: production · namespace app
- Kubernetes / logs, events, workloads ·
app - Kubernetes / restart one pod · separate approval required
- AWS / SQS, CloudWatch · read
What their security team reviews.
No inbound port, no cross-account role. Credentials never leave the customer’s account.
What they review- Inbound ports0
- VPN, bastion, jump hostnone
- Cross-account rolenone
- OutboundHTTPS 443 to your control plane
- Credentialsstay in the customer’s account
- Kubernetes accessone ServiceAccount, namespace-scoped
Everything around the operation.
Every deployment, one heartbeat away.
Health, version, and connection per customer. An offline site keeps its queue.
Inventory and health3f9a2c11s ago3f9a2c11s agob47e0d9offline 42:003f9a2c11s ago3f9a2c11s agoA record of every request, approval, and result.
Who asked, who approved, what ran, what it changed, whether it worked.
Audit log- Access requestedengineer · kubernetes/restart-pod · 6h · reason attached
- Approved by your teamCustomer 1 / prod confirmed as the target
- Approved by the customerSlack · expires 15:47
- kubernetes/restart-podpod=ingester-p4kwm · 18.7s · SUCCEEDED
- Verifiedreplacement Ready · queue age 47m → 4m
White-labeled, end to end.
The release, the image, the CRD, the Slack app. Your customers never see the word Alien.
Branding- Helm releaseacme-operator
- Container imageregistry.acme.io/operator
- Access request CRDaccessrequests.acme.io
- ServiceAccountacme-operator
- Slack appAcme Support
- The word “Alien”nowhere
When it does not fit an operation.
A time-boxed, recorded session with kubectl, aws, gcloud, or az. Same approval, same record.
Remote debugging$ alien debug customer-1/prod --duration 30m -- kubectl get pods -n app
session dbg_2q8x4v · approved by the customer · recorded · expires in 30m
NAME READY STATUS RESTARTS AGE
api-7f8c 2/2 Running 0 6d
ingester-p4kwm 1/2 Running 3 6d
$ alien debug customer-1/prod -- aws sqs get-queue-attributes --queue-url $Q
{ "ApproximateNumberOfMessages": "2310842" }
Run the control plane in your cloud.
No new subprocessor for your customers. The operator only ever talks to you.
What their security team asks.
What can the vendor run in our environment?
Only the operations you enabled, each one named and declared read-only or mutating. There is no shell by default. Your policy says which operations run on their own and which wait for your approval.
How does it reach us?
It does not. One container in your deployment opens an outbound HTTPS connection and pulls its work. No inbound port, VPN, bastion, or cross-account role. Its permissions are one ServiceAccount and the cloud identity you give it.
Who approves a change?
You do, per operation, with kubectl or in Slack. Approval is time-bound and runs nothing by itself. Each operation in the window is recorded on its own, and the approval lands in your own audit log too.
How do we turn it off?
Delete the release. The container stops, its RBAC is removed, and the connection closes. Nothing else was installed.
Add the operator to one test installation.
Pick one read-only operation, add the container to your chart or task, and watch the installation appear. Then enable it for the customer who asked.