Remote Development
🌐 Remote Development
ssh1) and Docker (docker1/docker2) courses. Remote Development lets VS Code's actual editing environment run somewhere other than your local machine — a remote server, a container, or a Linux subsystem — while everything still feels like a normal local window.
🏗️ The Core Idea — A Thin Client, A Remote Server
A lightweight VS Code client runs locally — the window, the UI, everything from Chapters 1-9. But a small VS Code Server component runs on the remote target — the SSH host, the container, the WSL instance. Extensions that need to interact with your code (a language server, a debugger, Chapter 4/8's tooling) run on the remote side too, so they see the real files, the real installed dependencies, and the real environment — not a local guess at what's over there.
🔑 Remote-SSH
The Remote - SSH extension connects to any machine you can already reach via plain SSH — reusing the exact same hosts, keys, and config from the site's own ssh1 course (~/.ssh/config entries appear automatically in the Remote Explorer view). Connecting opens a new window where the Explorer, terminal (Chapter 6), and debugger (Chapter 8) all operate directly on the remote machine — editing a file there feels identical to editing one locally, but the file itself never left the remote server.
📦 Dev Containers
The Dev Containers extension goes a step further: instead of connecting to a persistent server, it defines a whole disposable development environment as code, in .devcontainer/devcontainer.json:
The Command Palette's (Chapter 2) Dev Containers: Reopen in Container builds (or pulls, per the site's own docker1 course) the specified image and reopens your project running entirely inside it — every teammate who opens the same repo gets the exact same base image, tools, and even auto-installed extensions, regardless of what's actually installed on their own host machine.
🐧 WSL Integration
On Windows specifically, Remote - WSL connects to the Windows Subsystem for Linux — a real Linux environment running alongside Windows, no network or virtual machine involved. Opening a folder that lives inside the WSL filesystem gives you a genuine Linux terminal, Linux-native tooling, and Linux file permissions, all through the same familiar Windows-hosted VS Code window — useful for Linux-targeted development without dual-booting or running a full VM.
Choosing Between the Three
| Target | What it actually is | Best for |
|---|---|---|
| Remote-SSH | A real, persistent remote machine (a cloud server, a beefier desktop) | Working on hardware more powerful than your laptop, or code that must live on a specific server |
| Dev Containers | A container, defined entirely by config, disposable and rebuildable | Guaranteed-identical environments across a whole team — the most reproducible option |
| WSL | A Linux environment inside Windows itself — no network involved | Linux-native tooling on a Windows machine, with none of Remote-SSH's network dependency |
🎯 Why This Matters
Remote Development directly attacks the "works on my machine" problem — the same problem the site's docker2 capstone (productionizing a multi-container app) addresses from the deployment side. Here, the same reproducibility guarantee applies one step earlier, to development itself: a Dev Container defined once in a repo means no teammate ever debugs a bug that only exists because of their own machine's particular installed versions.
Connecting to a new SSH host for the first time triggers a host-key fingerprint prompt — the same trust-on-first-use mechanism from the site's own ssh1 course. Never blindly accept a fingerprint that unexpectedly changes for a host you've connected to before; that's a classic sign of a potential man-in-the-middle attack, not routine behavior. And remember Chapter 4's extension warning applies doubly here: a remote session runs a full VS Code Server with real permissions on that remote machine — the same evaluation discipline (trusted extensions, verified hosts) matters even more once a remote system, not just your local one, is on the line.
VS Code Server
Runs on the remote target; extensions and tooling execute there, not locally.
Remote-SSH
Connects to any real machine reachable via SSH, reusing ssh1's config and keys.
Dev Containers
devcontainer.json defines a reproducible, disposable environment as code.
WSL
A real Linux environment inside Windows — no network, no VM.
💻 Coding Challenges
Exercise 1: Explore the Remote Explorer
Install the "Remote Development" extension pack, open the Remote Explorer view, and check its SSH Targets tab. If you have an existing ~/.ssh/config from the site's ssh1 course, note whether its hosts already appear here automatically.
Exercise 2: Write a devcontainer.json
For any small project, write a .devcontainer/devcontainer.json specifying a base image appropriate to that project's language, plus at least one recommended extension. If Docker is installed, use "Dev Containers: Reopen in Container" to actually try it.
Exercise 3: Match the Scenario to the Right Tool
For each of these three scenarios, decide which remote option (Remote-SSH, Dev Containers, or WSL) fits best, and explain why: (a) a five-person team needs identical environments regardless of each member's own OS, (b) a data scientist needs a specific GPU physically installed in a lab server, (c) a Windows user wants to run Linux-only build tools without a VM.
🎓 Course Complete!
That's all 10 chapters of VS Code Essentials — the interface, keyboard-first navigation, efficient editing, extensions, workspaces and settings, the terminal and tasks, git integration, debugging, snippets and keybindings, and remote development. Everything from here builds naturally on the language- and tool-specific courses already on the site — the editor is now yours to actually work in.