Infraestructura de desarrollo remota con Docker y VS Code: la guía completa 2026

Mi laptop murió un martes a las 11 AM. 4 horas después estaba programando desde una laptop de repuesto con el mismo VS Code, mismas extensiones, mismas conexiones SSH, mismas configuraciones. No perdí ni media hora de trabajo. La diferencia fue que mi entorno de desarrollo estaba en un contenedor Docker corriendo en un VPS accesible vía VS Code Remote — SSH — Containers.

Trabajar en un entorno de desarrollo reproducible y accesible desde cualquier máquina es la diferencia entre un setup que escala y uno que se rompe el día que cambias de laptop. Esta guía cubre las cinco formas reales de hacerlo en 2026 con VS Code y Docker: devcontainer simple, Codespaces (si aceptas la nube), Gitpod, el patrón Remote SSH + contenedor, y la opción auto-hospedada con Coder. Con tradeoffs reales de cada uno.

---

Trabajar en un entorno de desarrollo reproducible y accesible desde cualquier máquina es la diferencia entre un setup que escala y uno que se rompe el día que cambias de laptop. Esta guía cubre las cinco formas reales de hacerlo en 2026 con VS Code y Docker, con sus tradeoffs y comandos verificados. Nada de marketing: lo que funciona y lo que da fricción.

Por qué necesitas una infraestructura remota

Un setup de desarrollo local (laptop con todo instalado) tiene tres problemas recurrentes:

• Tu laptop se rompe, pierdes días reinstalando todo. Si tu setup vive en un contenedor y un volumen, levantas el mismo entorno en otra máquina en 10 minutos.
• Cada dev tiene una config distinta (“en mi máquina funciona”). Con Docker defines el entorno una vez y todos trabajan igual.
• El setup crece sin control. Una laptop con 14 herramientas distintas, versiones contradictorias, dotfiles a medias. Un contenedor con Dockerfile y devcontainer.json es auditable.

Hay dos públicos para esta guía:

• Dev solo que quiere orden: laptop liviana, servidor o NAS en casa con el código, todo lo corre en remoto.
• Equipos de 2-10 personas que quieren un entorno común sin pagar GitHub Codespaces o JetBrains Gateway.

Las cinco arquitecturas que cubrimos, de más simple a más pro:

1. Extensión Dev Containers (antes Remote-Containers) de VS Code contra un contenedor local. 2. Remote-SSH de VS Code contra un servidor Linux con Docker. 3. VS Code Tunnels para acceder sin configurar SSH ni abrir puertos. 4. Coder autoalojado (la versión open source seria de Codespaces). 5. GitHub Codespaces (SaaS) para no mantener nada.

Lo que necesitas antes de empezar

Da igual qué arquitectura elijas, los prerequisitos son siempre los mismos:

• Docker Engine 24+ en la máquina donde corre el código. Verifica con docker --version y docker info (este último falla si el daemon no corre o tu usuario no está en el grupo docker).
• VS Code 1.85+ en la máquina cliente. Descarga desde code.visualstudio.com.
• Extensión correcta instalada según la arquitectura (ver más abajo).
• Una carpeta con tu proyecto con al menos un Dockerfile o un .devcontainer/devcontainer.json.

Si quieres evitar el sudo docker cada dos minutos:

sudo usermod -aG docker $USER
newgrp docker
docker run hello-world

Si hello-world no corre, el daemon no está activo. En servidores con systemd: sudo systemctl enable --now docker.

Arquitectura 1: Dev Containers contra un contenedor local

Es el caso más simple. Tu laptop tiene Docker, abres VS Code, le dices “ábrelo dentro de un contenedor” y todo el IDE corre dentro. La extensión se llama Dev Containers (Microsoft la renombró; antes era “Remote – Containers”).

Instalación

1. Instala la extensión “Dev Containers” (ms-vscode-remote.remote-containers) desde el marketplace de VS Code. 2. En tu proyecto, crea la carpeta .devcontainer/ con dos archivos:

.devcontainer/
├── devcontainer.json
└── Dockerfile

Dockerfile mínimo para un proyecto Python

