How Lovable Manages 30,000 Sandboxes: Inside Their Custom Scheduler and Traffic Migration Strategy

Published on ClawList.io | Category: DevOps | Reading time: ~6 min

---

If you've ever wondered what it takes to power a large-scale AI coding platform in real time, Lovable's infrastructure is a masterclass worth studying. A recent tweet from the Lovable team (surfaced by @dotey) quietly dropped some impressive technical details about how they manage their sandbox environment at scale. Three data points stood out — and each one deserves a deep dive.

Let's unpack what's happening under the hood.

---

The Scale: 30,000 Live Sandboxes at Any Given Moment

Lovable currently maintains approximately 30,000 active sandboxes simultaneously. For context, a sandbox in this context refers to an isolated virtual execution environment — a lightweight container or VM slice that safely runs user code without letting it interfere with the host system or other users' workloads.

To appreciate the complexity here, consider what that number actually means operationally:

• Each sandbox must be provisioned, monitored, and eventually torn down
• Resource allocation (CPU, memory, network, storage) has to be managed dynamically across thousands of concurrent instances
• Security isolation must be enforced at every layer — no sandbox should be able to "escape" and affect another
• State management — whether sessions are stateless or stateful — adds another dimension of complexity

At 30,000 concurrent environments, you're operating at a scale that rivals mid-sized cloud providers. Most teams at this scale would lean entirely on off-the-shelf orchestration tools like Kubernetes, AWS ECS, or Google Cloud Run. Lovable apparently decided that wasn't enough — and built something custom.

What This Looks Like in Practice

Imagine a typical developer using Lovable to generate and iterate on a React app. The moment they start a session, a sandbox spins up — an ephemeral slice of compute that runs their code, evaluates output, and feeds results back to the AI layer. That sandbox might live for 30 seconds or 30 minutes. When they close the tab, the sandbox dies.

Now multiply that by tens of thousands of concurrent users, each generating and destroying compute environments in real time. You start to see why a "standard" approach breaks down quickly.

---

The Throughput: 10 Sandboxes Created and Destroyed Every Second

Here's where the numbers get even more interesting. Lovable is cycling through roughly 10 new sandboxes per second — and simultaneously destroying 10 old ones. That's a creation-and-destruction rate of ~864,000 sandboxes per day.

This kind of ephemeral infrastructure pattern has a name in the industry: hyperscale ephemeral compute. It's the same model used by:

• Serverless platforms like AWS Lambda (function invocations per second)
• CI/CD runners like GitHub Actions (spinning up isolated runners per job)
• Browser automation platforms like Browserless or Playwright Cloud

But those platforms have years of tooling built around them. Lovable appears to be operating this pattern at a cadence that demands sub-second orchestration response times.

The Engineering Challenges at 10/sec

Timeline of a single sandbox lifecycle at Lovable:

[T+0ms]   → Trigger received (user action or AI request)
[T+50ms]  → Sandbox provisioned (image pulled, network assigned)
[T+100ms] → Code injected and execution begins
[T+Xms]   → Output captured and returned to platform
[T+Ym]    → Idle timeout detected or session closed
[T+Y+10ms]→ Sandbox gracefully terminated, resources reclaimed

At 10 sandboxes/second, the provisioning step above cannot take longer than ~100ms end-to-end, or you start queuing up a backlog. This likely means Lovable relies heavily on:

• Pre-warmed container pools — sandboxes ready to go before they're needed
• Snapshot-based boot — restoring from a known-good state rather than booting cold
• Local image caching on every node to avoid network pulls at runtime

---

The Secret Weapon: A Custom Scheduler with Exponential Smoothing Failover

This is where Lovable's architecture gets genuinely novel. Instead of relying on a standard load balancer or Kubernetes scheduler, they built a proprietary custom scheduler. The key differentiator? How it handles node failures.

In most distributed systems, when a node goes down, traffic is rerouted — but there's often a hard cutover. You might see:

• A brief spike in latency
• A burst of failed requests during the switchover window
• Uneven load distribution as the system rebalances

Lovable's scheduler takes a different approach: exponential smoothing-based traffic migration.

