VS Code for Remote and Container Development

By Kokil Thapa | Last reviewed: September 2026

Your Laravel app runs on PHP 8.5 inside Docker, but your editor still points at a host folder with the wrong extensions. That mismatch is exactly why teams adopt VS Code for Remote and Container Development. Visual Studio Code can attach to a Linux server over SSH or open your repo inside a container so the editor, terminal, debugger, and linter all share one runtime. If you maintain production systems from Kathmandu or collaborate with clients abroad, this workflow cuts the "works on my machine" loop before it reaches Linux server administration tickets.

What is VS Code for Remote and Container Development?

Standard VS Code opens files on your laptop and runs tools through your local shell. Remote development splits that model. A lightweight VS Code Server process runs on the remote machine or inside the container. Your desktop app becomes a thin client that sends edits and receives diagnostics over a secure channel.

Three official extensions cover most real-world cases:

• Remote - SSH — edit files on a VPS, staging server, or EC2 instance as if they were local.
• Dev Containers — open a folder inside a Docker container defined by devcontainer.json.
• WSL — develop inside Windows Subsystem for Linux when your stack targets Linux but your laptop runs Windows.

On client projects I often pair Dev Containers with the patterns in our reproducible dev environments guide. The goal is simple: one command reproduces PHP, Composer, Node.js 26 LTS, and database services for every developer.

How do you set up VS Code Remote SSH for a Linux server?

Remote SSH is the fastest path when you already have an Ubuntu 22 or 24 VPS. You edit directly on staging without rsync scripts or SFTP plugins. Microsoft documents the flow in the official Remote SSH guide.

Install the extension and configure your host

Install Remote - SSH from the VS Code marketplace. Add a host entry to ~/.ssh/config on your laptop:

Host staging-law-portal
    HostName 203.0.113.44
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent yes

Open the Command Palette and run Remote-SSH: Connect to Host. Pick staging-law-portal. VS Code installs its server binary under ~/.vscode-server/ on first connect. Subsequent sessions start in seconds.

Open your project and install server-side extensions

After connection, use File → Open Folder and select /var/www/current or your Deployer release path. Some extensions must run on the remote side. Install PHP Intelephense, Laravel Blade formatter, and ESLint in the remote context—not only on your laptop—or autocomplete will silently fail.

For teams maintaining sister sites on shared EC2 infrastructure, Remote SSH mirrors how I troubleshoot production Laravel apps after deploy. You get a real shell, real logs, and real file permissions without leaving the editor. That pairs naturally with ongoing support and maintenance workflows.

1. Confirm SSH key auth works outside VS Code with ssh staging-law-portal.
2. Connect through Remote SSH and trust the host fingerprint once.
3. Open the project root, not a nested subfolder, so Git and Composer resolve correctly.
4. Install language extensions in the remote window—check the badge that says "Install in SSH".
5. Pin the remote PHP path in settings if multiple versions coexist on the server.

How do Dev Containers work in VS Code?

Dev Containers open your repository inside a Docker container built from a declarative config. The Dev Containers specification standardises that file so the same setup works in VS Code, GitHub Codespaces, and other compatible tools.

A minimal Laravel 13 project might ship this .devcontainer/devcontainer.json:

{
  "name": "Laravel Dev",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/var/www/html",
  "customizations": {
    "vscode": {
      "extensions": [
        "bmewburn.vscode-intelephense-client",
        "onecentlin.laravel-blade",
        "dbaeumer.vscode-eslint"
      ]
    }
  },
  "forwardPorts": [8000, 3306, 6379],
  "postCreateCommand": "composer install && npm install"
}

Pair it with a compose file that mounts your repo and runs PHP 8.3 or 8.5 plus MySQL 9.7. See our Docker Compose multi-container guide for service wiring patterns that transfer directly into Dev Container compose files.

Rebuild versus reopen

Dev Containers: Reopen in Container attaches to an existing image. Rebuild Container re-runs Dockerfile steps when you change base packages. A common mistake is editing Dockerfile but only reopening—then wondering why the Xdebug extension never appeared. Rebuild after any Dockerfile or apt-get change.

What is the difference between Remote SSH, Dev Containers, and WSL?

All three fall under VS Code for Remote and Container Development, but they solve different problems. Pick the wrong one and you will fight permissions, slow file sync, or missing services.

My default recommendation for new Laravel 13 work: Dev Containers locally, Remote SSH for debugging deployed releases. WSL fills the gap when a developer refuses to dual-boot or buy a Mac but still needs Linux paths for Composer and Artisan.

If you are comparing build-vs-buy decisions for Nepali startups, remote editor workflows reduce onboarding friction the same way documented environments reduce hiring risk—similar trade-offs appear in our no-code versus custom development analysis.

How do you run and debug Laravel inside a Dev Container?

Laravel 13 requires PHP 8.3 or higher. Laravel 12 runs on PHP 8.2. Your container must match before Intelephense and PHPUnit agree on types. On booking systems like Adventure Third Pole Trek, Livewire, queues, and Vite 8.x builds all expect consistent Node and PHP versions across machines.

Port forwarding and the dev server

Run php artisan serve --host=0.0.0.0 --port=8000 inside the integrated terminal. VS Code auto-forwards port 8000 when listed in forwardPorts. Browse http://localhost:8000 on your host browser. Without 0.0.0.0, the server binds to localhost inside the container and the forward silently fails.

Xdebug configuration

Install Xdebug in the container image, not on the host. A typical docker/php/xdebug.ini snippet:

xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003

Add a VS Code launch configuration in .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html": "${workspaceFolder}"
      }
    }
  ]
}

