Self-Host VS Code with Greffon

A code editor in the browser sounds like a novelty until you have switched machines once. Your editor, your extensions, your open files, and the terminal next to them all live on one server instead of one laptop. Open a browser on any device and you are back where you left off. The Greffon catalog ships this as openvscode-server, the open build of VS Code that runs as a service, and Greffon takes the reverse proxy and certificate work off your plate.

Why own the editor

openvscode-server is the same VS Code you know, running on a server and rendered in your browser. The editor, the integrated terminal, and the files you are working on all sit on the greffer. That means your work runs with the greffer's CPU and memory, not your laptop's, and it keeps running when you close the tab. Grafting it onto a greffer means that environment lives on a machine you own, not a workspace you rent by the seat.

It is worth being precise about what this is and is not. This is the open-source build (openvscode-server), not the Microsoft-branded VS Code, and it does not include the proprietary Marketplace or Microsoft account sign-in. Extensions install from the open registry instead. Day to day it is the editor you expect, with a few brand-tied pieces left out.

Graft it from the catalog

On a greffer you do not hand-write a compose file or wire a reverse proxy. Pick VS Code from the catalog and graft it onto your greffer. Greffon issues the certificate and routes the app, so the editor comes up reachable over HTTPS without you assembling that plumbing by hand. Your files persist in a volume on the greffer, so they survive a restart or a version bump of the greffon.

Reach it from anywhere

A browser editor is only useful if your browser can reach it. On the same network as your greffer it works the moment it starts. To reach it from anywhere else, you have two honest options, and the good news is that this app fits the simpler one cleanly.

openvscode-server is a plain HTTP app: it serves the editor over a single web port and nothing it needs runs over UDP. That means Greffon's built-in tunnel covers it. A greffer behind NAT or CGNAT connects outbound to the manager's tunnel and serves the editor with no inbound ports opened at all. If you would rather expose the greffer directly, port forwarding plus dynamic DNS works too. Either way the editor stays reachable over HTTPS.

Size the box right

This is the tradeoff most browser-IDE walkthroughs skip. The editor is light, but your work is not. Language servers, a running dev server, a build, or a test suite all consume the greffer's memory and CPU, not your laptop's. A tiny free-tier box is fine for editing and light scripting. A TypeScript monorepo with three language servers and a watch build will feel cramped on 1 GB of RAM.

Lock the front door

A self-hosted editor is a powerful thing to leave exposed. It ships with an integrated terminal, which means anyone who reaches it gets a shell on your greffer with the editor's permissions. HTTPS (which Greffon handles) protects the traffic in transit, but it does not decide who is allowed in.

Treat the editor URL as a credential. Do not hand it out, keep the greffon access controls tight, and do not expose it more broadly than you need. If a teammate needs in, give them their own path rather than sharing one open door. The integrated terminal raises the stakes here past those of a read-only web app.

Back up your work

Your code probably lives in git, and pushing to a remote is the first line of defense: commit and push often and most of your work is safe off the greffer already. But the workspace also holds the things git does not, such as uncommitted changes, editor settings, and local config. Greffon handles TLS and routing today, and native one-click backups are coming in M2. Until then, bring your own backup tool (restic or borgbackup are the usual choices), back up the workspace volume on a schedule, and store a copy off the greffer.

FAQ