FROM mcr.microsoft.com/devcontainers/python:3.12
# Evita prompts interactivos
ENV DEBIAN_FRONTEND=noninteractive
# Instala herramientas extra
RUN apt-get update && apt-get install -y 
    git curl jq ripgrep 
    && rm -rf /var/lib/apt/lists/*
# Usuario no root (recomendado)
ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=1000
RUN groupadd --gid $USER_GID $USERNAME 
    && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME 
    && apt-get install -y sudo 
    && echo $USERNAME ALL=(root) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME
USER $USERNAME
WORKDIR /home/vscode/workspace

devcontainer.json que conecta el Dockerfile

{
  "name": "Mi proyecto Python",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "features": {
    "ghcr.io/devcontainers/features/python:1": {
      "version": "3.12"
    },
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "charliermarsh.ruff"
      ],
      "settings": {
        "python.defaultInterpreterPath": "/usr/local/bin/python"
      }
    }
  },
  "forwardPorts": [8000, 5173],
  "postCreateCommand": "pip install -r requirements.txt",
  "remoteUser": "vscode"
}

Uso

1. Abre la carpeta en VS Code. 2. Pulsa Ctrl+Shift+P → “Dev Containers: Reopen in Container”. 3. Primera vez tarda 2-5 minutos (descarga imagen). Después es instantáneo si no cambias el devcontainer.json. 4. Todo el IDE ahora corre DENTRO del contenedor. Terminal, debugger, extensions, todo.

Persistencia y rendimiento

El código se monta por bind mount dentro del contenedor, así que editar un archivo en VS Code se refleja inmediatamente en el host. La extensión instala VS Code Server dentro del contenedor, así que el código JS/TypeScript de las extensiones corre adentro (más rápido en proyectos grandes).

Para evitar que cada cambio de package.json o requirements.txt reinstale todo desde cero, usa volúmenes named para caches:

"mounts": [
  "source=node_modules,target=/workspace/node_modules,type=volume",
  "source=cache-pip,target=/home/vscode/.cache/pip,type=volume"
]

El devcontainer.json es lo único que versionas en Git. La imagen se reconstruye solo cuando cambian los archivos de .devcontainer/. El día que un dev nuevo clone el repo, abrir VS Code y hacer “Reopen in Container” le da el mismo entorno que tienes tú.

Arquitectura 2: Remote-SSH contra un servidor Linux

Acá la laptop solo es un cliente “tonto”. El código, las herramientas, los builds, todo corre en un servidor Linux (un VPS, un NAS, una workstation en la oficina). VS Code se conecta por SSH y abre una ventana remota.

Cuándo tiene sentido

• Tu laptop es vieja o liviana (Chromebook, MacBook Air, ThinkPad X1).
• trabajas con datasets grandes que no caben en la laptop.
• quieres que el código corra en la misma red que la base de datos / los servicios internos.
• Tu equipo de diseño/dev tiene workstations Windows/Mac pero el deploy es Linux.

Setup del servidor

Asumimos Debian 12 o Ubuntu 24.04 en el servidor. Lo crítico:

# 1. Instalar Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
# 2. Instalar las herramientas que vas a usar
sudo apt update && sudo apt install -y 
    build-essential git curl wget jq ripgrep fd-find 
    python3 python3-pip python3-venv 
    nodejs npm
# 3. Verificar SSH
sudo systemctl enable --now ssh

El usuario necesita poder correr Docker sin sudo (ya hecho arriba). Si la conexión SSH va lenta, agregar al ~/.ssh/config del cliente:

Host mi-servidor
    HostName 192.168.1.50
    User dev
    Compression yes
    ServerAliveInterval 30

Setup de VS Code en la laptop

1. Instala la extensión “Remote – SSH” (ms-vscode-remote.remote-ssh). 2. Abre la paleta (Ctrl+Shift+P) → “Remote-SSH: Connect to Host” → “mi-servidor”. 3. Primera vez, VS Code sube su binario a ~/.vscode-server/ en el servidor. Después es instantáneo. 4. Una vez conectado, todo el file panel, terminal, extensions son remotos.

Para que el proyecto abra directamente dentro de un contenedor en el servidor (combinando arquitecturas 1+2):

{
  "name": "Mi proyecto",
  "build": {
    "dockerfile": "Dockerfile",
    "context": ".."
  },
  "workspaceFolder": "/workspace",
  "shutdownAction": "stopContainer"
}

VS Code hace SSH al servidor, levanta el contenedor ahí, y tú ves la ventana como si fuera local. La diferencia: el código vive en el servidor, no en tu laptop.

SSH por clave, no por password

# En la laptop
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id dev@mi-servidor

Si el servidor está expuesto a internet, no uses password. Cambiá PasswordAuthentication no en /etc/ssh/sshd_config del servidor. Para acceder desde fuera de tu LAN, mejor Tailscale o un reverse proxy con autenticación.

Arquitectura 3: VS Code Tunnels (sin abrir puertos)

VS Code Tunnels (antes “VS Code Remote Tunnels”) es la opción moderna para acceder a una máquina sin configurar SSH ni abrir puertos. Microsoft corre el relay, tú solo necesitas una cuenta de GitHub o Microsoft.

Cómo funciona

• La máquina “server” corre code tunnel y se registra con tu cuenta.
• Tu laptop abre VS Code → “Remote: Connect to Tunnel” → aparece la lista de tus máquinas.
• VS Code establece una conexión WebSocket outbound al relay de Microsoft. No hay puertos abiertos.
• El relay enruta la conexión a tu laptop con cifrado E2E.

Setup

En el servidor (la máquina donde corre el código):

# Instalar VS Code CLI
curl -L "https://code.visualstudio.com/sha/download?build=stable&os=linux-deb-x64" -o vscode.deb
sudo apt install ./vscode.deb
# O más simple: usar el binario standalone
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/packages.microsoft.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/packages.microsoft.gpg] https://packages.microsoft.com/repos/code stable main" | sudo tee /etc/apt/sources.list.d/vscode.list
sudo apt update && sudo apt install code
# Iniciar el tunnel
code tunnel

Te va a pedir autenticarte con GitHub. Después te da un nombre para el tunnel (ej. mi-servidor).

Para que sobreviva al reinicio, como servicio systemd:

# ~/.config/systemd/user/code-tunnel.service
[Unit]
Description=VS Code Tunnel
After=network.target
[Service]
ExecStart=/usr/bin/code tunnel --name mi-servidor --accept-server-license-terms
Restart=always
RestartSec=10
[Install]
WantedBy=default.target

systemctl --user enable --now code-tunnel
loginctl enable-linger $USER  # para que sobreviva al logout

En tu laptop:

1. VS Code → paleta → “Remote: Connect to Tunnel” → seleccionar mi-servidor. 2. Se abre una ventana remota con la misma experiencia que SSH.

Limitaciones de Tunnels:

• Requiere internet (no funciona offline).
• El código pasa por infraestructura de Microsoft (cifrado, pero si te importa la soberanía, no es para ti).
• El relay tiene límites de bandwidth. Para editar 50 archivos pequeños OK, para git clone de 5 GB molesto.

Arquitectura 4: Coder (autoalojado, “tu propio Codespaces”)

Coder es la opción seria cuando tienes un equipo de devs y quieres dar a cada uno un entorno de desarrollo completo (workspace) en la nube, parecido a GitHub Codespaces pero autoalojado y open source.

Qué resuelve

• Cada dev tiene su propio workspace corriendo en Kubernetes o Docker.
• El dev abre el VS Code de su laptop y se conecta a su workspace. Todo corre en el servidor, nada en la laptop.
• Workspaces se crean desde un template (imagen Docker con todo preinstalado).
• El dev puede tener 5-10 workspaces (uno por feature/task), con persistencia.

Setup mínimo con Docker

En un servidor con al menos 8 GB RAM y 50 GB libres:

# Crear directorio de datos
sudo mkdir -p /var/lib/coder
sudo chown -R $USER:$USER /var/lib/coder
# Levantar con Docker
docker run -d 
  --name coder 
  --restart always 
  -p 7080:7080 
  -v /var/run/docker.sock:/var/run/docker.sock 
  -v /var/lib/coder:/var/lib/coder 
  ghcr.io/coder/coder:latest

abres http://tu-servidor:7080, creas el primer admin, y ya está. Después:

1. Crear un template. Coder trae templates de ejemplo (Node, Python, Go). Copiá uno, ajustá el Dockerfile si hace falta. 2. Crear un workspace desde ese template. Tarda 1-3 minutos en provisionar. 3. Conectar VS Code. Coder genera una URL vscode:// que abre el editor con la conexión ya hecha.

Reverse proxy con HTTPS

Nunca expongas Coder en HTTP plano. Con Caddy:

coder.tu-dominio.com {
    reverse_proxy localhost:7080
}

O con Nginx + certbot si ya tienes Nginx andando. Coder soporta OIDC (Google, GitHub, GitLab) para SSO.

Cuándo Coder y cuándo Dev Containers solos

• 1-3 devs, proyectos chicos: Dev Containers locales alcanza.
• 3-15 devs, múltiples proyectos, recursos caros: Coder vale la pena.
• 15+ devs, Kubernetes: Coder sobre k8s, ya con alta disponibilidad.

Coder consume recursos. Cada workspace activo reserva CPU/RAM. Empezá con templates de 1 vCPU / 2 GB y ajustá según uso real.

Arquitectura 5: GitHub Codespaces (SaaS)

Si no quieres mantener nada, GitHub Codespaces es la opción obvia. Cuesta:

• Free: 120 horas/mes para repos públicos, 15 horas para privados (2 cores).
• Pro ($4 usuario/mes): 180 horas/mes.
• Team/Enterprise: planes con más horas, máquinas más grandes, auditoría.

Cuándo tiene sentido

• Equipo que ya está en GitHub y no quiere operar infra.
• Picos de uso (alguien se fue de viaje, necesita una máquina potente por una semana).
• Estudiantes o freelancers que no quieren configurar nada.

Setup

1. En tu repo, agregar .devcontainer/devcontainer.json. Codespaces lo detecta automáticamente. 2. Botón “Code” → “Codespaces” → “Create codespace on main”. 3. VS Code se abre en el navegador (o conecta con VS Code desktop si tienes la extensión). 4. Cuando termines, el codespace se apaga. Tus cambios están en una branch.

Persistencia

Codespaces separa “infraestructura” (la VM) de “persistencia” (los archivos del workspace). Al apagar el codespace, los archivos se mantienen hasta 30 días. Si quieres mantener cambios, hace commit o push a una branch.

Limitaciones

• Las horas se acaban rápido en máquinas grandes (8 cores = 4x consumo).
• No puedes correr Docker dentro del codespace sin DinD (Docker in Docker), que es lento y frágil.
• Latencia desde Sudamérica a us-east puede ser 150-200ms. Si tipeás rápido, se nota.

Tabla comparativa

Arquitectura	Costo infra	Costo operacional	Setup inicial	Mejor para
Dev Containers local	$0	Bajo	30 min	Dev solo, laptop con Docker
Remote-SSH	$5-30/mes (VPS)	Bajo	1-2 horas	Laptop liviana, datasets grandes
VS Code Tunnels	$0 + tu máquina	Muy bajo	15 min	Acceso ad-hoc, sin abrir puertos
Coder	$50-200/mes (server)	Medio	2-4 horas	Equipos 3-15 devs
GitHub Codespaces	$0-4 user/mes + uso	Cero	15 min	No querer operar nada

Patrones comunes que sí funcionan

Configurar SSH agent forwarding

Cuando hacés SSH al servidor y desde ahí quieres hacer git push a GitHub, el agente tiene que llegar con tu clave:

# ~/.ssh/config en la laptop
Host mi-servidor
    ForwardAgent yes

En la laptop, ssh-add ~/.ssh/id_ed25519 antes de conectar. En el servidor, echo $SSH_AUTH_SOCK debería devolver un socket. git push desde el server usa tu clave de la laptop sin tener que copiarla.

Persistir dotfiles

Si quieres que cada dev nuevo arranque con tu .bashrc, .gitconfig, etc.:

// En devcontainer.json
"dotfilesRepository": "tu-usuario/dotfiles",
"dotfilesInstallCommand": "install.sh"

El repo dotfiles debe tener un install.sh ejecutable que copie los archivos a su destino. Funciona con cualquier gestor (chezmoi, dotbot, o scripts a mano).

Reconstruir solo cuando cambia el devcontainer

VS Code detecta cambios en .devcontainer/devcontainer.json o Dockerfile y rebuilda automáticamente. Si solo cambian archivos de código, el contenedor se reutiliza. Para forzar rebuild sin cache:

Ctrl+Shift+P → “Dev Containers: Rebuild Container”.

Compartir el entorno con el equipo

Versioná el .devcontainer/ en Git. Un dev nuevo hace git clone, abre en VS Code, “Reopen in Container” y tiene exactamente tu entorno. No hay “pero en mi máquina andaba”. El Dockerfile y el devcontainer.json son documentación ejecutable.

Troubleshooting: los problemas que vas a tener

“Cannot connect to the Docker daemon”

# Verificar
sudo systemctl status docker
sudo systemctl start docker
# Si tu usuario no está en el grupo
sudo usermod -aG docker $USER
# Relogin o:
newgrp docker

“Permission denied” dentro del contenedor

El contenedor corre como root o como un usuario sin acceso al volumen montado. Solución estándar: usar el usuario no-root del devcontainer (remoteUser: "vscode") y bind mount con permisos compatibles con el UID del host.

“Out of disk space” en el host

Docker se come disco rápido. Limpieza periódica:

docker system prune -a --volumes  # cuidado: borra TODO lo no usado
docker builder prune -a            # limpia cache de builds

Automatiza con un cron mensual.

“VS Code se desconecta cuando cambio de red”

Es el problema clásico de Remote-SSH. Soluciones:

• ServerAliveInterval 30 y ServerAliveCountMax 4 en ~/.ssh/config.
• Usar mosh (solo para sesiones interactivas de terminal; VS Code Remote no usa mosh, sigue dependiendo de SSH para subir su server y mantener port-forwarding).
• Túneles si la reconexión manual te molesta.

“El contenedor tarda 5 minutos en arrancar cada vez”

Imagen demasiado grande. Optimizá el Dockerfile:

# Usar imagenes específicas, no latest
FROM mcr.microsoft.com/devcontainers/python:3.12-bookworm
# Combinar comandos RUN
RUN apt-get update && apt-get install -y 
    git curl jq 
    && rm -rf /var/lib/apt/lists/*
# Multi-stage si tienes build pesado
FROM builder AS runtime
COPY --from=builder /app /app

Las imágenes oficiales de Microsoft ya vienen optimizadas, pero si agregás muchas cosas, el cache de capas puede invalidarse y reconstruir todo. Cada COPY de código fuente sin .dockerignore rompe el cache.

“Las extensiones no aparecen dentro del contenedor”

VS Code distingue entre extensiones del cliente (UI local) y del servidor (corren dentro del contenedor). Las que importan son las del servidor. Definilas en devcontainer.json:

"customizations": {
  "vscode": {
    "extensions": ["ms-python.python", "rust-lang.rust-analyzer"]
  }
}

Seguridad: lo mínimo que tienes que configurar

• SSH por clave, no password. Si usas Remote-SSH o Coder.
• HTTPS con cert válido si exponés algo a internet (Caddy + Let’s Encrypt automático).
• No correr como root dentro del contenedor. El devcontainer con remoteUser: "vscode" ya lo hace.
• No bindear el socket de Docker al contenedor. Es un escalado de privilegios silencioso. Solo en Coder cuando sabes lo que hacés.
• Actualizar la imagen base cada 2-3 meses. Las imágenes de devcontainers reciben parches de seguridad de las distros base.
• Si usas Coder en una organización: configurar OIDC + auditoría + límites de recursos por usuario. Sin eso, un dev puede pedir 16 cores y tumbar el cluster.

Conclusión

La “mejor” arquitectura depende de tu contexto. Para empezar, Dev Containers locales es lo más rápido de adoptar y lo que menos infra pide. Cuando el setup crezca, Remote-SSH te da potencia sin complejidad. Si quieres experiencia “todo en la nube” sin mantener nada, Codespaces. Si tienes un equipo serio y quieres soberanía, Coder autoalojado. Y VS Code Tunnels es la navaja suiza para casos ad-hoc.

Mi recomendación concreta para ti que estás leyendo esto: empezá con Dev Containers. Versioná tu .devcontainer/ desde el día uno. Cuando tu setup esté maduro y otro dev se sume al proyecto, esa carpeta es lo único que necesita para tener exactamente tu entorno.

FAQ

¿Dev Containers funciona en Mac con Apple Silicon? Sí, VS Code y Docker Desktop lo soportan nativamente. Las imágenes multi-arch (linux/amd64,linux/arm64) funcionan sin cambios. Si usas una imagen solo x86, Docker emula con Rosetta y es más lento.

¿Remote-SSH es seguro para producción? Sí, SSH es el estándar. Lo crítico es la autenticación (clave, no password) y mantener el server actualizado. Si exponés SSH a internet, fail2ban o un puerto no estándar ayuda.

¿Coder consume mucha RAM? Depende del template. Un workspace típico 2-4 GB. Con 10 devs activos simultáneos, mínimo 32 GB en el server. Empezá con pocos y medí.

¿Se puede usar VS Code Tunnels con un dominio propio? No directamente, el relay es de Microsoft. Si necesitas tu propio relay, mira code-server (Coder también lo ofrece) o un reverse proxy tradicional.

¿Qué pasa con los secrets del proyecto (API keys, DB passwords)? En local: .env con .gitignore. En Dev Containers: variable de entorno o mount de archivo. En Coder: su sistema de secrets integrado con Vault. En Codespaces: secrets del repo en GitHub. Nunca hardcodear.

¿Vale la pena pagar Codespaces si soy freelance? Si tus proyectos son cortos y aislados, sí. 15-60 horas al mes se gasta rápido. Si el proyecto dura 6 meses con trabajo diario, autoalojar con Coder en un Hetzner de 30 EUR/mes es más barato.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux