OpenCode en un servidor: cómo hacer que un agente de IA trabaje mientras duermes

Una historia conocida: lanzaste un agente de IA en la terminal, se colgó en el mejor momento, cerraste el portátil y toda la sesión desapareció. Claude Code y Codex son cerrados y están pensados para los modelos de sus propios autores. OpenCode, un harness de código abierto, no tiene esa limitación: funciona con cualquier proveedor y, sobre todo, se puede alojar en un servidor.

Por qué es posible

Por dentro, OpenCode usa un esquema cliente-servidor. La TUI se comunica con un servidor HTTP local que publica una especificación OpenAPI en el endpoint /doc. El comando opencode serve levanta ese mismo servidor sin interfaz. Por defecto escucha en 127.0.0.1:4096, y la dirección y el puerto se cambian con los flags --hostname y --port. Se puede acceder a él desde CI, desde cron o desde otro script, y además mantenerlo "caliente" para no pagar el arranque en frío de MCP y LSP.

Si el servidor es accesible más allá de localhost, define obligatoriamente OPENCODE_SERVER_PASSWORD. Se activará HTTP basic auth, con el nombre de usuario por defecto opencode. Una contraseña no basta: coloca el servidor detrás de nginx o Caddy con HTTPS; de lo contrario, basic auth sobre HTTP abierto solo protege frente a escaneos casuales.

Dónde resulta útil

El escenario más simple es CI/CD y la revisión de pull requests. Con la aplicación de GitHub basta mencionar /opencode o /oc en un comentario, y el agente arranca en un runner de GitHub Actions, lee el contexto y, si hace falta, abre un PR con la corrección. Sin la aplicación, se escribe en el workflow un paso con opencode run --standalone: en CI no hay una TUI en ejecución, así que el comando levanta por sí mismo un servidor privado para la tarea. La salida de los modelos no es determinista, así que no conviene encargar al agente evaluaciones con puntuación, pero para revisiones es perfectamente adecuado.

El segundo escenario son las tareas nocturnas. El plugin opencode-scheduler usa launchd en macOS y systemd en Linux, con cron como alternativa. Una auditoría diaria de dependencias o un informe del git log se programa y se olvida. El tercero es un servidor común para el equipo: plugins de IDE, una interfaz web o un puente de Telegram se conectan a un único proceso y ven las mismas sesiones.

Systemd o Docker

En un VPS limpio basta una unidad de systemd con el comando opencode serve. La trampa principal es PATH. Los servicios de systemd no heredan el PATH de tu shell, por lo que no se encuentra solo OpenCode, sino también todo lo que el agente invoca mediante bash: git, node, rg, make. Define Environment=PATH=... y HOME de forma explícita.

Docker aporta aislamiento del sistema de archivos y repetibilidad. Fija una versión concreta de la imagen, monta el workspace en un volume aparte y las configuraciones y sesiones en otro. Pero esto protege de un rm accidental, no de una fuga deliberada.

Permisos, proveedores, seguridad

El proveedor se conecta mediante @ai-sdk/openai-compatible: sirve cualquier endpoint compatible, desde Ollama local hasta una pasarela en la nube. En el ejemplo del artículo se usa BotHub, patrocinador del material. Es mejor no guardar la clave de API en la configuración, sino añadirla con opencode auth login. Para tareas de servicio, como los títulos de sesión, define un small_model barato.

En un servidor no se puede dejar la regla ask: opencode serve puede esperar horas una respuesta que nunca llegará. Usa reglas allow puntuales sobre deny, o el flag --auto, que convierte ask en allow pero conserva deny.

Lo más importante: SECURITY.md dice explícitamente que OpenCode no es un sandbox y que el sistema de permisos es solo UX. Los servidores MCP externos quedan fuera del límite de confianza, y un caso reciente de un MCP malicioso que ejecutaba código mediante OAuth lo confirmó. Otro dolor de cabeza es Bun: lee HTTP_PROXY de forma inestable, no entiende socks5://, y sin NO_PROXY para localhost el agente puede entrar en bucle con sus propias peticiones.

Monitorización y conclusión

Hay un health-check en /global/health, logs en journald o Docker, y el plugin opencode-otel envía trazas a Jaeger, Grafana Tempo, Datadog o Langfuse. Para CI resulta cómodo opencode run --format json. Vigila el consumo de tokens: por la noche el agente trabaja sin supervisión.

Conclusión práctica: levantar un agente en un servidor es cosa de una tarde, y el trabajo de verdad empieza después. Aislamiento, HTTPS, permisos estrictos y observabilidad son imprescindibles. Funciona mejor donde está integrado en un proceso: auditorías nocturnas, revisión de PR. Mejor no darle acceso a producción: que prepare el PR y que el botón lo pulses tú.