code-server: Running VS Code in a Browser Without Sacrificing Your Workflow

What code-server Actually Solves

code-server solves a specific pain: you want to use VS Code, but you do not want to run it on the machine in front of you. The README frames it as running VS Code on any machine anywhere and accessing it in the browser. That means your editor, its extensions, and your workspace live on a server. You connect from a laptop, a tablet, or any device with a browser. The heavy lifting, like compilations and test runs, happens on the server. The stated benefit is a consistent development environment across devices, and it preserves battery life on a laptop because the local machine only renders the UI. This is for developers who work on remote servers anyway, or who need a uniform setup regardless of the client hardware. It is not for someone who just wants a web-based text editor; it is for someone who wants the full VS Code experience, but hosted remotely.

How It Works: A Browser Front End, a Server Back End

The repository is written in TypeScript, and it is essentially a wrapper around the VS Code source. Code-server takes the VS Code editor, runs it as a server-side application, and exposes it over HTTP. The browser client communicates with the server using WebSockets, which is why the requirements explicitly state a Linux machine with WebSockets enabled. The architecture is not a thin remote desktop; it is the actual VS Code interface rendered in the browser. The README does not detail the internal data flow, but the WebSocket requirement tells you that the connection is persistent and bidirectional, not simple request-response. This has implications for network setups: any proxy or firewall that blocks WebSockets will break the editor. The project also integrates with devcontainers, so you can run code-server inside a development container, which suggests the server component is designed to be container-friendly. The core mechanism is straightforward: the server hosts the editor, the browser renders it, and the two stay in sync over a live connection.

Getting It Running: The Install Script and Its Dry Run

The README offers five ways to get started, but the primary path is the install script. You can preview what the script will do before running it, which is a sensible safety measure for a script that you pipe directly into sh. The dry-run command is:

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

That shows you the steps without making changes. The actual installation is:

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

The script uses the system package manager if possible, which means on Debian or Ubuntu it will likely pull a .deb package, and on RHEL it will use yum or dnf. After installation, the script prints instructions for running and starting code-server. The README does not give the exact command to start the server, so you will need to read the printed output or check the documentation. The other four methods are manual installation, deploying via coder/coder for teams, using one-click cloud provider deployments, or using the devcontainer feature. The manual route is for people who want more control over the installation, and the cloud provider guides are for those who want a pre-configured VM. The dry-run flag is a small touch that shows the project cares about the trust problem inherent in curl-piping.

Hardware and Network Requirements: The Real Constraints

The README gives a TL;DR for requirements: a Linux machine with WebSockets enabled, 1 GB RAM, and 2 vCPUs. That is a modest spec, but it is not trivial. A 1 GB RAM machine will run the editor, but if you also compile large projects or run a database, you will hit memory limits quickly. The WebSocket requirement is the one that surprises people. Many corporate networks or cloud load balancers do not support WebSockets by default, and if they are not enabled, the browser client cannot maintain the connection to the server. The README points to a separate requirements page for minimum specs and instructions on setting up a Google VM, but it does not list the exact steps here. That means you have to click through to the documentation to know whether your existing server qualifies. The practical takeaway is that this is not a zero-footprint tool; it needs a persistent, low-latency connection, and the server must have enough RAM to run both the editor and your development tasks. If your server is underpowered, the browser experience will suffer, and you will not gain anything over running VS Code locally.

Where It Falls Short: A Single-User Tool by Default

The most obvious limitation is that code-server is designed for a single user. The README does not mention authentication, user management, or multi-tenancy. It is a tool for you to run on a machine you control. If you want to give your team access to shared development environments, the README explicitly points you to coder/coder, which is a separate product for managing code-server for a team on your infrastructure. That is a significant gap if you are evaluating code-server for an organization. You will end up building your own access control, or you will switch to coder/coder. Another limitation is that the browser experience depends on network quality. If you have a flaky connection, the WebSocket will drop, and you will lose your editor session. The README does not address offline mode or reconnection behavior. Also, because it is a full VS Code instance, it consumes server resources even when you are not actively typing; the editor is always running. This is fine for a single developer, but it becomes a cost problem if you spin up multiple instances for a team. The wrong tool would be any scenario where you need shared workspaces, role-based access, or a lightweight editor that runs on a Raspberry Pi-class device.

The Alternative: coder/coder for Team Management

The README does not hide the fact that code-server is a stepping stone. It repeatedly points to coder/coder, which is the same company's product for deploying code-server to a team. The difference in approach is significant. code-server is a single-instance server that you install on a machine and access directly. coder/coder is a control plane that provisions and manages multiple code-server instances, handles user authentication, and provides a dashboard for teams. The README says code-server is for individuals, and coder/coder is for teams. If you are an engineer who wants a remote editor for yourself, code-server is the right choice. If you are an IT administrator who needs to give 50 developers access to cloud development environments, you should look at coder/coder instead. The alternative is not a different editor; it is the same editor with an orchestration layer on top. That distinction matters because the install and maintenance burden is completely different. With code-server, you are responsible for the OS, the network, and the editor updates. With coder/coder, the platform handles much of that, but you also have to deploy and operate the platform itself. There is no free lunch.

Maintenance and Upgrade Cost: What the Repo Tells Us

The repository is active, with releases coming out roughly weekly. The latest release, v4.135.0, was pushed on 2026-08-27, and the previous ones are from the same month. That cadence means you will need to update frequently to get bug fixes and security patches. The README does not describe an automatic update mechanism; the install script may or may not set up a service that updates itself. You will likely need to re-run the install script or manually download new versions. The project is MIT licensed, which gives you broad freedom to modify and redistribute, but it also means there is no commercial support unless you buy into coder's products. The maintenance cost is moderate. If you run code-server on a bare VM, you have to handle OS updates, code-server updates, and any security issues in the WebSocket endpoint. The devcontainer feature suggests that you can containerize code-server, which would make upgrades more reproducible, but the README does not give specific commands for that. The upgrade cost is not zero, but it is not prohibitive for a single user. For a team, the maintenance burden multiplies, which is another reason to consider coder/coder.

Editorial conclusion

Adopt code-server if you are an individual developer or a small team that needs a consistent development environment on a remote Linux box, especially if battery life or local compute is a constraint. Do not adopt it if you expect a fully managed, multi-tenant experience with user management and workspaces out of the box; that is what coder/coder is for. Before you commit, verify that your network allows WebSockets, that your server meets the 1 GB RAM and 2 vCPU minimums, and that you are comfortable running an install script from the internet. Check the current release notes for any breaking changes, and test the dry-run mode first.

Official sources

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