Remote debugging

When your software runs in a customer's cloud, debugging usually means screenshots, copy-pasted logs, and Zoom calls. alien debug replaces that. It opens a secure channel into a customer's deployment and runs a local command — or an interactive shell — against it, using credentials the manager hands out just for that session.

Nothing about the customer's network changes: there are no inbound ports, no VPN, and no shared cloud access. The deployment behaves like another region in your own cloud.

# Run a cloud CLI against the customer's environment
alien debug acme/prod -- aws sts get-caller-identity
alien debug acme/prod -- gcloud projects list
alien debug acme/prod -- kubectl get pods

# No command drops you into a shell with the env already set
alien debug acme/prod

A deployment can be referenced by ID (dep_...), by name, or as <group>/<name>.

How it works

alien debug asks the manager for a short-lived debug session, then runs your command with the environment that session returns. Two things make it safe:

• Least-privilege identity. The session acts as the deployment's own scoped identity — the same one Alien uses to manage that environment (see Impersonation). It can touch the deployment's isolated area and nothing else. The customer controls what that identity is allowed to do, and access can require approval.
• Ephemeral credentials. Any credential files (like a kubeconfig) are written to a per-session temp directory with 0600 permissions and deleted when the command exits. Nothing is left on disk.

Under the hood the channel uses whichever deployment model the customer is on:

• Push. The CLI runs a loopback proxy on 127.0.0.1 and points the cloud CLI at it (AWS_ENDPOINT_URL and the GCP/Azure equivalents). Requests tunnel to the manager over an authenticated WebSocket, where they're re-signed with the impersonated identity and forwarded to the cloud. Your aws command thinks it's talking to AWS; it's really talking through Alien.
• Pull. A lightweight agent inside the environment calls out over HTTPS. Same result, no inbound connection.

Scope and auditing

Debug sessions are scoped to operating the deployment, not reading customer data. They run as the management identity, are bounded by the permissions the customer granted, and leave an audit trail. When you need to inspect data on demand instead, reach for a remote command, which runs inside the environment and returns only what you ask for.

What's next