OpenCode en producción

Hay una manera de usar un agente de coding que me cambió la forma de trabajar: dejarlo correr en el host, con acceso a las mismas herramientas que yo usaría si estuviera SSH-eado. No en mi máquina local, no en una sesión efímera. Como un servicio más.

Qué es OpenCode

OpenCode es un agente de coding que vive en una terminal. Le decís qué querés hacer en lenguaje natural, él lee el repo, planifica, ejecuta comandos, edita archivos, y vuelve con el resultado. La diferencia con otras herramientas similares es que la interfaz es una terminal interactiva accesible por HTTPS desde cualquier browser.

No es la única herramienta de este tipo, pero el patrón de deployment es lo que me interesa acá.

Por qué correrlo en el host

Tres razones:

1. El contexto importa. Un agente que solo ve tu repo local no puede diagnosticar por qué un container no levanta, no puede leer los logs de Traefik, no puede ver si un puerto está ocupado. Un agente que corre en el host tiene los mismos ojos que vos cuando SSH-eás.
2. Las acciones son reales. Editar un archivo es editar un archivo de verdad. Correr docker compose up es levantar el container de verdad. Eso elimina toda la fricción de "lo probé en mi máquina pero no sé si funciona en producción" — porque es la misma máquina.
3. El host ya está listo. TLS, DNS, red, Authelia, todo eso ya está resuelto para los servicios. OpenCode es un servicio más, no una pieza especial.

La arquitectura

OpenCode vive en su propio container, conectado a la red web como cualquier otro servicio. Lo que tiene de especial:

• Workspace montado como bind-mount: /workspace dentro del container es el mismo /workspace que ven los demás servicios. Editar un archivo desde el agente es editar el archivo que nginx va a servir.
• Docker socket montado: /var/run/docker.sock le da al agente la capacidad de listar containers, leer logs, levantar servicios, hacer restart. Es el mismo socket que usa el daemon de Docker.
• Acceso a red: está en web, así que puede hablar con cualquier container que también esté ahí (Traefik, Authelia, etc.) por nombre.

Con esas tres cosas, el agente puede:

• Diagnosticar por qué un container está unhealthy (docker logs, docker inspect)
• Levantar un servicio nuevo (docker compose up -d)
• Modificar configuración de Traefik (editando el compose file y haciendo redeploy)
• Editar cualquier archivo de cualquier servicio bajo /workspace
• Probar cambios localmente antes de commitear

El loop de trabajo

Lo que termina pasando en la práctica:

1. Le digo al agente: "agreguemos un servicio nuevo para X"
2. Él mira el patrón existente (docker-compose.yml de los servicios que ya están), copia la estructura, ajusta lo que haga falta
3. Corre docker compose up -d --build
4. Traefik lo descubre, Let's Encrypt emite cert, el servicio queda disponible
5. El agente verifica con curl que responde 200 y reporta

Todo eso sin que yo toque una terminal. Y queda versionado en archivos que puedo revisar después.

Lo que NO está automatizado

• El agente no commitea solo. Después de cada cambio importante, miro el diff, ajusto lo que quiero distinto, y commiteo yo. Es una decisión deliberada: el commit final es mío, no de la herramienta.
• No hay red de tests obligatoria. Algunos servicios tienen tests, otros no. El agente los corre si existen, pero no es un blocker.
• No hay rate limiting del agente. Puede gastar tokens sin freno. Lo trato como un asistente que tiene tarjeta corporativa: confío pero reviso.

Cuándo NO usar este patrón

• Si el host tiene datos sensibles de terceros sin anonimizar, el agente los ve. No es diferente a vos teniendo SSH.
• Si querés separación estricta entre "desarrollo" y "producción", este patrón las borra. Es deliberado.
• Si el agente tiene acceso a internet abierto (alguna configuración lo permite), puede filtrar el repo a servicios externos. Lo tengo bloqueado por defecto.

La verdad sobre tener un agente en producción

Es una herramienta, no un reemplazo. El 80% del trabajo sigue siendo mío: definir qué queremos, validar que la solución tenga sentido, decidir prioridades, escribir las partes donde el criterio humano importa. El otro 20% — la ejecución mecánica, las búsquedas en docs, el formateo, el debugging rutinario — se lo delego al agente y me aburro menos.

Lo que cambió es que ya no tengo excusas para no hacer algo porque "es tedioso". Si es tedioso, se lo paso al agente y reviso el resultado.