# Introducing Islo BYOC for enterprise teams > Source: > Published: 2026-07-30 00:00:00+00:00 Today, we’re introducing **Islo BYOC**: Islo running on infrastructure you own - your AWS account, or your own on-prem Linux machines, with Google Cloud and Azure coming soon. Islo runs coding agents on real computers. Each one is set up the way a developer’s machine is: your repository checked out, your dependencies installed, your services running. An agent working that way needs two things from you. It needs your source code, and it needs to reach the internal systems your engineers use. In a large company, both are difficult to hand to software running in someone else’s cloud. Source code is one of the most sensitive assets the company has, and internal systems are usually not reachable from the public internet at all. BYOC removes that problem by putting the computers inside your own environment, while Islo keeps operating the product for you. We built BYOC in partnership with [Alien](https://www.alien.dev/), which lets us deploy and operate Islo inside your infrastructure without turning Islo into a self-hosted product your team has to maintain. ## A complete computer for every agent Each computer is a complete virtual machine with its own Linux kernel, not a container and not a stripped-down microVM built for short function-style workloads. That is what lets a computer run the same software your developers run locally, without changes. Inside one computer you can run Postgres, Redis, ClickHouse, your API, a real browser, Docker, and your own build tooling, the same way you would on a developer machine. These are not small function runners. Our own end-to-end verification computer has 8 vCPUs, 16 GB of memory, and about 50 GB of pre-warmed disk. A fresh computer on our current cloud setup boots in about 380 milliseconds. BYOC startup time varies with the host, but it uses the same warm pools and copy-on-write disk caches. Each run is isolated at the hardware boundary rather than by a shared kernel, so untrusted code and untrusted model output stay contained. State survives the session. You can snapshot a computer, resume it, and reconnect later with its services still running. On BYOC this runs on virtualization-capable cloud instances or on your own bare metal, which is frequently where the best price-performance for this workload is. ## What teams run on BYOC **Autonomous coding agents.** An agent can pick up a ticket, change code, start the full application, run tests, and open a pull request without sending the repository or build artifacts outside your network. Long-running computers preserve the branch, services, caches, and agent history while review comments and CI failures arrive. **RL and agent evaluations.** Run hundreds of isolated trials against real task environments instead of reduced test harnesses. A task can start Docker, ClickHouse, Postgres, browsers, or any other service the benchmark requires. Gateway policies control which hosts and paths each trial can reach, and every request has an audit trail. That matters when a reward-hacking agent can turn unrestricted internet access into a passing score. **End-to-end verification and CI.** Give every run the same environment developers use, including private packages and internal services. Our own verifier uses an 8 vCPU, 16 GB computer with roughly 50 GB of tools, repositories, and services ready on disk. It boots the complete Islo platform and checks changes through the browser and API rather than stopping at unit tests. ## Why run Islo in your own infrastructure **Keep code and data in your environment.** Agents work directly on your repositories, dependencies, and data that often resembles production. With BYOC, all of it stays on machines in your account. Your existing IAM, audit logging, retention, monitoring, and regional requirements still apply. For many organizations this is a contractual or regulatory condition rather than a preference. **Reach private systems directly.** Useful agent work depends on internal systems such as GitHub Enterprise, self-hosted GitLab, artifact registries, package mirrors, private databases, internal APIs, license servers, and staging environments. Inside your VPC or on-prem network, that access is normal network configuration. From outside, each system needs an exception that someone has to approve and maintain. **Control capacity and cost.** Agent work is compute-heavy, and demand grows as teams automate more engineering work. In your own account, you can use reserved capacity, committed-spend discounts, and hardware you already operate, including bare metal. ## What runs where **In your infrastructure:** the agent computers and everything they use. Repositories, working state, running services, environment variables, snapshots, and the artifacts a run produces all stay in your account. Egress policy is enforced in your network, so credentials injected by Gateway never pass through Islo’s infrastructure.**In Islo Cloud:** the product itself. Your team keeps the dashboard, users and policies, integrations, and the managed release lifecycle it already uses. You own the infrastructure and the data while Islo operates the product. ## Managed, not self-hosted BYOC is Bring Your Own Cloud without traditional self-hosting. An administrator selects a region in the Islo dashboard and launches a CloudFormation stack. For on-prem machines, the equivalent is a one-line installer and a single deploy command on each Linux host. Either path creates only the dedicated resources and least-privilege roles Islo requires, scoped to Islo rather than to unrelated infrastructure in your account. From then on, Islo maintains the software: **Versions are rolled out for you.** New releases, security fixes, and product improvements are built, tested, and rolled out across every BYOC deployment. There is no fork to maintain and no upgrade window to schedule.**Upgrades do not disturb running work.** Agent computers are long-lived, so a rollout replaces the software underneath them without stopping the computers agents are working in.**Health and capacity are visible centrally.** Machine health, capacity, and operational logs are available in one place, to your team and to ours.**No inbound access is required.** Islo connects outbound only, so nothing needs to reach into your network, and your endpoints can stay restricted to your VPN. Because the deployment is yours, it also does not depend on constant connectivity to us: if the connection to Islo Cloud is interrupted, the computers in your environment keep running. ## Availability Islo BYOC is available to Enterprise customers on AWS and on self-managed Linux machines, with Google Cloud and Azure coming soon. [Contact us](mailto:support@islo.dev) to set up your first deployment.