Your Code Editor, Your Server, Your Rules
Coder is an open-source platform that runs VS Code – or more precisely, code-server, a browser-accessible fork of Visual Studio Code – on infrastructure you control. Instead of buying into a cloud IDE subscription or fighting with local environment inconsistencies across machines, you spin up a single server, point your browser at it, and get a full development environment from anywhere. The editor, the terminal, the extensions, the file system – all running on your hardware, behind your firewall.
The appeal is straightforward. Development environments drift. A laptop running macOS, a workstation running Ubuntu, and a colleague’s Windows machine will behave differently in subtle ways that waste hours. Coder collapses that problem by making the server the single source of truth. Your team connects to the same environment, running the same OS, the same dependencies, the same everything.
This guide walks through setting up Coder as a self-hosted VS Code environment, from installation to connecting your first workspace.
What You Need Before You Start
The minimum hardware requirement is modest: a Linux server with at least 2GB of RAM and 2 CPU cores. In practice, more RAM means faster extension loading and better performance for language servers. A VPS from any major provider works fine, as does a physical machine on your local network. The key requirement is that the server runs a supported Linux distribution – Ubuntu 20.04 or later is the path of least resistance since Coder’s documentation and community examples lean heavily on Debian-based systems.
You also need a domain name or at least a stable IP address if you plan to access the environment outside your local network. Coder runs over HTTPS in production setups, and while you can technically access it over plain HTTP on a local network, anything exposed to the internet should sit behind TLS. Caddy or Nginx work well as reverse proxies here, and Caddy in particular handles automatic certificate provisioning through Let’s Encrypt with minimal configuration. If you want to work within a broader design-to-code workflow, the environment pairs naturally with tools like those covered in the Complete Guide to Figma Dev Mode.
Docker is optional but worth installing. Coder’s newer workspace model – Coder v2, distinct from the older code-server standalone – uses Terraform templates to define workspace environments, and Docker-based workspaces are the easiest to get running quickly. If you are setting up a single-user environment and just want VS Code in a browser with minimal overhead, the standalone code-server binary is the faster path.
Installing and Configuring Coder
For the standalone code-server approach, the install is a single command. Running curl -fsSL https://code-server.dev/install.sh | sh on your server downloads and installs the latest release. After that, you start it with systemctl enable –now code-server@$USER, which creates a systemd service that runs code-server on port 8080 by default. The first launch generates a config file at ~/.config/code-server/config.yaml containing a randomly generated password and the bind address. You can edit this file to set a fixed password or change the port before restarting the service.
For Coder v2 – the full platform with workspace management – the install is still a single binary. Download the latest release from the Coder GitHub repository, make it executable, and run coder server to start the control plane. On first launch, Coder prompts you to create an admin account and configure an access URL. That access URL is what users and workspaces use to connect back to the control plane, so it needs to be reachable. For local testing, http://localhost:3000 works. For production, point a domain at your server and configure TLS through a reverse proxy or Coder’s built-in TLS support. Once the server is running, you create workspace templates using Terraform – Coder ships with starter templates for Docker, Kubernetes, and cloud providers that you can pull down and customize without writing Terraform from scratch.
Workspace configuration is where Coder’s design shows its logic most clearly. A template defines the compute resources, the base image, and any startup scripts – things like automatically cloning a repository, installing language runtimes, or configuring dotfiles. When a developer creates a new workspace from that template, they get a fully configured environment in minutes instead of spending an afternoon on setup. The coder_agent resource in the template is what establishes the connection back to the control plane and enables the browser-based VS Code session. Extensions install normally through the VS Code marketplace interface, and settings sync works the same way it does in the desktop client.
Connecting, Access, and Day-to-Day Use
Once a workspace is running, you access it through the Coder dashboard at your configured access URL. Click the VS Code button on the workspace card and the browser opens a full editor session. The interface is identical to desktop VS Code – same command palette, same keybindings, same sidebar layout. Terminals run on the server, so you are working in the actual environment rather than tunneling commands through the browser.
Coder also supports connecting from the desktop VS Code client through the Coder extension, available in the VS Code marketplace. After installing the extension and signing in with your Coder credentials, your workspaces appear in the remote connections list. You can open them in the desktop client the same way you would open a remote SSH session, which means you get native rendering and access to your local desktop extensions rather than the browser-hosted ones. For teams that prefer native clients but want centralized, reproducible environments, this hybrid approach is the standard setup.
Port forwarding is built in. If you run a local development server inside your workspace – say a Next.js app on port 3000 – Coder automatically detects it and makes it accessible through a forwarded URL. This eliminates the friction of manually tunneling ports or configuring SSH jump hosts. The Coder dashboard shows active port forwards and lets you toggle visibility between private (only the workspace owner can access) and shared (anyone with the Coder URL can access).
The one configuration detail that catches most new users is the wildcard DNS requirement for Coder v2’s port forwarding to work correctly in production. Coder generates subdomains dynamically for forwarded ports – something like 3000–myworkspace–admin.coder.example.com – and that only resolves if your DNS is configured with a wildcard record pointing *.coder.example.com at your server. Without it, port forwarding still technically works through a different mechanism, but the subdomain-based approach is cleaner and required for the shared-access feature. Set that wildcard record early and you save yourself a debugging session later when a teammate reports that your forwarded preview URL is not loading on their machine.
