Self-Hosted Orbs

Some companies need more control over where their code runs. Self-hosted orbs allows Amp to spawn orbs in their own cloud on AWS, Google Cloud, or Azure. Amp creates and stops these temporary development environments as work starts and ends.

Choose Where Orbs Run

Amp can host your orbs, or your company can run them in its own cloud.

Amp-hosted orbs fit most teams. Amp creates and maintains the machines, so you can start work without running a cluster.

Self-hosted orbs fit companies that need the development environment in their own cloud account, region, or network. Your team maintains the cluster.

Who Should Self-Host

Amp-hosted orbs fit most teams. Self-host when Amp-hosted orbs cannot meet one of these needs:

• Your source code or build output must stay in your cloud account.
• Your builds need private services that are reachable only from your network.
• Your rules require compute in a specific cloud, region, or account.

Understand What Stays in Your Network

With self-hosted orbs, your repository checkout, build output, and paused orb files stay in your cloud account. The orb can reach private services in your network.

The Amp service still runs the conversation and sends work to the orb. File contents that Amp reads, command output, and code changes travel through ampcode.com and may be sent to the model provider. Amp does not receive access to your Kubernetes API or storage account.

What You Need

You need an Amp Enterprise workspace and a Kubernetes cluster on Google Kubernetes Engine, Amazon EKS, or Azure AKS.

The Self-Hosted Orbs guide covers the network rules, installation, connection, testing, and day-to-day operation.