Making Sandboxes Fast for Vibe Coding

Oct 28, 2025

If you’re running ephemeral sandboxes for AI coding sessions (think Lovable, Cursor, or any vibe-coding setup), you’ve probably felt the pain of slow cold starts and laggy responses. Here’s how to fix that.

1. Bake everything into your image

Stop installing dependencies every time you spin up a sandbox. It’s slow, wasteful, and kills your flow.

Don’t do this:

// Installing deps on every sandbox start = slow
const sandbox = await client.sandboxes.create();

await sandbox.commands.run('apt-get update && apt-get install -y nodejs npm');
await sandbox.commands.run('npm install');
await sandbox.commands.run('npm run dev');
// 30+ seconds before you can do anything

Do this instead:

Build a custom image with everything pre-installed:

FROM node:20-alpine
WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .
EXPOSE 3000
CMD ["npm", "run", "dev", "--", "--host", "::"]

Push it to a registry:

docker build -t my-app:latest .
docker push my-app:latest

Then use it in your SDK:

const sandbox = await client.sandboxes.create({
  image: 'my-app:latest'
});
// Server is already running. Ready in ~1 second.

Cold starts drop from 30+ seconds to ~1 second.

Pro tip: Copy your package.json before your source code. Docker caches layers, so you only reinstall when dependencies actually change.

2. Reuse your sandbox

Creating a fresh sandbox for every operation is like restarting your laptop every time you open a file. Don’t do it.

Instead, keep one sandbox alive for your entire session:

Use a session token to route requests to the same instance
Set a short idle timeout (5-10 minutes) to clean up when you’re done
Add a kill endpoint so you can tear it down explicitly

Think of it like keeping your IDE open instead of closing it after every edit. Your caches stay warm, your state persists, and everything just feels faster.

3. Run your agent inside the sandbox

Network calls are slow. Localhost is fast. If your AI agent is making dozens of file operations or tool calls, co-locate it with your code.

Run your agent runtime in the same container or as a sidecar. Use localhost HTTP, Unix sockets, or direct RPC. No egress fees, no network latency, no auth headaches.

Bonus: if you’re using embeddings or small models, cache them in the image. Load once, use forever.

4. Rightsize your sandbox resources

Not all dev servers are created equal. Next.js is notoriously memory-hungry—it’ll easily eat 1GB+ RAM and slow down your dev experience. Soon you will be able to customize your sandbox resources.

For Next.js projects, you can tune the dev server with memory optimization flags:

// package.json
{
  "scripts": {
    "dev": "NODE_OPTIONS='--max-old-space-size=2048' next dev"
  }
}

But the real fix? Use lighter tools. Which brings us to…

5. Choose fast tools

Your toolchain directly impacts iteration speed. Here are some faster alternatives worth considering:

Vite over Next.js for dev

Next.js hot reload: 1-2 seconds
Vite hot reload: 300-400ms
5x faster feedback on every edit.

Biome over ESLint

ESLint + Prettier: 2-3 seconds to lint/format
Biome: 200-300ms for both
Written in Rust, handles linting and formatting in one tool.

Bun over npm

npm install: 20-30 seconds
bun install: 2-3 seconds
Drop-in replacement that’s significantly faster for installs and runs.

// Fast stack example
const sandbox = await client.sandboxes.create({
  image: 'my-vite-app:latest',  // Vite for dev server
});

// In your Dockerfile:
// RUN bun install        # Fast installs
// RUN bun run build      # Fast builds

These tools are newer and still maturing, but they’re well-adopted and production-ready for most use cases. For vibe coding where you’re iterating constantly, the speed gains add up quickly.

6. Use pm2 to keep things alive

Vibe coding means rapid iteration. Your dev server will crash. Files will change. You need auto-recovery.

npx pm2 start "npm run dev" --name app --watch --ignore-watch node_modules

pm2 watches your files, restarts on crashes, and handles signals properly. It’s the difference between “my server died and I lost 5 minutes” and “it restarted before I noticed.”

Quick wins checklist

Pre-baked Docker image with all dependencies
One sandbox per session, not per operation
Agent running on localhost, not across the network
Fast tools: Vite over Next.js, Biome over ESLint, Bun over npm
pm2 or similar process manager for auto-restart
Short idle TTL to clean up abandoned sessions

Get these right and your sandbox will feel as fast as local dev. Maybe faster.