Coder: entornos de desarrollo remotos con devcontainers para todo el equipo
El portátil de cada uno es el último sitio sin versionar de todo el proceso. Versionas el código, la infraestructura, los despliegues y hasta el entorno de ejecución en contenedores; y luego el entorno donde se escribe ese código es una máquina distinta por persona, con su versión de Node, sus credenciales sueltas y su «a mí me funciona».
Coder ataca justo eso: los entornos de desarrollo dejan de vivir en los portátiles y pasan a ser recursos que se declaran, se despliegan y se apagan como cualquier otro. Lo tuvimos montado sobre nuestra propia infraestructura durante unos meses.
Qué hace, en concreto
Antes de entrar en lo nuestro conviene desglosarlo, porque «entornos de desarrollo remotos» se queda corto y la mitad de lo interesante está en los detalles.
| Capacidad | Qué significa en la práctica |
|---|---|
| Plantillas como código | El entorno se declara en Terraform: qué imagen, cuánta CPU y memoria, qué volúmenes persisten. Quien administra decide la forma; nadie improvisa la suya |
| Sustrato a elegir | Los espacios de trabajo pueden ser pods de Kubernetes, contenedores Docker o máquinas virtuales, según dónde tengas capacidad |
| Tu editor de siempre | Se conecta desde VS Code o JetBrains locales, por SSH o desde el navegador. No obliga a cambiar de herramienta |
| Aplicaciones por subdominio | Lo que levantes dentro —una web, una API, un panel— sale por su propia dirección, sin túneles a mano |
| Ciclo de vida | Arranque bajo demanda y apagado por inactividad, con lo que un entorno parado no consume |
| Acceso centralizado | Quién tiene entorno, con qué plantilla y con qué recursos se decide en un sitio, y se revoca en un sitio |
El resumen es que separa dos cosas que en un portátil van pegadas: dónde se ejecuta el trabajo y desde dónde se escribe. El primero pasa a ser infraestructura declarada; el segundo sigue siendo tu máquina y tu editor.
Nuestro caso: devcontainers para varios programadores
Lo montamos para centralizar el desarrollo de varias personas sobre el mismo proyecto, y la pieza que lo hizo encajar fue el devcontainer. El entorno no lo define quien administra la plataforma: lo define el propio repositorio, en un fichero que ya estaba ahí.
Eso cambia quién manda. La plantilla decide la forma del recurso —cuánta máquina, cuánto disco, en qué red—; el repositorio decide qué hay dentro. Cuando alguien añade una dependencia del sistema, la añade donde tenía que añadirla, y al siguiente que abra su entorno le llega sin que nadie le diga nada.
Lo que desaparece es la mañana perdida del primer día, y algo más sutil: el entorno deja de derivar. En máquinas propias, dos personas que empezaron igual acaban distintas en tres meses. Aquí se reconstruye desde la misma definición cada vez.
El acceso era una decisión de red, no una contraseña
Esta es la parte que más me interesa del experimento, y la que se traslada a cualquier equipo que se plantee esto. El servidor no estaba expuesto a internet: vivía en la red interna, detrás del proxy, y se alcanzaba por la VPN en malla.
"tag:lattner": ["autogroup:admin"]Una etiqueta en la política de acceso de la VPN, y solo el grupo de administración podía alcanzarla. Entrar al entorno de desarrollo no era cuestión de tener la dirección y unas credenciales: era estar en la lista, en la capa de red, antes de que la aplicación llegara siquiera a pedirte quién eres.
Para gobernanza eso vale más que cualquier panel de permisos. Da una respuesta comprobable a «quién puede tocar el código en un entorno con acceso a nuestros servicios», y la respuesta no depende de que nadie haya configurado bien la aplicación.
Para lo que de verdad lo quería: máquinas que no tienes
El argumento más fuerte no es la homogeneidad, es la asimetría. Un portátil de trabajo no puede con según qué cosas, y en trabajo con modelos eso aparece enseguida: indexar un corpus grande, ejecutar un modelo local, procesar horas de audio.
Con los entornos en el servidor, la potencia deja de estar atada a quién tiene mejor portátil. Cuatro personas pueden turnarse en una máquina seria en lugar de comprar cuatro máquinas serias, y el trabajo pesado corre donde están los datos y la red rápida, no al otro lado de una conexión doméstica.
En nuestro caso se quedó a medias: la parte de aceleración por hardware no llegamos a configurarla. Es justo el escalón donde esto pasa de cómodo a decisivo, y no lo cruzamos.
Qué haría distinto
Hoy no lo tenemos desplegado. Lo que sí me llevo es cuándo compensa y cuándo no.
Compensa con varias personas sobre el mismo proyecto, cuando el entorno es complejo de montar, cuando hay que dar acceso a alguien de fuera sin darle una copia de todo, o cuando el trabajo necesita más máquina de la que hay en un portátil. Para una persona sola con un proyecto que arranca con un comando, es infraestructura que mantener a cambio de poco.
Y una advertencia práctica: es un servicio más que operar, con su base de datos, su almacenamiento persistente y sus actualizaciones. La ganancia hay que medirla contra eso, no contra cero.
Seguir leyendo
Consultoría de desarrollo agéntico
Montar un homelab desde cero: Kubernetes y GitOps - Homelab (03/06)
Gobernanza IT: quién entra, quién puede desplegar y cómo se demuestra
Un despliegue por cliente o un espacio por cliente
Búsqueda y agentes sobre tu propia documentación