Start listening, set a breakpoint in a controller, and hit the route. If breakpoints stay hollow, verify pathMappings first. Wrong mappings are the top Laravel debugging failure in container setups. Our debug a running container article covers parallel techniques with plain Docker CLI when VS Code is not attached.

Database and Redis sidecars

Reference a MySQL or PostgreSQL 18 service in the same compose network. Use the service name as hostname—DB_HOST=mysql, not 127.0.0.1. For PostgreSQL-specific local setups, see run PostgreSQL in Docker for development. Redis 8.10 for cache and queues follows the same pattern.

What are common mistakes with VS Code remote and container workflows?

Most failures I see are environmental, not editor bugs. Treat this list as a pre-flight check before blaming Laravel or Docker.

Extension split-brain

ESLint running locally while TypeScript resolves inside the container produces phantom errors. Open the Extensions panel and install into the remote or container context. The UI shows where each extension runs.

Bind-mount performance on macOS and Windows

Heavy vendor/ and node_modules/ directories on Docker Desktop bind mounts are slow. Use a named volume or copy-on-write strategy for dependencies. On Linux natively, bind mounts are usually fine. For large WooCommerce or Magento trees, expect noticeable lag until you optimise mount targets.

Committing secrets through .devcontainer

Never bake API keys into devcontainer.json or Dockerfile layers. Use remoteEnv referencing a local .env that stays gitignored. Scan images in CI—the practices in container image scanning with Trivy apply to dev images too.

Editing production directly over SSH

Remote SSH makes production edits temptingly easy. Do not do it. Use SSH for read-only debugging or for staging mirrors. Production changes flow through Git and Deployer 7 symlink releases—the same pipeline I use on legal-tech sister sites sharing GitLab CI.

Ignoring resource limits

A Dev Container compose stack with MySQL, Redis, Meilisearch, and Mailpit can consume 4 GB RAM quickly on an 8 GB laptop. Cap services during daily dev. Our limit Docker container resources post shows compose limits that keep VS Code responsive.

How does remote VS Code fit Nepal freelance and agency workflows?

Developers in Kathmandu often work on client VPS instances abroad while running local ISP connections with occasional drops. Remote SSH reconnects automatically when the tunnel returns. Dev Containers let you keep working offline on a plane once images are built.

Freelancers billing in NPR or USD benefit when onboarding a subcontractor takes one Git clone plus Reopen in Container instead of a two-page PHP extension checklist. That aligns with remote collaboration patterns described in our remote freelance developer in Nepal guide.

For API-heavy products, the same container can expose Postman collections and run PHPUnit beside your editor. Deeper API design notes live in API development services and the API-first development workflow article. Validate JSON payloads with the site JSON formatter tool when debugging webhook fixtures outside the IDE.

When scoping custom software projects, I document the Dev Container setup in the repo README. Clients inherit a reproducible environment that survives developer turnover—a practical form of infrastructure as code for application runtimes, not just Terraform modules.

Key Takeaways

• Install Remote SSH, Dev Containers, or WSL based on whether you target a remote server, Docker, or local WSL—not all three at once for the same repo.
• Always install PHP, ESLint, and Laravel extensions in the remote or container context so diagnostics match the runtime binary.
• Commit .devcontainer/devcontainer.json and pin PHP 8.3+, Node 26 LTS, and database versions to align with CI and production.
• Use Remote SSH for staging debugging; use Dev Containers for daily feature work—never edit production directly through SSH.
• Rebuild the container after Dockerfile changes, forward ports explicitly, and fix Xdebug pathMappings before chasing application bugs.
• Pair containerised dev with image scanning and resource limits so local Docker stays fast and safe.

People Also Ask

Do you need Docker Desktop for VS Code Dev Containers?

On Windows and macOS, Docker Desktop is the common choice. On Linux you can use Docker Engine directly without Desktop. VS Code talks to the Docker socket either way. Ensure Docker is running before you select Reopen in Container, or the command fails immediately with a socket connection error.

Can you use VS Code Dev Containers without internet?

After the initial image pull and VS Code Server download, most work continues offline. First-time extension installs and Composer/npm downloads still need network access inside the container. Pre-build images in CI and push to a private registry if your team has restricted connectivity.

Is VS Code Remote SSH safe for production servers?

SSH itself is safe when you use key auth, disable password login, and restrict users. The risk is human: editing live files instead of deploying through Git. Treat Remote SSH as a debugging viewport, not a deployment channel. Read logs, inspect configs, run read-only Artisan commands—then patch locally and deploy through your pipeline.

How is GitHub Codespaces related to Dev Containers?

Codespaces runs the same Dev Containers specification in the cloud. Your devcontainer.json often works in both VS Code locally and Codespaces with minimal changes. Teams that outgrow laptop RAM sometimes shift heavy builds to Codespaces while keeping identical config—see the GitHub Codespaces documentation for pricing and limits.

Ship consistent environments with VS Code remote workflows

VS Code for Remote and Container Development turns environment setup from a tribal checklist into a versioned file in your repo. Whether you are building a legal-tech portal, a Laravel booking system, or a WooCommerce storefront, the editor should run where your code runs. Start with a Dev Container for local work, add Remote SSH for staging parity, and keep production changes in Git—not in a live SSH buffer.

If you want help standardising Laravel 13 or legacy PHP 8.2 upgrade paths across your team, review our Laravel development guide or browse the Court Marriage In Nepal portfolio case. Need a full-stack partner to set up CI, containers, and deployment on Ubuntu? Contact us to discuss your project—or explore web development services for a scoped engagement.