the in-browser ide: what it actually runs, what it can't

the dreamclerk in-browser ide runs entirely in your browser tab. no ssh. no remote desktop. no citrix. open a tab, and you are inside a 2-vcpu, 4gb-ram linux microvm with node, python, go, java, postgres, redis, and a real terminal. cold start is 200ms on a 2020 macbook air, 1.4s on a 2018 android phone. it ships as 12mb of wasm and ~80kb of javascript.

this post is the architecture. if you are an applicant, the architecture is not on the rubric. if you are a curious engineer, the architecture is what makes the in-browser ide feel like a real ide instead of a glorified fiddle.

the stack, top to bottom

1. react + vite for the shell, the file tree, the tabs, the status bar.
2. monaco editor for the editor itself. monaco is the engine that powers vs code. it has the same keybindings, the same extension host, the same command palette. it is loaded from a cdn with a crossorigin header and a 24-hour cache, so the first load is ~3mb, and subsequent loads are <100kb.
3. xterm.js for the terminal. real escape sequences, real alt-key handling, real copy-paste, real scrollback.
4. webcontainer api for the underlying linux. webcontainer is a wasm-built node-and-system-call layer that runs entirely in the browser sandbox. it is the same technology stackbit and replit use. the webcontainer boots in ~200ms, exposes a real filesystem, and runs node 20, python 3.11, and a postgres binary.
5. a custom pr service that watches the in-browser filesystem, detects commits (via the in-browser git client), and ships the diff to the dreamclerk backend for review.

the security model

the in-browser ide is, by construction, a sandbox. the webcontainer runs in a single browser tab, with no network access to your local machine, no shared filesystem with your laptop, and no ability to make outbound network calls except through a whitelisted proxy (the dreamclerk api).

what that means in practice:

• the ide cannot read your laptop's files
• the ide cannot write to your laptop's files
• the ide cannot make an outbound network call to a third-party api (so it cannot exfiltrate your code, your api keys, or your activity)
• the ide's filesystem is destroyed when the tab is closed
• the ide's filesystem can be re-attached to a new tab by re-loading the same sprint, which restores from the dreamclerk backend

the only thing the ide can do is talk to the dreamclerk backend. the backend is where the pr is reviewed, where the rubric is scored, where the cert is signed. the ide is the read-write side; the backend is the trust side.

the 3 things the in-browser ide cannot do

1. run code that needs a real linux kernel. you can run node, python, go, java, and a postgres binary. you cannot run a docker container, a kernel module, or a c++ binary that needs glibc 2.34. if your capstone is "deploy a postgres cluster with logical replication," you will not be able to do the cluster part in the browser ide — you will do the schema design, the query plan, the indexing strategy, and the replication slot config in the ide, and you will do the cluster part on a remote box. this is a deliberate trade-off. the cost of supporting the full kernel is ~80mb of wasm and a 4-second cold start. we chose fast.

1. open a tcp socket to a third-party host. the in-browser ide can talk to the dreamclerk backend, the bundled postgres, and the bundled redis. it cannot talk to api.github.com, api.openai.com, or your own server. if your capstone needs to hit an external api, you have two options: bundle the api as a fixture (and the ide mocks it), or use a backend-side proxy that the ide talks to. both options are real engineering. they are the same options you would have in a 1-week project at a real company.

1. persist state across sprints in a way you can read on your laptop. the in-browser ide's filesystem is stored in the dreamclerk backend, not on your laptop. you can browse it from the ide, you can git pull it into a local clone, and you can git push from a local clone back into the ide. but you cannot cp -r the filesystem to your laptop. this is a security choice: it means the only place the code lives is the dreamclerk backend, and the only way the code leaves the dreamclerk backend is through a signed, reviewable pr.

why we chose this stack

we considered four other stacks.

• github codespaces. rejected because the cold start is 8–25 seconds, the per-user cost is ~$0.18/hour, and we needed a sub-second cold start for the in-cohort experience.
• gitpod. rejected for the same reason.
• eclipse theia + a remote dev server. rejected because the remote dev server is a single point of failure and the cost model is worse than codespaces.
• a custom ide built on codemirror 6. rejected because the extension story is much weaker than monaco, and we wanted every applicant to feel like they were in vs code, not in a clone of vs code.

the in-browser ide is not the cheapest stack, the most powerful stack, or the most portable stack. it is the stack that lets a student in a tier-3 college with a 4gb-ram android phone ship the same code as a student with a 32gb-ram m2 macbook, with the same keybindings, the same extensions, and the same pr flow.

the roadmap

we are working on three things.

1. a real kernel. the webcontainer team is shipping a beta that supports docker. when it does, we will switch the in-browser ide to use it. the cost will be a 4-second cold start, which is acceptable for sprint-2 and later, and not acceptable for sprint-1 onboarding. we will keep the current stack for sprint-1 and switch to the new stack for sprint-2.

1. a third-party api proxy. we are building a backend-side proxy that lets applicants configure a whitelisted list of third-party apis (the github api, the openai api, the stripe api, etc.) and have the in-browser ide talk to them. the proxy will rate-limit, log, and surface the api calls in the pr review.

1. a local-only mode. for applicants who do not want their code in the dreamclerk backend (a small but real fraction), we are building a local-only mode that runs the same ide in their browser, with a local sqlite database, and no pr flow. the cap is no certificate.

what this is not

this is not a replacement for a real local dev environment. applicants who already have one should keep using it for personal projects. the in-browser ide is for the cohort, for the pr flow, for the review round. it is not for the work you do on your own time.

what this is

a deliberate, opinionated, in-browser ide that gives every applicant the same surface, the same keybindings, the same pr flow, and the same review round. the surface is monaco. the pr flow is git. the review round is the dreamclerk AI tech lead. the surface is the artifact. the pr flow is the protocol. the review round is the rubric.

the in-browser ide is the smallest possible surface that lets a tier-3 student with a 4gb android ship the same code as a tier-1 student with an m2 macbook. that is the whole point.

— dreamclerk team, chennai, june 2026

related posts

• shipping code vs knowing code
• building the in browser ide a postmortem