I am Lino
20 de abril de 2026

Devcontainers: cómo meter tu entorno de desarrollo en un tupper (y que siga sabiendo bien)

Publicado el 20 de abril de 2026  •  11 minutos  • 2312 palabras
Table of contents

“En mi máquina sí funciona.”

Y al portátil nuevo, a producción y a la máquina de tu compañera eso les da exactamente igual. Así empieza el ritual: “¿qué versión de Node tienes?”, “¿tenías esta lib instalada?”, “a mí los tests me pasan”.

Los devcontainers nacen justo para matar ese género de discusiones. El concepto es tan simple que casi ofende: en vez de tener un entorno de desarrollo distinto en cada portátil, te llevas el entorno dentro de un contenedor Docker.

Un fichero devcontainer.json describe todo lo que hace falta: imagen base, versiones de entornos de ejecución, herramientas, extensiones del editor, puertos… y tu IDE (VS Code, PyCharm, Rider, etc.) abre el proyecto dentro de ese contenedor .

Traducido a lenguaje humano: todo el equipo desarrolla “en la misma máquina”, aunque cada persona use el portátil que le dé la gana. Y cambiar de proyecto no es reconfigurar medio sistema: es abrir otra carpeta y que el IDE te meta en otro contenedor.

Vamos a verlo con calma:

Por qué usar devcontainers (y cuándo igual no compensa)

Imagina que en un repositorio, junto al código, tienes una especie de “receta de cocina” llamada .devcontainer/devcontainer.json . Esa receta dice:

El IDE lee eso, levanta un contenedor Docker con esas características y se mete dentro. Resultado:

¿Inconvenientes? También tiene:

Si te parece un precio razonable, a cambio ganas algo muy valioso: dejar de jugar al Tetris de “versiones en el host” y mover el lío a un sitio declarativo que vive en el repo.

VS Code: vivir dentro de un contenedor sin darte (mucha) cuenta

VS Code es, ahora mismo, el que mejor se lo ha montado con los devcontainers. La extensión “Dev Containers” es oficial, está bien documentada y, sorprendentemente, hace lo que promete.

1. Lo que necesitas antes de tocar nada

Una vez todo eso está en su sitio, viene lo entretenido.

2. Crear un devcontainer desde cero en VS Code

Supongamos que tienes una carpeta de proyecto “normal” en tu máquina y quieres convertirla en “proyecto con devcontainer”. Los pasos son pocos y bastante indoloros:

  1. Abre el proyecto en VS Code (File > Open Folder... o code . desde la terminal).
  2. Abre la Command Palette (Ctrl+Shift+P / Cmd+Shift+P) y escribe: Dev Containers: Add Dev Container Configuration Files... y pulsa Enter.
  3. VS Code te preguntará qué quieres como base. Tienes varias opciones:
    • Listado de stacks típicos: Node, Python, .NET, Java, Go, etc.
    • Imágenes preconstruidas de Microsoft: mcr.microsoft.com/devcontainers/....
    • Puedes incluso indicar que quieres partir de un Dockerfile o de un docker-compose.yml propio.

Elige, por ejemplo, “Python” si estás haciendo un backend en Django/FastAPI/Flask, o “Node” si es una API en Express. 4. VS Code creará una carpeta .devcontainer/ en tu proyecto, con al menos un fichero devcontainer.json y, a veces, un Dockerfile asociado.

Algo minimalista podría parecerse a:

{
  "name": "Mi Proyecto Python",
  "image": "mcr.microsoft.com/devcontainers/python:3.12",
  "forwardPorts": [8000],
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.black-formatter"
      ]
    }
  }
}
  1. Ahora vuelve a la Command Palette y ejecuta: Dev Containers: Reopen in Container.

VS Code hará su magia: - Construirá la imagen (si hace falta). - Creará un contenedor. - Montará tu carpeta de proyecto dentro del contenedor. - Instalará las extensiones listadas. Todo esto con una barrita de progreso que, la primera vez, te enseña cuánto café necesitas. 6. Cuando termine, estarás “dentro del contenedor”: - La terminal integrada (View > Terminal) ya no es tu host; si haces uname -a verás Linux con la info del contenedor. - python, node, java… serán los del contenedor, no los del host. - Los archivos que ves en el panel de Explorer son los de siempre, pero montados desde el contenedor.

Desde ese momento, desarrollar es igual que antes… solo que todo sucede dentro de ese entorno empaquetado que puedes reconstruir en cualquier sitio.

3. Usar los devcontainers ya existentes (repos de ejemplo, equipo, etc.)

Si clonas un repo que ya trae .devcontainer/devcontainer.json, ni siquiera tienes que crearlo tú.

  1. Abres la carpeta en VS Code.
  2. VS Code suele mostrarte una notificación tipo: “This folder contains a Dev Container configuration. Reopen in Container?”.
  3. Pulsas “Reopen in Container” y repite el proceso de build/conexión.

Si no ves la notificación, siempre puedes ir a la Command Palette y lanzar Dev Containers: Reopen in Container manualmente.

