code-server: VS Code in the browser, and how to install it on a Linux box

What code-server actually solves

The README states the goal plainly: run VS Code on any machine anywhere and access it in the browser. The problem it addresses is not editing code, which VS Code already does well, but the split between where the editor runs and where the code lives. If your build machine has the CPU, the RAM and the network path to your dependencies, you can put the editor there too and stop copying files back and forth.

The audience follows from that. The README lists three motivations: coding on any device with a consistent environment, using cloud servers to speed up tests, compilations and downloads, and preserving battery life because intensive tasks run on the server. That is a description of a developer with a weak or shared client and a strong server, not a developer who wants a faster local editor. A laptop on a train, a tablet, a locked-down corporate desktop: these are the clients the project is aimed at.

The repository itself is TypeScript, MIT licensed, with the VS Code source vendored under lib/vscode and patched from the patches/ directory. That patch directory is the honest signal of what the project is: a maintained fork-and-wrap of Microsoft's editor, not a reimplementation of it.

How the server, the browser and VS Code fit together

The shape of the system is visible in package.json. The main entry point is out/node/entry.js, so the runtime is Node on the server side. The build scripts are split into build-code-server.sh and build-vscode.sh, which confirms two separable artifacts: the Node wrapper and the patched editor bundle. The patches/ directory holds the changes applied on top of upstream VS Code.

The browser is the client. The server holds the workspace, the extensions, the integrated terminal and the language servers. The README's requirement line is the practical consequence: a Linux machine with WebSockets enabled, 1 GB RAM and 2 vCPUs. WebSockets are called out because the editor's connection to the server is long-lived and bidirectional; a proxy that terminates or buffers WebSocket upgrades will break the session in ways that look like random disconnects rather than a clean error.

That architecture explains the trade-offs you will meet. Everything the editor does happens on the server, so a slow server is a slow editor, and a network interruption is an interruption of your editing session rather than a pause in a background sync. It also explains why the project ships Docker images and devcontainer features: the same server-side model maps cleanly onto a container.

Installing code-server with the install script

The README gives five routes: the install script, a manual install, coder/coder for teams, one-click cloud provider deployments, and the devcontainer feature. The install script is the shortest path and the one the README documents in full. It uses the system package manager where possible.

Before running anything, the README shows a dry run. This prints what the script would do without doing it:

curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run

If the output is acceptable, the real install is the same command without the flag:

curl -fsSL https://code-server.dev/install.sh | sh

According to the README, the script prints instructions for running and starting code-server when it finishes. That is your next step, and it is where you will find the port and the authentication settings for your install, since the README does not spell them out on the front page. For a first real use, the README's own framing is the test: open the printed URL from a second device, open a folder on the server, and confirm the integrated terminal runs on the server rather than on the client. If the terminal shows the server's hostname, the data flow is working as designed.

For teams, the README points at coder/coder rather than describing a multi-user mode inside code-server itself.

Where code-server is the wrong tool

The README's requirement line is the first limitation, and it is not a soft one: Linux, WebSockets, 1 GB RAM, 2 vCPUs. There is no Windows or macOS install path described on the README page. People search for code-server on Windows, but the documented deployment target is a Linux machine or a container. If your only computer runs Windows and you wanted a local install, this is not the project for that.

Running code-server on a small VPS to save money is a second trap. The editor, the extensions, the language servers and the terminal all execute on that host. A 1 GB instance is the stated floor, not a comfortable target, and the moment you add a TypeScript language server or a JVM-based toolchain you are competing with the editor for the same memory.

A third case is a network path that cannot hold a persistent connection. Because the session depends on WebSockets, a corporate proxy that strips upgrade headers or an unreliable mobile link turns the editor into something that reloads mid-keystroke. The README does not document rollback or an offline mode, so there is no supported fallback for that situation.

Finally, a security note the README does not develop: the browser is the only client, so the authentication in front of that URL is the whole boundary. The README points to the setup and configuration guide rather than covering it inline, and that guide is where you should look before exposing the port beyond localhost.

code-server compared with openvscode-server

The comparison people ask about is openvscode-server, which is the other well-known way to get VS Code into a browser. The difference is in the packaging philosophy. openvscode-server takes upstream VS Code and adds a server entry point, keeping close to the Microsoft codebase. code-server keeps a patches/ directory and a separate Node wrapper (out/node/entry.js) around the same editor, and it ships an install script, distribution packages, Docker images, a devcontainer feature and a documented path to coder/coder for teams.

So the practical choice is about how much surrounding product you want. If you want the thinnest possible server build of VS Code and you are comfortable wiring up your own process management and TLS, openvscode-server is closer to that. If you want an install script that uses your package manager, a dry-run preview, and a documented team path, code-server is the one that provides those. The editor underneath is the same lineage either way, so the decision rests on the wrapper, the release cadence and the documentation, not on the editing experience.

Releases, upgrades and the MIT licence

The project is not archived, and the last push was on 2026-08-27. Releases arrive frequently: v4.133.0 on 2026-08-17, v4.134.0 on 2026-08-24 and v4.135.0 on 2026-08-27, all within the same month. That cadence is the main upgrade cost. code-server tracks upstream VS Code, and the patches/ directory has to be rebased as upstream moves, which is why the release notes are the right place to check before jumping versions rather than upgrading blindly on a schedule.

Because the editor is served from the server, an upgrade is a server-side operation: you replace the installed version and the next browser reload picks it up. There is no client to update, which is the pleasant half of the trade-off. The unpleasant half is that a broken upgrade takes the editor away from every client at once.

The licence is MIT, stated in both the README-adjacent repository metadata and package.json. That is permissive and places few conditions on redistribution. Note that the repository also carries a ThirdPartyNotices.txt file, which is where the bundled VS Code components and their terms are recorded. I am not a lawyer and this is not legal advice: if you plan to redistribute code-server inside a product, read LICENSE and ThirdPartyNotices.txt together, because the MIT licence on the wrapper does not by itself describe every component shipped in the bundle.

Editorial conclusion

Adopt code-server if you have a headless Linux server, WebSockets enabled, and want the same editor on a laptop, a tablet and a borrowed machine. Do not adopt it if your only hardware is Windows or macOS and you wanted a desktop install, or if you need a supported release line older than the current one. Verify three things before you commit: that your host meets the stated minimum of 1 GB RAM and 2 vCPUs, that your reverse proxy forwards WebSocket upgrades, and what the install script actually does on your distribution, which you can see with the dry-run flag before anything is written.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes