code-server

Last reviewed Aug 23, 2026 · 696 words

code-server puts full VS Code in a browser tab, running on your server's CPU, RAM, and files — which means the iPad, the Chromebook, or the locked-down work laptop becomes a real development machine the moment it can reach a URL. It's the self-hosted answer to GitHub Codespaces with no hourly meter. It is also, by its nature, a web page that can execute arbitrary commands on your server, which makes its security posture the most important paragraph in this guide.

Never expose it raw — a terminal is the prize

A code-server session includes an integrated terminal with the permissions of its user. Anyone who gets past auth owns that user, and internet scanners look for code-server specifically. The password in ~/.config/code-server/config.yaml is a single static string with no 2FA and no lockout — treat it as a speed bump, not a lock. The safe patterns, in order of preference:

1. VPN-only (the strong default): bind to localhost or the Tailscale interface and never publish it at all. Every device you'd code from can run a VPN client; this is the one service where "but my client can't do VPN" almost never applies.
2. Reverse proxy with real auth in front: Caddy or similar terminating TLS, with SSO or at minimum basic-auth layered over code-server's own password. Websocket pass-through is required or the editor won't load. The remote access rundown covers the trade-offs.

Run it as a normal user, not root, and give that user only the projects it needs — the blast radius decision is made at install time, not incident time.

The extension store isn't the one you know

code-server cannot legally use Microsoft's extension Marketplace, so it ships with the open Open VSX registry instead. Most big names are there — language servers, themes, Vim keybindings — but some Microsoft-proprietary extensions (Pylance, the remote-development pack, Copilot's official client) are absent or ship alternatives. Check your three must-have extensions on Open VSX before committing your workflow; .vsix sideloading covers occasional gaps. This is the honest difference between code-server and desktop VS Code, and it's better to meet it on day one than mid-project.

Size the box for the toolchain, not the editor

The 512 MB minimum runs the editor; it does not run your language servers. A TypeScript or Rust project's tooling costs the same on a server as on a laptop — count 2–4 GB for comfortable single-project work, more for monorepos or when the terminal is compiling. The pleasant surprise cuts the other way: because the heavy lifting happens server-side, the client can be genuinely feeble, and an old tablet drives a 16-core build box at full speed. Put the server on real hardware sized by the Pi vs mini PC math and the browser side takes care of itself.

Small settings that make it feel native

• Browsers steal VS Code's keybindings (Ctrl+W closes the tab, not the file). Install it as a PWA ("install app" in Chrome/Edge) and most conflicts disappear along with the URL bar.
• Settings Sync works against your existing account, so your desktop profile — theme, keymaps, snippets — follows you in minutes.
• Everything lives under the user's home: ~/.local/share/code-server for state, your normal project folders for code. Back up dotfiles and projects as usual and the instance is disposable.
• Pair it with a self-hosted git forge and the loop — edit, commit, push, CI — never leaves your network.

What I'd do

code-server as an unprivileged user on the homelab's main box, bound to the Tailscale interface only, installed as a PWA on every client device, extensions verified against Open VSX up front, 4 GB of headroom. Used that way it's the best answer yet to coding from anywhere without carrying the machine that matters — and the terminal-shaped attack surface stays a private amenity rather than a public offering.