A real IDE in your browser, with a terminal and live logs

Generated code is only useful if you can read and change it. A read-only preview is a brochure. So every Moonshift project opens in a real in-browser IDE, with the three things you actually need to work: an editor that understands your code, a terminal that can run it, and the logs that tell you what it did.

Type a change and you get LSP diagnostics as squiggles within two seconds of your last keystroke. Cmd-click a symbol to jump to its definition. Save, and the commit lands on your repo. It feels like the editor on your machine, because under the hood it is the same language server, just hosted.

Keeping the language server fast

A hosted language server is easy to get wrong in two opposite ways. Kill it too aggressively to save resources and the editor goes cold, every keystroke waits on a fresh start. Give it too much room and a single project starves the box. The current limits keep the LSP warm and responsive while still guaranteeing nothing runs unbounded.

Diagnostics are debounced to your last keystroke, so you’re not paying for analysis on every character, just on the pauses where you’d actually want feedback.

A terminal that’s actually safe

The bottom pane tabs between Preview, a real Terminal, and streaming Logs. The terminal runs allowlisted dev commands, build, test, ls, git status, grep, inside a sandbox jail: net-isolated by default, resource-limited, with a wall-clock kill. No way to wander off the project.

• Allowlisted commands only, so a stray rm can’t escape the project.
• Network-isolated by default; resource and CPU limits enforced.
• A wall-clock kill, so a runaway command can’t hold the box.
• Long-lived language servers stay warm without starving the editor.

Getting that jail right was most of the work. The allowlist is the kind of boring decision that makes the difference between a feature you can offer to the public and one you can’t.

From error to the exact line, in one click

Stack-trace references in both the terminal and the logs pane are clickable. Run a build, click a type-error line, and the editor jumps you to exactly that spot. The loop from “error” to “the line that caused it” is a single click, no copy-pasting a path into a fuzzy finder.

That sounds small. In practice it’s most of debugging: the slow part is rarely the fix, it’s finding the line. Collapsing that to a click changes how it feels to work in a codebase you didn’t write yourself five minutes ago.

Logs where the work is

The Logs tab tails your latest production deployment, so the place you read errors is the same place you fix them. No tab-switching to a separate dashboard, no copy-pasting a trace into a search box. The error, the code, and the fix all live in one window.

Why in the browser at all

Because the project already lives on our infrastructure, the repo, the database, the deploy. Pulling it down to a laptop just to read one file is friction. An in-browser IDE means you can go from “what does this do?” to a committed change without leaving the page the app already lives on.

“The editor, the terminal, and the logs in one place. That’s most of debugging.”