Kimi Code lleva el agente a tu Laravel remoto sin mover tus credenciales

El problema no es editar código, es dónde se ejecuta

Cuando uso un agente sobre un proyecto Laravel, no quiero darle acceso directo a mi máquina principal ni copiar credenciales del proveedor de IA a cada servidor. Tampoco quiero que una sesión pensada para revisar una cola, arreglar un test o preparar una migración termine ejecutando comandos en producción por accidente. La parte interesante de Kimi Code 2.5.0-canary.20261030040529-bd0d4de es que separa el cliente y el modelo del lugar donde el agente toca archivos y ejecuta procesos. (moonshotai.github.io)

El CLI, las credenciales, las aprobaciones y las peticiones al modelo se quedan en mi equipo. En cambio, las operaciones de lectura, escritura, edición y shell pueden ocurrir en otra máquina POSIX o dentro de un contenedor compatible con Docker. Para un homelab, esa división permite usar un entorno Laravel aislado sin convertir el servidor remoto en otro puesto de trabajo con claves repartidas por ahí. (moonshotai.github.io)

Una configuración útil para un Laravel por SSH

La configuración vive en ~/.kimi-code/config.toml, dentro de la sección [environments]. Un destino SSH utiliza type = "ssh" y un host que puede resolverse mediante mi ~/.ssh/config, así que puedo conservar usuario, puerto, clave, salto intermedio o agente SSH donde ya los gestiono. defaultCwd debe ser una ruta absoluta POSIX del servidor remoto; no conviene confiar en ~ ni en rutas relativas. (moonshotai.github.io)

[environments.laravel-homelab]
type = "ssh"
host = "laravel-homelab"
defaultCwd = "/srv/laravel/app"

Con esa entrada, la sesión puede quedar vinculada a ese servidor desde su creación. También existe --environment para elegir el identificador y --environment-cwd para cambiar el directorio remoto inicial en una sesión nueva. Yo lo usaría para una copia de staging o para una máquina de integración, no como excusa para saltarme un flujo de despliegue que ya funciona. (moonshotai.github.io)

Docker encaja mejor cuando quiero acotar el alcance

Para un proyecto Laravel que ya vive en Docker, el destino puede ser un contenedor en ejecución. Kimi Code usa docker exec para llegar al contenedor y permite indicar un context si no estoy trabajando contra el contexto Docker por defecto. Esto resulta práctico cuando quiero que el agente ejecute php artisan test, Composer o una comprobación de Pint dentro del mismo entorno que usa la aplicación. (moonshotai.github.io)

[environments.laravel-dev]
type = "docker"
container = "laravel-app"
defaultCwd = "/var/www/html"

El contenedor necesita tener disponible el ejecutor remoto de Kimi Code. No se instala automáticamente: la documentación indica que debe existir en la ruta esperada o que se configure remoteBin con su ubicación dentro del destino. En una imagen propia, prefiero dejarlo instalado de forma explícita antes de abrir una sesión, en lugar de convertir el arranque del agente en un paso mágico difícil de repetir. (moonshotai.github.io)

La letra pequeña antes de apuntar a un servidor

Esto no convierte un servidor remoto en un entorno completamente local. Los hooks de ciclo de vida se ejecutan en la máquina donde corre Kimi Code, y los servidores MCP basados en stdio también permanecen locales salvo configuración explícita. Si un hook espera inspeccionar archivos o procesos del Laravel remoto, puede tomar decisiones equivocadas porque estará viendo el sistema local. (moonshotai.github.io)

Tampoco hay una red de seguridad que redirija comandos al equipo local si se corta la conexión. Si el entorno remoto deja de estar disponible, las llamadas fallan; no hacen fallback silencioso a local, y eso es exactamente lo correcto cuando hay comandos potencialmente destructivos. Las sesiones remotas requieren objetivos POSIX, así que Windows no entra en esta función tal como está documentada. (moonshotai.github.io)

Yo no lo usaría directamente contra producción con permisos amplios, aunque el modelo y las claves se queden fuera. El agente sigue pudiendo modificar archivos y lanzar procesos con los permisos del usuario remoto o del contenedor. La barrera sensata sigue siendo la de siempre: usuario limitado, entorno desechable cuando sea posible, confirmaciones activas y tests antes de cualquier despliegue.

Fuente: Freedom.Tech

Documentación oficial: Kimi Code Remote environments