Es la forma más fácil de probarlo: busca un repo de ejemplo tipo vscode-remote-try-python de Microsoft o tu propia plantilla, ábrelo y deja que se encargue.

PyCharm y Rider: subirse al tupper ajeno

JetBrains llegó más tarde que el resto al mundo de los devcontainers, pero se ha puesto las pilas: tanto PyCharm como Rider soportan conectar con devcontainers definidos por un devcontainer.json.

La filosofía aquí es distinta: JetBrains no te genera el devcontainer (eso mejor lo haces con VS Code o a mano), pero sí sabe:

1. Requisitos previos

2. PyCharm: conectar a un devcontainer

Escenario: tienes un proyecto de Python con .devcontainer/ listo (quizá lo generaste en VS Code, quizá a mano). Quieres usar PyCharm pero ejecutar el código dentro de ese contenedor.

Pasos simplificados (según la documentación de PyCharm ):

  1. Abre PyCharm. En la pantalla de bienvenida puedes:
    • Abrir el proyecto local que ya tiene .devcontainer, o
    • Usar opciones de “Remote Development / Dev Container” si las ves.
  2. Una vez el proyecto está abierto, localiza y abre devcontainer.json en el editor de PyCharm.
  3. En el margen izquierdo del editor, PyCharm muestra un iconito asociado al archivo; al hacer clic deberías ver una opción del estilo “Create Dev Container” o “Start Dev Container inside IDE”.
  4. Al hacer clic, PyCharm usará Docker para construir y arrancar el devcontainer siguiendo la receta de devcontainer.json. Verás el progreso en la ventana de Services (la de Docker/containers).
  5. Cuando termine, tendrás un intérprete de Python basado en ese contenedor. PyCharm te permitirá elegirlo como interpreter del proyecto (igual que hace con entornos virtuales, Docker, etc.).

A partir de ahí, tus tests, tu run config, tu debugger… todo se ejecuta dentro del contenedor, pero tú sigues editando desde tu PyCharm de siempre.

3. Rider (Java, .NET): mismo concepto, menú distinto

En Rider la película es parecida, solo que orientada a proyectos Java/.NET.

Resumen de cómo lo cuenta su documentación :

  1. Abres el proyecto que ya incluye un .devcontainer/devcontainer.json.
  2. Abres el devcontainer.json en el editor.
  3. En el margen izquierdo aparece un iconito; al hacer clic, seleccionas “Create Dev Container” (o alguna variante tipo “Create Dev Container and Clone Sources”).
  4. Rellenas lo que te pida (repo, branch, etc. en caso de clonación remota) y pulsas “Build Container and Continue”.
  5. Rider se conecta al contenedor, abre el proyecto ahí y te deja trabajar como si fuera un entorno remoto Docker más.

La clave en ambos casos (PyCharm/Rider) es que no crean el devcontainer; simplemente lo usan. Por eso tiene bastante sentido generar la configuración en VS Code (o a mano) y luego reutilizarla desde los dos mundos.

Más cosas que trastear en el devcontainer.json

Sin entrar en guía exhaustiva, cuando empieces a trastear vas a ver campos que dan mucho juego:

"customizations": {
  "vscode": {
    "extensions": [
      "ms-python.python",               // soporte de Python
      "ms-python.black-formatter",       // formateador
      "charliermarsh.ruff",              // linter rápido
      "ms-azuretools.vscode-docker",     // gestión de Docker
      "eamodio.gitlens",                 // historial Git avanzado
      "esbenp.prettier-vscode"           // formateador para JS/TS/HTML
    ]
  }
}

Ojo: esto solo funciona con VS Code (y derivados como Cursor o VS Code forks). Los IDEs de JetBrains (PyCharm, Rider, IntelliJ…) ignoran el bloque customizations.vscode; para ellos el devcontainer.json define imagen, puertos y comandos, pero la configuración de plugins del IDE se gestiona desde el propio JetBrains, no desde el fichero. Visual Studio (el “grande”, no VS Code) tampoco soporta este bloque.

En JetBrains, además, hay integración específica para añadir ajustes del IDE al contenedor desde el propio Rider/PyCharm (por ejemplo, plugins), pero eso ya es capítulo dos.

Epílogo: los devcontainers y el sueño de “funciona igual en todas partes”

Los devcontainers no son una bala de plata. Sigues necesitando entender Docker un mínimo, configurar recursos con cariño (hola, WSL2 y vmmem) y asumir que la primera build de un contenedor va a tardar más que abrir el repo a pelo.

Pero a cambio te dan algo que, pasado cierto tamaño de equipo o complejidad de proyecto, vale oro:

Al final, un devcontainer es como un tupper: metes dentro todo lo que necesita tu app para vivir –dependencias, herramientas, configuración, extensiones– y lo cierras bien. Da igual dónde lo abras –Windows, macOS, Linux, VS Code, JetBrains–: sabe exactamente igual.

Que en este sector ya es casi ciencia ficción.

Glosario rápido

Si algún término te suena a nombre de banda de metal progresivo, aquí va la traducción.

Fuentes y referencias

Todo lo que vas a necesitar para ganar la discusión de “y si usamos devcontainers” en la retro.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.