Editing Code Where It Actually Runs
Here is a problem every Ops engineer has faced: a script works perfectly on your laptop but behaves differently on the server. The server has a different Python version, different library paths, different environment variables, different filesystem permissions. You end up in a cycle of editing locally, pushing to the server, running it, reading the error, editing again.
VS Code's Remote Development extensions eliminate this cycle by letting you edit files directly on the remote host, with full IDE features — autocomplete, linting, debugging — running on that host's environment.
Remote - SSH
The Remote - SSH extension (Extension ID: ms-vscode-remote.remote-ssh) connects VS Code to any host you can reach via SSH.
Connecting is a matter of pointing the extension at a host via its connection string. VS Code opens a new window, and in the background copies a small VS Code Server binary to the remote host and starts it — from that point on, opening a folder there opens the remote filesystem, not the local one.
From this point, everything you do happens on the remote host:
- The file tree shows the remote filesystem.
- The integrated terminal is a shell on the remote machine.
- Extensions run on the remote host, using its Python/Go/Node installation.
- The debugger runs on the remote host, so it can access local services (databases, APIs) that your laptop cannot reach.
SSH config integration: VS Code reads the standard ~/.ssh/config file. Any host defined there with an alias — hostname, user, and identity file already specified — appears in the "Connect to Host" dropdown automatically, with no separate VS Code-specific configuration needed.
Dev Containers
The Dev Containers extension (Extension ID: ms-vscode-remote.remote-containers) takes the remote architecture one step further: instead of connecting to a remote host, it connects to a Docker container running locally (or remotely).
You define the container in a .devcontainer/devcontainer.json file committed to your repository. When a team member opens the repo, VS Code detects this file and offers to "Reopen in Container." It builds the container, installs the specified extensions inside it, and opens the folder — all automatically. A typical configuration for ops tooling would name a Python base image, layer on Terraform and AWS CLI as features, list the extensions to install inside the container, and specify a post-create command to install project dependencies. Every developer who opens this repo gets an identical environment — same OS, same tool versions, same extensions — regardless of what is installed on their laptop.
The architectural insight here is that Dev Containers solve the "works on my machine" problem at the IDE level, not just the runtime level. It is not enough for your Docker image to have the right tools — your editor also needs to know about them. Dev Containers ensure both are consistent.