Remote bindings

Your backend can read and write one resource in the customer's account directly: write a KV record, read an object, send a queue message. A remote binding is the client for it, with short-lived credentials scoped to that one resource.

import { Bindings } from "@alienplatform/bindings"

const bindings = await Bindings.forRemoteCustomer({
  project: "acme-docs",
  externalId: customer.id,
  token: process.env.ALIEN_REMOTE_BINDINGS_KEY!,
})

const policy = { maxBytes: 50_000_000 }
await bindings.kv("policies").setJson("ingest", policy)

The write goes from your backend to the cloud provider's API. Nothing connects into the customer's network, and no handler runs in the deployment.

Publish the resourceCopy Anchor Link

Mark the resource with remoteAccess: true. Only resources you mark are reachable; the rest of the stack is not.

const policies = new alien.Kv("policies").build()

export default new alien.Stack("acme-docs")
  .add(policies, "frozen", { remoteAccess: true })
  // .add(...) the other resources
  .build()

At initial setup, the one-time step the customer's admin runs, the admin creates a dedicated identity that can access only the published resources. The setup template shows exactly which resources and actions it covers.

Use it from your backendCopy Anchor Link

Create a project API key for remote bindings and store it on your server:

alien api-keys create --for remote-bindings

The secret is printed once. Keys are listed under Settings → API Keys in the dashboard.

Then address the customer by their external ID and use the binding, as in the snippet at the top of this page. The external ID is your own stable identifier for that customer, set with alien onboard --external-id. It defaults to a URL-safe form of the customer name.

╔═ Alien ═╗                    ╔═ Your backend ═╗                ╔═ Cloud API ════════╗
║         ║                    ║                ║                ║                    ║
║         ║                    ║   your cloud   ║                ║  customer account  ║
║         ║                    ║                ║                ║                    ║
║         ║   request access   ║                ║                ║                    ║
║         ◀────────────────────╬                ║                ║                    ║
║         ║                    ║                ║                ║                    ║
║         ║ scoped credentials ║                ║                ║                    ║
║         ╬────────────────────▶                ║                ║                    ║
║         ║                    ║                ║                ║                    ║
║         ║                    ║                ║ write policies ║                    ║
║         ║                    ║                ╬────────────────▶                    ║
║         ║                    ║                ║                ║                    ║
╚═════════╝                    ╚════════════════╝                ╚════════════════════╝

Alien resolves the customer's deployment and issues short-lived cloud credentials for that one resource. The write then goes straight from your backend to DynamoDB, Firestore, or Table Storage in the customer's account.

If you already know the deployment, use Bindings.forRemoteDeployment({ deploymentId, token }). In Python it's Bindings.for_remote_deployment(deployment_id=..., token=...), and in Rust RemoteBindings::for_deployment(deployment_id, token, None).

In the deployment, the Worker reads the record with the ordinary binding:

const entry = await kv("policies").getJson<{ maxBytes: number }>("ingest")
const maxBytes = entry?.value.maxBytes ?? DEFAULT_MAX_BYTES

getJson returns the entry, or null if the key doesn't exist yet. The value is in entry.value. Python and Rust return the raw bytes in entry.value, so decode the JSON yourself.

When to use itCopy Anchor Link

Use a remote binding when your backend owns data that the deployment reads locally. In the running example:

1. Customers edit ingest policies in your hosted UI.
2. Your backend writes each policy into the policies KV table in the customer's account.
3. The processor Worker reads it next to the documents, with no call back to your cloud.

This is a local read model: a copy of data your backend owns, kept next to the code that reads it. The same pattern fits entitlements, feature flags, routing tables, or a cache. The deployment keeps working if your backend is unreachable.

Send a command instead when you need to run code in the deployment, or when the answer must be computed next to the data. To hand the deployment work without waiting for a result, send to a remote Queue; see Queued jobs.

What you can callCopy Anchor Link

In Python, remote bindings cover kv and queue. In Rust, alien_bindings::RemoteBindings (feature platform-sdk) covers every resource above.

Remote bindings use a cloud identity, so they work on AWS, Google Cloud, and Azure deployments. The SDK reference lists every method; the Sandbox restrictions are on its resource page.

What to keep in mindCopy Anchor Link

• Data you read crosses into your cloud. Read only what your backend needs, and prefer a command that returns a summary when the raw data is sensitive.
• Name records so you can rebuild them. If a customer's table is lost, your backend should be able to write it again.
• The customer can revoke access at any time by removing the identity created at initial setup.

NextCopy Anchor Link

• Commands: call a handler in the deployment and get its result instead
• Backend connections: every way your backend and a deployment talk, compared
• Networking and endpoints