Gitpod moved from a managed, multi-tenant Kubernetes service to a customer-owned cloud model because regulated companies needed their source code and workloads to stay inside their own infrastructure.
2
A single ECS task runner launches development environments on the customer's cloud infrastructure, using native services such as EC2 and EBS instead of managing Kubernetes clusters.
3
Gitpod can run autonomous agents in the same development environments as humans, with the same source-code and internal-system access, plus API-level audit logs for agent tasks.
Summary
Lou Bichard describes Gitpod's six-year move toward an architecture that regulated customers can operate without taking on a large infrastructure team. The original managed SaaS model was easy to adopt but suffered from abuse and did not fit enterprise security needs. A self-hosted Kubernetes version gave customers more control, but created heavy setup and day-two work. Gitpod then narrowed its platform support and managed more of the service, while keeping source code and workloads in the customer's cloud account. The current design replaces Kubernetes with a small runner, implemented as a single ECS task, that starts development environments on native cloud infrastructure. Bichard argues that this model also fits autonomous agents because agents need the same code, data connections, and development tools as human developers. An API-first design records platform actions, including agent work, in audit logs. The talk is a practical account of how deployment architecture affects security, cost, adoption, and vendor-customer relationships.
A managed SaaS product was easy to start but did not fit regulated companies
Gitpod began in 2019 as a managed, multi-tenant SaaS product hosted on GCP Kubernetes. Users could click a link and enter a development environment quickly. The model also exposed Gitpod to crypto mining and other abuse because it offered shared compute on the internet. Bichard says Kubernetes was not designed for this workload, and the model was insufficient for enterprise customers that needed tighter control over where their code and environments ran.
Self-hosting shifted the operational burden to customers
Gitpod packaged its existing architecture for customers to install themselves, including support for different cloud providers and Kubernetes configurations. That approach gave customers control, but it produced substantial day-two work. Customers had to set up and operate the platform, sometimes allocating two or three people or an entire team to it. Bichard says that overhead reduced the product's return on investment and made adoption harder, especially when the people installing the product were not closely supported by Gitpod.
A managed substrate reduced variance while keeping workloads in the customer's cloud
Gitpod next built what Bichard calls a substrate. Customers still hosted the workload, source code, and data integrations in their own infrastructure, while Gitpod managed more of the service. The company focused on AWS to reduce variation between deployments and retained limited telemetry and operational data on its side. This improved operations, but the underlying Kubernetes design still required multiple clusters, carried a high fixed cost, and remained difficult to install.
The current design uses a small runner and native cloud services
Gitpod moved away from Kubernetes and designed the architecture from first principles. A runner takes the secure parts, such as source code and data access, and runs them on the customer's infrastructure. The runner is a single ECS task, while development environments run on EC2 and use EBS backups. Bichard's argument is that native cloud services remove the complexity that comes with making a workload portable across providers. The runner itself costs only single-figure dollars per month in the example he gives.
Gitpod keeps low-sensitivity metadata while customers retain their intellectual property
The architecture separates information that Gitpod can operate from information customers need to keep private. Gitpod can retain metadata such as user IDs and other account information that is not personally identifying. Customers keep the source code, intellectual property, and running workloads inside their own infrastructure. This division lets Gitpod manage parts of the service without requiring regulated customers to hand over the assets they care most about protecting.
The deployment flow is simple, but network ownership remains the hard part
Customers choose a workload and provide their own network details, including VPC information and subnets. The deployment process can take as little as three minutes once those details are available. Bichard says the main difficulty is organizational rather than technical: finding who owns the network configuration and who can allocate the required resources. The runner interface keeps the deployment steps small while leaving the network decisions with the customer's organization.
Agents can use the same development environments as human developers
Gitpod's agent offering uses the infrastructure already built for customer development environments. Bichard says an autonomous agent needs the same basic capabilities as a developer: source-code access, internal databases, clusters, and other internal systems. The agent can therefore work inside the same type of environment and receive the same access and privileges as an individual human. Because the environment runs in the customer's infrastructure, Gitpod describes the agent offering as privacy first.
API-first actions create an audit history for agent work
After rearchitecting the platform, Gitpod made every action and interaction available through an API. Spinning up a development environment and other platform activity are audit logged. The same audit history applies when agents run tasks, giving customers a record of what happened on the platform. Bichard presents this as one of the additional benefits of running agents on the existing customer-owned environment rather than treating agent execution as a separate system.
"If you need to allocate two, three, maybe even a whole team to actually set up and run this infrastructure, then the benefit that you're getting from that product is also being eroded."06:00
Who should watch
You are evaluating SWE agents for a bank, pharmaceutical company, healthcare provider, or another organization that keeps code and internal systems inside its own cloud.
Your team is building a self-hosted or customer-managed AI product and needs to understand how setup costs and day-two operations affect adoption.
You are designing agent execution environments and need audit logs, customer-controlled network placement, and a clear split between vendor metadata and customer data.
