packages/kilo-docs/pages/code-with-ai/platforms/cloud-agent.md
Cloud Agents let you run Kilo Code in the cloud from any device, without relying on your local machine. They provide a remote development environment that can read and modify your GitHub and GitLab repositories, run commands, and auto-commit changes as work progresses.
Before using Cloud Agents:
Your work is always pushed to GitHub, ensuring nothing is lost.
Each user receives an isolated Linux container with common dev tools preinstalled (Node.js, git, gh CLI, glab CLI, etc.).
Python is not included in the base image, but apt is available so you can install it or other packages as needed.
All Cloud Agent chats share a single container instance, while each session gets its own workspace directory.
When a session begins:
After every message, the agent:
Containers are ephemeral:
Agent environment profiles are reusable bundles of environment settings for cloud-agent sessions. A profile can include:
Profiles are owned by either a user or an organization. Names are unique per owner, and each owner can have a single default profile. This lets teams share standard environment setups across multiple sessions and triggers.
You can customize each Cloud Agent session by also defining env vars and startup commands on the fly. These will override any Agent Environment Profile you've selected:
.kilocode/setup-script.kilocode/setup-script..kilocode/setup-script in Cloud Agent, call it explicitly from Setup Commands, for example: bash .kilocode/setup-script..kilocode/setup-script)Cloud Agents support project-level skills stored in your repository. When your repo is cloned, any skills in .kilocode/skills/ are automatically available.
{% callout type="note" %}
Global skills (~/.kilocode/skills/) are not available in Cloud Agents since there is no persistent user home directory.
{% /callout %}
Remote Connections let you access and control local CLI sessions from the Cloud Agents web interface. Your computer handles the compute; the cloud gives you a window into it from any device.
When remote mode is enabled in the CLI, your active local sessions appear in the Cloud Agents dashboard alongside cloud sessions. The connection is two-way:
Remote mode must be enabled from the CLI. See CLI Remote Connections for setup instructions.
{% callout type="warning" title="Security Warning" %} Anyone with access to your Kilo account can send messages to your computer when remote mode is enabled. {% /callout %}
Cloud Agents are great for:
Triggers allow you to initiate cloud agent sessions automatically, either via HTTP requests (webhooks) or on a recurring schedule. This enables integration with external services and time-based automation workflows.
{% callout type="note" %} Triggers are currently in beta and subject to change. {% /callout %}
Triggers are accessible from the main sidebar under Webhooks / Triggers and link to https://app.kilo.ai/cloud/triggers for personal accounts. Organization-level trigger configurations are available through your organization's sidebar.
When creating a trigger, you choose an activation mode that cannot be changed after creation:
Triggers utilize agent environment profiles to configure the execution environment for triggered sessions. The agent resolves the profile at runtime, so profile updates apply automatically to future executions. Profiles referenced by triggers cannot be deleted until those triggers are updated or removed.
Triggers do not support manual env var or setup command overrides at this time.
Scheduled triggers fire on a recurring schedule using cron expressions. You can configure them with a simple frequency picker (every 10 minutes, hourly, daily, weekly) or enter a raw cron expression for full control. Each trigger has a configurable timezone (default: UTC) and handles daylight saving time transitions automatically.
The minimum schedule interval is 10 minutes. Scheduled triggers use {{scheduledTime}} and {{timestamp}} as prompt template variables (webhook-specific variables like {{body}} are not available since there is no inbound HTTP request).
Triggers are designed for low-volume invocations from trusted sources and are best suited for short-lived tasks.
Additional limits:
413)415) such as multipart/*, application/octet-stream, image/*, audio/*, video/*, application/pdf, application/zipcaptured or inprogress at once (returns 429)The trigger endpoint will return rate limit responses when the number of queued or processing requests exceeds system capacity.
You can reference data in a trigger’s prompt template using these placeholders.
Webhook triggers:
{{body}} - raw request body (string){{bodyJson}} - pretty-printed JSON if parseable, otherwise raw body{{method}} - HTTP method (GET, POST, etc.){{path}} - request path{{headers}} - JSON-formatted request headers{{query}} - query string without leading ? (empty if none){{sourceIp}} - client IP if provided (falls back to unknown){{timestamp}} - capture timestamp (ISO string)Scheduled triggers:
{{scheduledTime}} - the time the schedule fired (ISO string){{timestamp}} - capture timestamp (ISO string){% callout type="warning" title="Security Considerations" %} Care should be taken when deciding to use webhooks as they are susceptible to prompt injection attacks. Especially in scenarios where webhook payloads may contain untrusted input. At this time we recommend using webhooks only for trusted sources. {% /callout %}
plan.md or todo.md file to keep scope clear.