Understanding Exponential Smoothing in This Context

Exponential smoothing is a technique borrowed from time-series forecasting. In a scheduling context, it means that instead of making binary "node is up / node is down" decisions, the scheduler gradually shifts traffic weight away from degraded nodes using a smoothed decay function.

Here's a simplified mental model:

# Simplified exponential smoothing weight decay on node failure

def update_node_weight(current_weight, health_signal, alpha=0.3):
    """
    alpha: smoothing factor (0 = no change, 1 = instant cutover)
    health_signal: 1.0 = fully healthy, 0.0 = fully failed
    """
    new_weight = alpha * health_signal + (1 - alpha) * current_weight
    return new_weight

# Simulating gradual traffic drain from a failing node
weights = [1.0]
health_signals = [0.8, 0.5, 0.2, 0.0, 0.0, 0.0]

for signal in health_signals:
    weights.append(update_node_weight(weights[-1], signal))

print(weights)
# [1.0, 0.54, 0.378, 0.2646, 0.185, 0.1295, 0.0906]
# Traffic drains smoothly — no hard cliff

Rather than a hard cutover, traffic slides gracefully from the unhealthy node to healthy alternatives. From the user's perspective: nothing breaks, nothing stutters. Sessions continue. Sandboxes migrate.

Cross-Region and Multi-Cloud Traffic Migration

The other remarkable detail is that this failover isn't just within a single data center — it spans multiple geographic regions and multiple cloud providers. This is an extremely resilient architecture that protects against:

• Single cloud provider outages (AWS us-east-1 going down, for example)
• Regional network disruptions (undersea cable cuts, BGP misconfigurations)
• Latency degradation in specific regions during peak hours

By combining exponential smoothing with multi-cloud geographic awareness, Lovable's scheduler can make intelligent, gradual decisions like:

"Node cluster in AWS Frankfurt is degrading. Start shifting 20% of EU sandbox traffic to GCP Amsterdam. Increase to 60% over the next 30 seconds. Monitor. If stable, complete the migration."

This is sophisticated traffic engineering — the kind typically associated with companies like Cloudflare, Netflix, or Stripe.

---

What Developers and AI Engineers Can Learn From This

Lovable's infrastructure choices aren't just impressive — they're instructive. Here are the takeaways if you're building AI automation platforms, developer tools, or any system that requires ephemeral compute at scale:

• Don't assume off-the-shelf schedulers will scale with your UX requirements. If your product demands sub-100ms sandbox provisioning, you may need to build custom tooling.
• Pre-warming is not optional at scale. Cold starts are the enemy of smooth user experiences in ephemeral compute systems.
• Hard failovers are a UX problem, not just an infra problem. Exponential smoothing teaches us that how you transition matters as much as whether you transition.
• Multi-cloud is a hedge, but it requires investment. Running across AWS and GCP simultaneously adds operational complexity — but at Lovable's scale, the resilience is worth it.
• Observability is the invisible foundation. To run a custom scheduler with this much nuance, you need deep, real-time telemetry on every node, every region, and every sandbox lifecycle event.

---

Conclusion

What Lovable's tweet revealed is more than a fun infrastructure factoid — it's a window into the kind of engineering depth required to build AI-native developer tools at production scale. Managing 30,000 concurrent sandboxes, cycling through nearly a million per day, and migrating traffic seamlessly across clouds and continents without users ever noticing a blip — that's not a weekend project. That's years of deliberate systems design.

For developers building on top of AI platforms, or teams designing their own automation infrastructure, Lovable's architecture offers a compelling blueprint: invest in your scheduler, embrace ephemeral compute, and smooth out every hard edge your users might feel.

The future of AI-powered development environments is fast, resilient, and invisible. Lovable seems to be building exactly that.

---

Source reference: @dotey on X/Twitter Published on ClawList.io — Your resource hub for AI automation and OpenClaw skills.

---

Tags: DevOps Sandbox Infrastructure AI Platforms Custom Scheduler Cloud Architecture Lovable Ephemeral Compute Traffic Migration Multi-Cloud