Kimi Code runs the agent against remote Laravel without moving your credentials

The real issue is where tools run

When I use an agent on a Laravel project, I do not want it to have unrestricted access to my main workstation, and I do not want to copy AI provider credentials onto every server. I also do not want a session intended to fix a test, inspect a queue, or review a migration to run commands on production by mistake. The useful part of Kimi Code 2.5.0-canary.20261030040529-bd0d4de is the split between the local client and model traffic, and the place where the agent reads files or runs processes. (moonshotai.github.io)

The CLI, credentials, approvals, and model requests remain on my machine. File reads, writes, edits, and shell commands can instead happen on another POSIX machine or inside a Docker-compatible container. For a homelab, that means I can give the agent a disposable Laravel environment without turning the remote server into another machine full of API keys. (moonshotai.github.io)

A practical SSH setup for Laravel

The configuration belongs in ~/.kimi-code/config.toml, under [environments]. An SSH target uses type = "ssh" and a host that can be resolved through my existing ~/.ssh/config, so my user, port, key, jump host, and SSH agent setup stay where they already belong. defaultCwd must be an absolute POSIX path on the remote host, so I would not rely on ~ or relative paths here. (moonshotai.github.io)

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

That entry lets a new session bind to the remote server from the start. There is also an --environment option for selecting the target and --environment-cwd for setting the initial remote directory on a newly created session. I would use this for staging, CI-like hosts, or a lab machine, not as a shortcut around a deployment process that already has proper safeguards. (moonshotai.github.io)

Docker is better when I need a tighter boundary

If the Laravel project already runs in Docker, the target can be a running container. Kimi Code reaches it with docker exec and can use a specific Docker context when the default one is not the right target. That is useful when I want the agent to run php artisan test, Composer, or Pint in the exact runtime used by the application. (moonshotai.github.io)

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

The container still needs the Kimi Code remote executor available inside it. It is not installed automatically: the documentation says it must be present at the expected location, or remoteBin must point to its actual path. In a custom image, I would install it deliberately during image creation rather than making agent startup depend on an implicit step nobody remembers later. (moonshotai.github.io)

The fine print matters

This does not make the remote host behave exactly like a local workspace. Lifecycle hooks run on the machine where Kimi Code itself runs, and stdio MCP servers also remain local unless explicitly configured otherwise. A hook that expects to inspect files or processes on the remote Laravel host may therefore make the wrong decision because it is seeing local state instead. (moonshotai.github.io)

There is no silent safety net that sends commands back to the local machine after a connection drops. When the remote environment becomes unavailable, tool calls fail rather than falling back to local, which is the right behavior for potentially destructive commands. Remote environments also require POSIX targets, so Windows is not supported by this feature as documented. (moonshotai.github.io)

I would not point this directly at production with broad permissions, even though the model traffic and credentials remain local. The agent can still change files and start processes with the permissions of the remote user or container user. The sensible controls are the usual ones: a restricted account, an ephemeral environment where possible, approvals kept on, and tests before any deployment.

Source: Freedom.Tech

Official documentation: Kimi Code Remote environments