Introducing Tensorlake BYOC: Serverless Sandboxes in Your Private Cloud

Serverless developer platforms have mostly lived outside the private networks where companies run their infrastructure.

Teams that need to run workloads inside a VPC generally have two options today: build a platform on Kubernetes or adopt a cloud-specific service such as AWS Lambda or Google Cloud Run.

As sandboxes become critical infrastructure for coding agents, reinforcement learning, and large-scale CI, teams want another option. They want the developer experience of a serverless platform while keeping compute, storage, and workload traffic inside their private networks.

Today, we are announcing Tensorlake BYOC. You can now run Tensorlake Sandboxes on infrastructure you own across AWS, GCP, Azure, CoreWeave, Nebius, and bare metal environments.

Why Sandboxes Need to Run Inside Private Networks

There are two main reasons teams want sandbox infrastructure in their own networks:

1. Security: Running sandboxes inside a private network makes it easier to comply with policies that prohibit confidential code, data, or models from leaving the organization's infrastructure.

2. Connectivity to internal systems: Coding agents need access to databases, codebases, package registries, staging environments, and observability tools. Running sandboxes in the same network provides this access without complicated networking or security exceptions.

Kubernetes Was Not Built for Sandbox Workloads

Kubernetes works well for long-running services, but sandboxes are short-lived, high-volume, and frequently suspended or resumed.

Supporting this pattern usually requires warm pools, custom schedulers, sandbox claiming systems, and snapshot management. Tensorlake provides these capabilities as a managed platform.

Scale Up to 5 Million Concurrent Sandboxes

We built a cluster scheduler specifically for high-throughput sandbox workloads.

Tensorlake can schedule more than 24,000 sandboxes per second and support up to 5 million concurrent sandboxes in a single project.

Kubernetes documents a limit of 150,000 pods per cluster. Tensorlake supports over 33 times that capacity in a single project. This makes it possible to run large reinforcement learning rollouts while providing enough headroom for future agentic applications deployed across your infrastructure.

What Tensorlake Enables You to Build

Tensorlake starts new sandboxes in under 500 milliseconds and suspends or resumes them in less than two seconds.

This enables teams to build:

1. Background agents: Start an isolated environment when a pull request, email, support ticket, or production alert arrives.

2. Reinforcement learning infrastructure: Run agentic evaluations across tens of thousands or millions of sandboxes without infrastructure becoming the bottleneck.

3. Elastic CI infrastructure: Scale workers with the volume of code produced by developers and coding agents without maintaining large idle worker pools.

A Serverless Experience on Your Infrastructure

Tensorlake BYOC feels like a serverless product to the developers building on it.

Developers use the same Tensorlake APIs, SDKs, images, and public documentation. Code written for Tensorlake Cloud continues to work when compute moves into a private network.

Infrastructure teams retain control over the instances, storage, networking, and access to internal systems. Developers request a sandbox, and Tensorlake schedules it onto available compute in the project.

An Architecture Built for Public Cloud and Self-Hosted Compute

Tensorlake was designed from the beginning to run sandboxes both in our public cloud and on customer-owned compute.

The platform splits cleanly into a control plane and data planes. The control plane runs on Tensorlake's infrastructure and manages sandbox scheduling, API keys, authentication, authorization, and user and service metadata.

Data planes, including compute and storage, run either in Tensorlake Cloud or inside the customer's infrastructure. The control plane schedules sandboxes onto these data planes without changing the APIs developers use.

This architecture allows the same Tensorlake APIs, SDKs, and images to work across our public cloud and self-hosted compute. Customers can start on Tensorlake Cloud and move workloads into their private networks without changing application code.

Sandboxes run in Firecracker microVMs wherever KVM is available and in gVisor containers where it is not. The same images work across both runtimes.

Images and sandbox snapshots are stored in object storage inside the customer's network.

Ingress can be managed by Tensorlake from a private VPC peered with the customer's network. It can also run entirely inside the customer's network so sandbox workload traffic never leaves it.

Multi-Cloud From the Beginning

Tensorlake BYOC is available across AWS, GCP, Azure, CoreWeave, Nebius, and supported bare metal environments such as Latitude.

A single Tensorlake project can include compute from multiple providers. Teams can place sandboxes close to their data, use capacity where it is available, and expand across clouds without changing application code.

Higher Utilization Through Oversubscription

Serverless platforms oversubscribe compute to pack workloads more densely and reduce costs. Most sandboxes do not use all their allocated CPUs at the same time, so oversubscription improves resource utilization.

Tensorlake gives operators control over how much each machine is oversubscribed. For example, an AWS i7i.metal-24xl with 96 vCPUs and 768 GiB of memory can run up to 1,000 sandboxes, depending on the resource requirements of the workloads.

Simple Onboarding

An administrator downloads a data plane binary and certificate from the Tensorlake dashboard. The certificate authenticates the compute node with Tensorlake.

The binary bootstraps the services required to run sandboxes. Additional nodes can be added as more capacity is needed, and the data plane automatically receives new releases.

Customers provide the compute, storage, and network. Tensorlake operates the sandbox platform.

Pricing

Pricing for Tensorlake Self-Hosted Compute goes down as you scale, with steep discounts for customers running large reinforcement learning workloads.

GPU pricing is lower because the cost of an accelerator is significantly higher, while the work required to schedule and manage its sandboxes does not increase proportionally.

The comparison below uses a 20 percent Tensorlake rate for CPU sandboxes, which is available at scale.

An AWS i7i.metal-24xl currently costs $9.06 per hour in US East. At the 20 percent Tensorlake rate, the total cost of the compute and sandbox platform is $10.87 per hour.

When a workload supports packing 1,000 sandboxes onto this machine, the Tensorlake and compute cost can be as low as 1.1 cents per running sandbox-hour.

If you are building coding agents, reinforcement learning infrastructure, or large-scale CI and need sandbox infrastructure inside your private network, contact us to get started.