* Allow setting the VS Code build target For the NPM package (and tests, at least for now), we will still use linux-x64, but this is going to allow using the platform build targets for our standalone releases so we can avoid having to copy all the packaging steps (like cleaning up modules). This does mean that the NPM package when installed will be missing those cleanup steps. Possibly we can try to break out the packaging step into a something that can be ran standalone (which will also require installing dev dependencies like gulp) but not sure how much work this would be. * Preserve dependencies for e2e tests To avoid having to install them again. Also moved an env block to the root of the job. * Refactor releases to use VS Code packaging Instead of building the linux-x64 package, stripping the modules, then installing them again, we build the correct target and use the modules as they are. This means we do not have to copy all the post-processing steps like the ones that delete unnecessary modules. For the NPM package we still publish the linux-x64 package (without modules of course). This means npm installations do not get that same post-processing. Another advantage of this is that we can run the release immediately without having to wait for the build step, or on a commit that no longer has a build artifact, since they all build individually now. We could try sharing the core-ci build step, but leaving that alone for now. I also converted the macOS jobs into a matrix. Deleted the CI readme because it was out of date and seemed to just repeat what should be described in the scripts anyway. Removed a section about Homebrew since we do not maintain that anymore. It looks like there is no need to symlink node_modules.asar anymore. |
||
|---|---|---|
| .github | ||
| .tours | ||
| ci | ||
| docs | ||
| lib | ||
| patches | ||
| src | ||
| test | ||
| typings/httpolyglot | ||
| .dockerignore | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .node-version | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.yaml | ||
| CHANGELOG.md | ||
| eslint.config.mjs | ||
| flake.lock | ||
| flake.nix | ||
| install.sh | ||
| LICENSE | ||
| package-lock.json | ||
| package.json | ||
| renovate.json | ||
| ThirdPartyNotices.txt | ||
| tsconfig.json | ||
code-server
Run VS Code on any machine anywhere and access it in the browser.
Highlights
- Code on any device with a consistent development environment
- Use cloud servers to speed up tests, compilations, downloads, and more
- Preserve battery life when you're on the go; all intensive tasks run on your server
Requirements
See requirements for minimum specs, as well as instructions on how to set up a Google VM on which you can install code-server.
TL;DR: Linux machine with WebSockets enabled, 1 GB RAM, and 2 vCPUs
Getting started
There are five ways to get started:
- Using the install script, which automates most of the process. The script uses the system package manager if possible.
- Manually installing code-server
- Deploy code-server to your team with coder/coder
- Using our one-click buttons and guides to deploy code-server to a cloud provider ⚡
- Using the code-server feature for devcontainers, if you already use devcontainers in your project.
If you use the install script, you can preview what occurs during the install process:
curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
To install, run:
curl -fsSL https://code-server.dev/install.sh | sh
When done, the install script prints out instructions for running and starting code-server.
Note
To manage code-server for a team on your infrastructure, see: coder/coder
We also have an in-depth setup and configuration guide.
Questions?
See answers to frequently asked questions.
Want to help?
See Contributing for details.
Hiring
Interested in working at Coder? Check out our open positions!
For Teams
We develop coder/coder to help teams to adopt remote development.

