Back to Hub

Frontend code doesn't need a cloud container.

Every time you open a CodeSandbox, a container spins up in a datacenter somewhere. Every time you open a StackBlitz, a full Node.js runtime boots inside your browser tab, compiled to WebAssembly. Both are remarkable feats of engineering. Both are also — for an enormous category of everyday work — completely unnecessary.

Here is the question neither company's marketing asks: what exactly is the container doing while you edit a landing page? If the answer is "nothing," you are paying for infrastructure — with your time, your data, or your wallet — that your project never needed.

This is a deep dive into the three ways to run frontend code in 2026: CodeSandbox's cloud containers, StackBlitz's in-browser WebContainers, and NitroIDE's deliberately container-free approach. No marketing fluff, and full honesty about where each one wins.

How CodeSandbox actually works

CodeSandbox gives every sandbox its own Linux container running on their cloud. That container is a real computer: it runs npm install, starts dev servers, executes Node backends, and can host databases. When you fork a React template, you are provisioning infrastructure.

That power has three costs. First, the account wall: meaningful use requires signing up. Second, the meter: the free tier rations compute — build minutes, container hours, and resource caps that nudge heavy users toward paid plans. Third, the cold start: containers sleep when idle, so reopening a project often means watching a spinner while your little cloud computer wakes up.

For full-stack work — a Next.js app with API routes and a database — this is the right architecture, and CodeSandbox does it well. For a portfolio site, it is a datacenter doing the job of a text file.

How StackBlitz WebContainers actually work

StackBlitz took a radically different path. Instead of renting you a cloud computer, they compiled Node.js itself to WebAssembly and run it inside your browser tab. Your npm install executes locally. Your dev server runs locally. When people say "WebContainers," they mean a real Node runtime living in your tab — no remote server does the compute at all.

Credit where it's due: this is genuinely impressive engineering, and for framework work (Next.js, Vite, Astro) it's the closest thing to a local dev environment you can get without installing anything. But a browser tab is still a browser tab: installs can be slow and memory-hungry, large node_modules trees strain the tab, and the full experience still sits behind an account.

The third option: no container at all

NitroIDE asks a simpler question: if your project is HTML, CSS, and JavaScript, why boot anything? Browsers already execute all three natively — that is literally what they are for. There is no container to spin up because there is nothing to contain.

The whole architecture fits in one paragraph: the Monaco editor (VS Code's engine) edits files stored in a virtual file system backed by your browser's local storage. The preview is an iframe on the same machine. Dependencies skip npm entirely — libraries load from CDNs via <script> tags or import maps, the way the web consumed libraries for a decade before bundlers took over.

The result: the workspace opens instantly, works offline as an installable PWA, and your code runs only in your browser. The trade — stated plainly in the "can't do" list below — is that anything needing a real backend has nowhere to run.

Head-to-head: the honest table

What you can actually build without a container

More than you'd expect. Anything with a CDN or ESM build works: React 18 via an import map, Vue, Svelte, Three.js, GSAP, Tailwind through the one-click CDN panel. Multi-file projects, live preview, Emmet, find-and-replace — the full editor experience, minus the waiting room.

That pattern — ESM CDNs plus import maps — covers the large majority of what people actually prototype in sandboxes: landing pages, portfolios, dashboards, interactive demos, client-side tools. When you're done, Export → Download ZIP hands you real files. No lock-in, no export credits, no "upgrade to download."

What NitroIDE can't do — the honest list

A comparison that only lists wins is an ad. Here's the full list of what the container-free approach gives up:

• No Node.js runtime. No Next.js server components, no Express, no API routes, no SSR. If your app needs a server, it needs a server.
• No npm. Dependencies must ship a CDN or ESM build. Anything that only exists as an npm package with no browser build stays out.
• No build step. No JSX transform, no TypeScript compilation, no bundler. You write the code the browser runs.
• No backend or database. No Postgres, no Redis, no cron jobs, no "always-on" anything.
• No multiplayer. It's a single-player editor on your machine — no shared cursors, no team workspaces.

Moving a CodeSandbox frontend sandbox to NitroIDE

If your sandbox is frontend-only — no server file, no database — the move takes about ten minutes. There is no importer (there is no NitroIDE server holding your projects to import from), so it's manual, and it's straightforward:

• Step 1 — Copy your files out. Open each file in your sandbox, select all, copy. Keep a scratch document with filenames attached so nothing gets mixed up.
• Step 2 — Recreate the files in NitroIDE. Open NitroIDE Codebox and create matching files — index.html, style.css, script.js, whatever your project uses.
• Step 3 — Convert imports to CDN. This is the one real translation step. Replace import ... from 'package-name' / require(...) with <script> tags or an import map pointing at esm.sh or unpkg. Use the CDN panel's one-click buttons for Tailwind, jQuery, and GSAP.
• Step 4 — Paste and preview. Paste each file's contents in. The live preview updates as you go, so mismatches show up immediately.
• Step 5 — Export to ZIP. That's your backup and your portable copy — your files live in this browser's storage, so the ZIP is how they travel.

If your sandbox has a server.js, a database, or environment variables, stop at Step 1 — that project belongs on CodeSandbox or StackBlitz, and no honest guide would tell you otherwise.

The verdict: use the right computer for the job

There is no single winner here — there are three different answers to three different questions:

• Choose CodeSandbox when your project needs a real backend: API routes, databases, hosted full-stack apps, team collaboration.
• Choose StackBlitz when you want Node frameworks (Next.js, Vite, Astro) running in the browser without installing anything locally.
• Choose NitroIDE when your work is frontend-only and you'd rather skip the account, the quotas, the cold starts, and the cloud entirely — instant, private, offline-capable, and free with no meter running.

The container was never the point. Shipping the thing was. Pick the tool whose computer matches your project — and if your project never needed a computer at all, you know where to find us.

Frequently asked questions

When should I pick CodeSandbox?

When your project needs a real backend — API routes, databases, hosted full-stack apps, or team collaboration.

When should I pick StackBlitz?

When you want Node frameworks like Next.js, Vite, or Astro running in the browser without installing anything.

When should I pick NitroIDE?

When the work is frontend-only HTML, CSS, and JS and you want no account, no quotas, and no cold starts — instant, private, offline-capable, and free.

Can NitroIDE run npm packages?

Only via CDN or ESM builds — script tags or import maps. There is no npm install and no build step.

Can I move a CodeSandbox frontend project to NitroIDE?

Yes — copy the files out, recreate them in Codebox, convert imports to CDN, paste and preview, then export to ZIP.