{"slug": "running-self-hosted-ai-agents", "title": "Running Self-Hosted AI Agents", "summary": "Oxide published guidance for running self-hosted AI agents on its Oxide Cloud Computer by provisioning a virtual machine for the agent's orchestrator, which then creates ephemeral virtual machines for each agent session, rather than using containers. The company argues virtual machines offer stronger isolation than containers — a separate guest kernel versus a shared host kernel — at the cost of seconds-long startup versus milliseconds, GB-scale images versus MB-scale, and VMs that keep running after the main process exits. Oxide illustrates the workflow with Claude Code self-hosted environments and Amp self-hosted orbs, noting that AI agents need CPUs because the harness runs as a CPU process that executes tool calls requested by GPU-based inference.", "body_md": "# Running Self-Hosted AI Agents\n\nCustomers are increasingly asking us the following question:\n\nHow do I run AI agents on Oxide?\n\nThe initial answer is simple. You run AI agents the same way you run other workloads on Oxide—in virtual machines. Customers already run long-lived services in virtual machines, so running AI agents feels familiar.\n\nHowever, AI agents aren’t exactly long-lived services—they fall somewhere\nbetween that and ephemeral CI/CD jobs, depending on how they are used. Run a\nlong-lived agent that provisions sub-agents and it looks like the former. Run an\nagent to complete a bounded task using `/goal` and it looks like the latter.\n\nRegardless of your use case, the workflow looks like this:\n\n1. Provision a virtual machine.\n2. Run the AI agent in the virtual machine.\n3. Clean up the virtual machine.\n\nWith that context, the more accurate answer is to run the AI agent’s orchestrator as a virtual machine, configured to create ephemeral virtual machines for each AI agent session. I’ll show how this works on our Oxide Cloud Computer using both Claude Code self-hosted environments and Amp self-hosted orbs.\n\n## [AI agents need CPUs](#_ai_agents_need_cpus)\n\nBefore describing how to run AI agents on an Oxide Cloud Computer, it’s important to understand why AI agents need CPUs in the first place.\n\nAI agents are just systems that perform inference and execute tool calls in a loop. Put another way, AI becomes \"agentic\" when GPU-based inference needs CPU-based tool execution.\n\nThe AI agent harness (e.g., Claude Code, Codex, Amp) is responsible for running this loop. The harness runs as a process on a CPU, communicating with an LLM over the network. When the LLM requests a tool call, the harness executes it on the CPU it’s running on and sends the result back to the LLM.\n\nWithout a CPU, you can’t run the harness or execute tool calls.\n\n## [Virtual machines, not containers](#_virtual_machines_not_containers)\n\nAI agents need strong isolation for both security and performance. You don’t want an AI agent to delete important data or duel with other AI agents and disrupt their execution.\n\nVirtual machines provide stronger isolation than containers, making them well-suited for AI agents. This isolation comes at a cost, summarized by this table:\n\n|  | Virtual Machines | Containers | \n|---|---|---|\n| Startup time | Seconds | Milliseconds | \n| Main process exits | VM keeps running | Container stops | \n| Size | Larger (GBs) | Smaller (MBs) | \n| Isolation | Separate guest kernel | Shared host kernel | \n\nUsing virtual machines instead of containers for workload orchestration raises the following questions:\n\n1. How do I provision the virtual machine running the AI agent process?\n2. How do I clean up the virtual machine when the AI agent process finishes?\n\nThese questions are surprisingly difficult to work through, especially\nwhen documentation leaves out the details. Look at this quote from the\n[Claude Code\nself-hosted environments documentation](https://code.claude.com/docs/en/self-hosted-environments-deploy).\n\nEphemeral, per-session containers: run each runner process in a fresh container\nor VM that’s destroyed when the process exits\n\nNot only does this push readers towards containers, and possibly worse isolation as a result, but it also has a tone of \"just do the right thing\" without telling readers how to do it. Excuse me, Claude, did you just tell me to go eff myself?\n\nNeedless to say, when our customers ask how to run AI agents on Oxide, they also ask how to do it specifically with virtual machines, not containers.\n\n## [AI agents on Oxide](#_ai_agents_on_oxide)\n\nLet’s see how to run AI agents on our Oxide Cloud\nComputer using virtual machines, specifically using\n[Claude\nCode self-hosted environments](https://code.claude.com/docs/en/self-hosted-environments-quickstart) and\n[Amp self-hosted orbs](https://ampcode.com/docs/orbs/self-hosted). These were\nchosen due to their popularity in the industry and to showcase how different AI\nagents use certain Oxide features.\n\n### [Claude Code self-hosted environments](#_claude_code_self_hosted_environments)\n\n[Claude\nCode self-hosted environments](https://code.claude.com/docs/en/self-hosted-environments-quickstart) run Claude Code sessions on infrastructure you\ncontrol, in this case the Oxide Cloud Computer. The orchestrator dynamically\nprovisions ephemeral Oxide virtual machines to run Claude Code and deletes them\nwhen finished.\n\nHere’s the architecture:\n\nThe orchestrator virtual machine is the central component. It’s a long-running virtual machine responsible for addressing the complexity mentioned in the previous section. Recall these questions:\n\n1. How do I provision the virtual machine running the AI agent process?\n2. How do I clean up the virtual machine when the AI agent process finishes?\n\nFor provisioning, the orchestrator virtual machine runs a `claude` command\nyou’ve likely never used:\n\n```\nclaude self-hosted-runner orchestrator \\  --environment-secret-file /etc/claude-self-hosted/environment-secret \\  --hooks-dir /etc/claude-self-hosted/hooks \\  --hook-concurrency 1 \\  --hook-timeout 60 \\  --expected-spawn-seconds 300\n```\n\nThis command authenticates to the self-hosted environment using the\n`--environment-secret-file` option and waits for work orders, which are requests\nto create an ephemeral runner for a user’s Claude Code session. When there are\nno work orders, the number of ephemeral runners scales down to zero.\n\nThe `--hooks-dir` option is, to borrow an LLM-ism, \"load-bearing.\" It points to\na directory containing hooks the orchestrator will call when work orders come\nin. The only hook available is `spawn-runner`, which, when called, must create\nthe ephemeral virtual machine running the AI agent process. The AI agent process\nis another `claude` command you’ve likely never used:\n\n```\nclaude self-hosted-runner \\  --capacity 1 \\  --base-dir /var/lib/claude-self-hosted \\  --use-anthropic-git-proxy \\  --configure-git\n```\n\nThe `--capacity 1` option ensures the process only runs a single\nClaude Code session to support our ephemeral architecture, while the\n`--use-anthropic-git-proxy` and `--configure-git` options ensure that your\nconnected Git repositories can be safely cloned within the virtual machine.\n\nTo make cleanup easier, the ephemeral virtual machine is configured to power\noff once the AI agent process has finished. There are a few ways to do this, but\na popular way is to create a systemd service that runs at startup. The service\nthen runs the AI agent process and runs `poweroff` after it exits.\n\nA stopped virtual machine is the signal used for cleanup. Unfortunately, the\norchestrator does not have a `cleanup-runner` hook, so the burden of cleanup is\non us. I chose to run a separate `reaper` process that periodically polls the\nOxide API for stopped virtual machines matching the desired name prefix. When\nit finds a matching virtual machine, it deletes it and its boot disk, freeing up\nresources for more Claude Code sessions.\n\nIf everything is wired up correctly, you’ll be able to select your self-hosted\nenvironment when you create a Claude Code session on [https://claude.ai](https://claude.ai). You\ncould also run `claude` with the `--environment` option, though you’ll need\nto ask your Claude administrator for the self-hosted environment ID to pass as\nits argument.\n\nIf you want to try this yourself, I’ve put together a showcase describing\nhow to use Claude Code self-hosted environments with Oxide. Find the code at\n[oxidecomputer/showcase](https://github.com/oxidecomputer/showcase).\n\n### [Amp self-hosted orbs](#_amp_self_hosted_orbs)\n\n[Amp self-hosted orbs](https://ampcode.com/docs/orbs/self-hosted) run Amp\nthreads on infrastructure you control, in this case the Oxide Cloud Computer.\nThe provider dynamically provisions ephemeral Oxide virtual machines to run Amp\norbs and deletes them when finished.\n\nHere’s the architecture:\n\nThe Amp orb provider runs an `amp` command that authenticates to Amp and waits\nfor requests to spawn, pause, and delete Amp orbs:\n\n```\nAMP_ORB_PROVIDER_TOKEN='aop_live...' amp orb provider dispatch.sh\n```\n\nThe `dispatch.sh` script can contain any logic you wish, as long as it adheres\nto the [dispatch\ncontract](https://ampcode.com/docs/orbs/self-hosted#dispatch-contract) defined by Amp, which is really just responding to the `ORB_OPERATION`\nvalues `spawn`, `pause`, and `delete`. Here’s a pseudocode version of the\ndispatch script I used:\n\n```\nremove_instance() {  oxide instance stop   --project \"$PROJECT\" --instance \"$orb_name\"  oxide instance delete --project \"$PROJECT\" --instance \"$orb_name\"}case \"$ORB_OPERATION\" inspawn)  remove_instance  if oxide disk view --project \"$PROJECT\" --disk \"$orb_name\"; then    boot_disk=$(attach_disk \"$orb_name\")    # resume from orb's disk  else    boot_disk=$(new_disk \"$orb_name\" \"$ORB_IMAGE\")    # new orb from the image  fi  # User data starts `amp orb bootstrap` as `user` with this spawn's ORB_TOKEN.  oxide instance create --project \"$PROJECT\" \\    --json-body <(instance_body \"$boot_disk\" \"$ORB_TOKEN\")  ;;pause)  remove_instance    # the disk is kept  ;;delete)  remove_instance  oxide disk delete --project \"$PROJECT\" --disk \"$orb_name\"  ;;esac\n```\n\nAmp’s `pause` and `delete` operations free us from relying on a stopped virtual\nmachine as the signal for cleanup. Instead, we can delete the instance but\nkeep its boot disk for `pause` and delete the instance and its boot disk for\n`delete`. This significantly simplifies the overall architecture and deployment\ncompared to Claude Code self-hosted environments.\n\nIf everything is wired up correctly, you’ll be able to select your self-hosted\norb provider when you create an Amp thread on [https://ampcode.com](https://ampcode.com). You could\nalso run `amp` with the `--orb-provider` option, using the provider name as\nthe argument.\n\nIf you want to try this yourself, I’ve put together a showcase\ndescribing how to use Amp self-hosted orbs with Oxide. Find the code at\n[oxidecomputer/showcase](https://github.com/oxidecomputer/showcase).\n\n## [Tomorrow’s AI agents](#_tomorrows_ai_agents)\n\nOur Oxide Cloud Computer has the right primitives for today’s AI agents—virtual machines with strong isolation, disks with solid performance, control over VPC networking, and an elastic API to dynamically provision everything. Even so, we’re looking ahead to meet the needs of tomorrow’s AI agents.\n\nConversations with current and prospective customers about AI agents have centered around the following themes:\n\n- Security\n- Scale\n- Cold-start latency\n- Cleanup\n\nSecurity is where most conversations start, especially as the number of\nreported CVEs increases across the industry. We’ve already discussed the\nstrong isolation provided by virtual machines, but our security story\ndoesn’t stop there. Our Oxide Cloud Computer has silos for tenancy and\nresource quota enforcement, projects for network isolation, and VPC firewall\nrules to block undesirable network traffic. Additionally, our removal of\nthe BIOS, along with the virtual machine attestation work discussed in\n[RFD 605](https://rfd.shared.oxide.computer/rfd/0605), provides a secure\nfoundation for AI agent workloads.\n\nIf you run many AI agents, you may be wondering about scale. You can create as many virtual machines as you can fit on your Oxide Cloud Computer, but we’re working on multi-rack capabilities to expand a silo’s capacity beyond a single rack. Once released, this will simplify the management of AI agents across multiple racks.\n\nOur API makes virtual machine provisioning trivial from an operational standpoint, but it can take tens of seconds or even minutes after an API request before a virtual machine is scheduled, booted, and running a workload. This affects users in the form of cold-start latency, which a warm pool can help mitigate, but not entirely eliminate. We accepted the latency in this blog post, but our goal is to reduce it as much as possible.\n\nCleaning up virtual machines is also trivial using the Oxide API, but, depending\non the AI agent, there isn’t always a simple way to know when the workload\nhas finished. In this blog post, we handled this by treating a stopped virtual\nmachine as the signal that the workload has finished. This required us to wrap\nour AI agent process in a systemd service that runs `poweroff` after the AI\nagent process exits, along with a `reaper` process to poll the Oxide API for\nvirtual machines to clean up. Not the best user experience, especially if the AI\nagent architecture doesn’t provide a `delete` operation, but we’re exploring how\nto make this experience behave like a container that exits when the main process\nis finished.\n\nI’ve made it this far without talking about microVMs, but the microVM primitive is exactly what some infrastructure providers are using to improve the user experience of running AI agents without sacrificing the strong isolation they’ve come to rely on from virtual machines.\n\nThe definition of microVMs can vary across the industry, but discussing them in the context of AI agents has led to internal conversations about what a microVM primitive could look like for Oxide. Our hypervisor team even spiked on work to see how quickly we could launch a virtual machine and have it running its workload. Turns out we’re not far off from popular microVM implementations!\n\nWe don’t have anything set in stone, but the conversations about microVMs are proving to be fruitful and are being validated by customer requests. We’re well-positioned to release a better primitive for running AI agent workloads with a focus on security, scalability, cold-start latency, and cleanup, taking inspiration from microVMs.\n\nIf you’re interested in running AI agents on Oxide, we’d love to hear from\nyou! [Contact us](https://oxide.computer/contact), tell us about your use case, and stay tuned for\nwhat’s next.\n\n## [See it in action](#_see_it_in_action)\n\nTo see self-hosted AI agents in action, watch the video below, in which I run Claude Code and Amp AI agents on Oxide.", "url": "https://wpnews.pro/news/running-self-hosted-ai-agents", "canonical_source": "https://oxide.computer/blog/self-hosted-ai-agents", "published_at": "2026-10-29 14:00:00+00:00", "updated_at": "2026-10-29 14:21:43.226534+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools"], "entities": ["Oxide", "Oxide Cloud Computer", "Claude Code", "Amp", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/running-self-hosted-ai-agents", "markdown": "https://wpnews.pro/news/running-self-hosted-ai-agents.md", "text": "https://wpnews.pro/news/running-self-hosted-ai-agents.txt", "jsonld": "https://wpnews.pro/news/running-self-hosted-ai-agents.jsonld"}}