Tech Digest

Developer

code-server

VS Code in a browser tab, on your server, without a Microsoft account

DeveloperMITMaturearm64 builds
Last reviewed Profile maintained against the project's own documentation
Operational load
2 / 5
Light
Idle memory
200 MB
typical use ~900 MB
Moving parts
1
containers in a normal deployment
Backup shape
File copy
live file copy safe

code-server runs the open source core of VS Code as a web application, so your editor, terminal and language servers live on the server and you reach them from any browser. It replaces GitHub Codespaces or a local IDE for people who want their development environment on one machine and their laptop to be a thin client.

Our verdict on code-server#

The single thing to understand before you install code-server is the marketplace. Microsoft's terms restrict the VS Code Marketplace to Microsoft's own products, so code-server ships pointing at Open VSX instead. Open VSX carries most genuinely open source extensions, including the community Python and Go extensions, ESLint, Prettier, Vim keybindings and the popular themes. It does not and cannot carry Microsoft's proprietary ones: Pylance, the C# Dev Kit, the remote development pack and Live Share are all absent, and code-server's own FAQ names Live Share and the Remote extensions as not working. If your workflow depends on Pylance's type checking or the C# tooling, stop here. You can repoint the gallery with the EXTENSIONS_GALLERY environment variable, but doing that against Microsoft's endpoint is a terms violation, not a supported configuration. Everything else works well: current builds track upstream Code closely, the amd64 and arm64 images are official, and a 2 GB VPS is a usable machine.

Who code-server is for#

Choose it if

  • Developers who want one beefy server holding the source, the toolchain and the containers, and to reach it from a laptop or tablet.
  • People working on remote hardware where copying a repository back and forth is the actual bottleneck.
  • Anyone standardizing a team on one preconfigured environment image rather than ten inconsistent laptops.
  • Homelab users who already run everything else in containers and want the editor beside the code.

Look elsewhere if

  • Your work depends on Pylance, the C# Dev Kit, Live Share or the Remote SSH/Containers/WSL extensions, none of which are available.
  • You need per-user accounts and isolation, because code-server has one password and one filesystem view.
  • You want the full Coder platform with workspace provisioning and templates, which is a different, larger product from the same vendor.

What running it actually looks like#

One container or one system package. It binds 127.0.0.1:8080 by default and writes ~/.config/code-server/config.yaml on first start with a generated password, which is where you go to find it. Official releases cover amd64 and arm64 for the tarball, deb, rpm and the codercom/code-server image; other architectures go through npm, which compiles native modules and needs a toolchain. Put it behind a reverse proxy with TLS: the editor uses websockets, so the proxy needs upgrade headers and a generous read timeout or terminals disconnect every few minutes. Mount the project directory and ~/.local/share/code-server so extensions and workspace state survive a container replacement. Upgrades track upstream VS Code releases closely, and extensions occasionally need reinstalling after a large jump.

Resource profile#

Memory
200 MB idle, around 900 MB in ordinary use. Node plus the extension host is a couple of hundred megabytes; the growth is entirely language servers, and a TypeScript project or a Python environment with Pyright will add several hundred more each.
CPU and acceleration
Idle until you type. Extension activation, file watching on large trees and language server indexing are the spikes; inotify limits on Linux bite before CPU does.
Storage growth
The binary and its Node runtime are around 200 to 400 MB on disk. Extensions, the `~/.local/share/code-server` state directory and whatever source you check out are what actually grow.
Operational load
2 of 5, Light. One process, one config file, no database, and upgrades are a package or tag bump that tracks upstream VS Code releases. The recurring attention goes into extension compatibility and keeping the thing behind an authenticating proxy.

Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.

Data and backup surface#

Three things matter and all are plain files. ~/.config/code-server/config.yaml holds the bind address, the password hash or plaintext, and the cert settings. ~/.local/share/code-server holds installed extensions, per-workspace state, the SQLite-backed UI state and your machine settings. Your source tree is your source tree, and you should be pushing it to a git remote rather than relying on this backup. A live file copy is fine, since nothing here is a database under load, though closing the browser tab first avoids capturing half-written workspace state. Extensions are regenerable from Open VSX and can be excluded if you keep a list, which makes the whole backup a few megabytes.

Derived backup shape

File copy. Copy the config and data directories. Safe while running for anything that writes atomically.

Traps and surprises#

Microsoft's marketplace is off limits

The VS Code Marketplace terms say the offerings are for use with Visual Studio products and services, so code-server cannot use it. The default is Open VSX. Setting EXTENSIONS_GALLERY at Microsoft's endpoint technically works and is a terms violation that has broken for people before. Check that the extensions you rely on exist on open-vsx.org before you commit to this.

Live Share and the Remote extensions do not work

The FAQ names both explicitly: Live Share and the Remote extensions (SSH, Containers, WSL) are closed source and unavailable. In practice this means you cannot nest code-server into a dev container the way local VS Code does, and pair programming needs a different tool. Dev container workflows have to be arranged outside the editor, by running code-server inside the container you want.

One password, no accounts

Authentication is a single shared password from config.yaml, and anyone who has it gets a root-capable terminal as whatever user code-server runs as. There is no multi-user mode. If more than one person needs access, run separate instances under separate users, and put an authenticating proxy in front of each rather than relying on the built-in password alone.

Websockets and proxy timeouts kill terminals

The editor keeps a persistent websocket. A reverse proxy without Upgrade and Connection headers, or with a default 60 second read timeout, produces an editor that loads fine and then drops the terminal and the file watcher every minute. Set the upgrade headers and a proxy read timeout measured in hours, and disable response buffering on that route.

inotify watch limits on large repositories

Opening a big monorepo makes the file watcher exhaust the default fs.inotify.max_user_watches, and the symptom is silent: saved files do not trigger rebuilds and the source control view stops updating. Raise the sysctl on the host, not in the container, since the limit is per user on the host kernel, and add heavy build output directories to files.watcherExclude.

Specifications#

Category
Git forges and developer infrastructure
Licence
MIT (Permissive)
Written in
TypeScript
First release
2019
Maturity
Mature
Datastore
None; state is files on disk
Default ports
8080
Ships as
docker, deb/rpm package, native binary, npm, helm chart
arm64 builds
Yes
Identity
Auth proxy only. Authentication is a single shared password in `~/.config/code-server/config.yaml`; there are no user accounts, so anything more than one person means an auth proxy in front.
Replaces
GitHub Codespaces, JetBrains Gateway, AWS Cloud9, Gitpod
Project site
coder.com/docs/code-server
Source
github.com/coder/code-server
Documentation
coder.com/docs/code-server/install

Alternatives to code-server#

Everything else in git forges and developer infrastructure, closest in operational weight first.

ToolOps loadIdle RAMLicence
Forgejo2, Light150 MBGPL-3.0-or-later
Gitea2, Light150 MBMIT
Woodpecker CI2, Light90 MBApache-2.0
GitLab CE4, Heavy4096 MBMIT
Harbor4, Heavy2500 MBApache-2.0

Where code-server comes up elsewhere#

Head to head

Sources#

Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.

  1. code-server FAQ, marketplace, extensions and telemetry
  2. code-server install guide, architectures and config path
  3. code-server releases
  4. code-server npm package, current version

Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.