Kiro Crew

Kiro Crew is an open-source personal AI agent that runs on your own hardware, locally or on a remote host, and stays running. Kiro’s documentation describes it as persistent, self-learning, and self-evolving, and it is the fifth surface alongside the IDE, CLI, Web, and mobile.

What is Kiro Crew?

The other four surfaces are session-shaped. You open one, do something, and close it. Crew is the opposite: a gateway process that stays up, holds memory, runs scheduled jobs, watches for triggers, and can be reached from a dashboard or from a chat app on your phone.

It was open-sourced on August 4, 2026 under the Apache 2.0 licence and picked up coverage from InfoQ, InfoWorld, Forbes, and DevOps.com. That matters for two reasons: you can read the code, and, because the project is young and moving quickly, you should check its documentation rather than trusting a page like this one for details that change.

How it differs from the other always-on options

Four things in Kiro can run without you sitting there, and they are easy to conflate:

	Runs on	Shape	Reaches	Output
Kiro Crew	Your hardware, local or remote	Persistent process	Dashboard, Slack, Discord, Telegram, Teams, and more	Artifacts, files, messages, whatever the job produces
Web Automations	AWS	Scheduled runs (hourly / daily / CRON)	GitHub, GitLab repositories	A pull request per run
Cloud sessions	AWS	One durable session you attach to	The repository fixed at creation	Session work you review
CLI headless	Wherever you run it	One non-interactive command	Whatever the runner can reach	Whatever your pipeline does with it

The rule of thumb: if the work is repository-shaped and belongs in a PR, that is Kiro Web. If it belongs in your CI pipeline, that is headless CLI. If it is a long task you want to check on from another machine, that is a cloud session. If it is an assistant that should still be there tomorrow, on hardware you control, that is Crew.

How to install it

Four paths, all documented:

• Desktop app. Signed .dmg for macOS, a signed installer for Windows, and .deb, .rpm, and .AppImage for Linux, on x86_64 and ARM64.
• One-liner. curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
• Python package. pip install kirocrew, with extras available as pip install "kirocrew[voice]" and pip install "kirocrew[aws]".
• Docker. ghcr.io/kirodotdev/kirocrew:stable, with insider, nightly, and version tags also published.

Prerequisites. Python 3.12 or newer, which is the minimum since Crew 0.6.0 (it was 3.10 before). Node.js 22 or newer only if you are building the dashboard yourself, which the wheel, desktop, and Docker paths do not require. And kiro-cli for model access, which the desktop app installs on first launch.

The three commands to know:

kirocrew setup     # interactive wizard
kirocrew doctor    # verify the installation
kirocrew gateway   # start the server at http://localhost:5476

Data lives in ~/.kiro/crew/, overridable with KIROCREW_HOME, and the port is 5476, overridable with KIROCREW_PORT.

Running it 24/7

As a service. kirocrew service install registers a systemd unit on Linux or a launchd job on macOS. From there, kirocrew service status, kirocrew restart, and kirocrew logs -f are the operational commands, and kirocrew token --ttl 2h issues a time-limited access token.

In Docker.

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

docker exec -it kirocrew kiro-cli login

Note the 127.0.0.1: prefix on the port mapping. That is deliberate.

On a remote host. Supported Linux distributions are Ubuntu 22.04+, Debian 12+, Fedora, and Amazon Linux 2023. Plan for roughly 10 GB of RAM minimum and 16 GB recommended, which puts this above the smallest VPS tiers. The dashboard binds to loopback only by default, so you reach it with a tunnel:

ssh -L 5476:localhost:5476 user@host

Interfaces

Crew is unusual in how many places it can be reached from: the desktop app, the web dashboard at localhost:5476, its own CLI, and a long list of messaging platforms including Slack, Discord, Telegram, Teams, Webex, WeChat and WeCom, WhatsApp (linked by QR code), iMessage through a macOS bridge, and Feishu or Lark. All of them share the same memory, skills, and scheduled jobs, so a conversation started in Slack is the same agent you see in the dashboard.

What it can do

The documented feature set is broad:

• Subagents. Parallel background agents.
• Scheduling. Recurring jobs, reactive monitoring, and external triggers.
• Artifacts. Versioned output with live preview and one-click deploy to your own AWS account.
• Multi-instance. Manage remote Crews over SSH, AWS Systems Manager (SSM), or, since 0.7.0, AWS Fargate.
• Task Runner. Autonomous execution with planning, validation, retry, and checkpoints.
• Memory. Preferences, history, lessons, and semantic facts.
• Knowledge. A curated documentation library.
• Snapshot and restore. Capture and roll back state.
• Browser. Real browser automation with a live view.
• Computer Use. Desktop control on macOS and Windows, off by default.
• Workflows. Multi-agent fan-out and pipelines defined as Python scripts. (Crew’s own feature, not the Kiro Workflows that run in the IDE, CLI, and Web.)

Underneath, the building blocks are the ones you already know. Crew’s agent capabilities page lists Agents, Agent Templates, Integrations (MCP), Skills, Steering, Hooks, and Prompts, which is the same vocabulary as the rest of Kiro.

Apps and the App Store

An app is a package that adds agents, skills, MCP servers, cron jobs, dashboard pages, or backend processes. Crew has a built-in App Store: Install clones the repository and Enable registers it. Federated registries are supported, so an organization can run its own.

Third-party apps are disabled by default, behind a toggle under Settings → Security. Leave that off until you have read what you are enabling. Press coverage at launch named DevFleets (worktree management), Issue Radar (issue and PR triage), and Task Runner as reference apps announced at launch.

What’s new in Crew 0.9.0

0.9.0 (16 October 2026) is about seeing what each crewmate is doing without asking it.

Before you upgrade. New installs start Response Verbosity at Answer only, and the Ultra level is retired: a config that stored Ultra now behaves as Answer only, so pick another level if you want longer replies. Translucent panels are off by default. Chats an older build ran on a peer crew through the retired turn relay open read-only. Some settings moved: Agent Capabilities is now Customize, and Subagent Settings and Warm Pool (now Pre-started Sessions) live under Settings → Agent Harness.

Crewmates at a glance. Opening a crewmate shows a card with its goal, what is finished, running, or waiting on you, and one next step. The card reads from the crewmate’s record, so it costs no chat turn. A Profile card holds the crewmate’s memory, workspace, notes, permissions, model, reasoning effort, schedules, and sessions.

Dashboards and remote crews (preview). With Dynamic Dashboard turned on under Settings → Developer → Feature Previews, each crewmate gets a dashboard tab; twelve pages ship, and a value the crewmate wrote itself is labelled as such. With Remote crew sessions turned on, a peer crew’s session opens as a live window onto that machine, with nothing stored locally.

A composer that knows its limits. It warns when a prompt nears or passes the model’s context window and holds an over-limit send until you send it again. ! <command> reviews and runs a shell command in the session’s workspace, and Cmd or Ctrl plus Up edits your last message.

Usage you can plan by. The Usage tab adds an estimated token count (estimated, because Kiro CLI reports credits rather than tokens) and, with enough history, says whether your credits last until the reset or the day they would run out.

Crew 0.8.0

0.8.0 (27 September 2026) changes three defaults, and two of them matter for safety.

Before you upgrade. Owner-written autoApprove lists now take effect: tools listed under autoApprove in mcp.json or an agent file skip both the approval card and Crew’s own tool gate. Review those lists first, or set mcp.honour_auto_approve to false and restart the Gateway to keep the gate. An app’s own list is never honoured. Crew logs are on by default: each chat records a redacted event log that feeds session ledgers and Issue Radar; set KIROCREW_CREW_LOG=0 before starting the Gateway to turn it off. Command cron validation is stricter: stored commands using brace expansion fail until edited, so move shell tricks into a script cron. 0.8.0 also fixed approved calls skipping a final denied-command and protected-path check.

Quieter watches. A monitoring loop can screen each check before waking the session (Quiet check-ins, in the Decisions preview), so a quiet check costs no model turn. Pull request watches also wake when a review asks a question or requests a change, and monitoring.max_runtime_secs can raise the seven-day ceiling to thirty days.

Blocked content explains itself. A removed credential or a blocked link opens a card that says what matched and the safe way to reach it.

Folders carry steering. A folder can name extra steering directories, and every chat in that folder inherits them on every agent backend.

Kiro CLI included. Fresh desktop installs on macOS, Linux, and Windows carry a tested copy of Kiro CLI, so you can sign in and chat without installing one on your PATH.

Templates, teams, and more backends. An Agent templates tab lets you create, duplicate, or enrol templates as crewmates; with the Crew Members preview you can group crewmates into teams. DeepSeek Harness joins the agent backends when dsh is installed. Remote crews can chain through one another, up to two hops.

Crew 0.7.0

0.7.0 (24 September 2026), patched to 0.7.2 by 28 September, is mostly about making an always-on agent behave like a service you can leave alone.

Settings apply while it runs. Most changes reach the running Gateway as soon as you save config.json or change a value in Settings. The few that still need a restart say so in the UI.

Work survives a restart. Accepted subagent work, Task Runner steps, and workflow calls go into a durable queue before they run, so a Gateway restart picks them up instead of dropping them. Automatic updates, now checked at startup and every twelve hours, wait for active work to go idle before restarting. A Crew log keeps an append-only session trail across compaction; it was optional in 0.7.0 (KIROCREW_CREW_LOG=1 in ~/.kiro/crew/.env) and is on by default since 0.8.0.

More agent backends (preview). OpenCode and goose join Kiro CLI, Claude Code, Codex, and KAS in the Agent Backend selector, and Pi works when pi and pi-acp are installed. Pi sessions do not get Crew’s own MCP tools, so pick another backend when you need subagents, scheduling, or memory.

Chat controls. Model and reasoning effort now sit together on the model chip. While the agent is working you choose Steer to redirect the current turn or Queue to wait for the next one, and /side (or /btw) opens a side chat for a quick question that does not disturb the main conversation.

Pull request watches beyond GitHub. GitLab, Bitbucket Cloud, and Azure DevOps Services pull requests can be watched too. Azure DevOps Server and Bitbucket Data Center are not supported.

Remote crews on AWS Fargate. Fargate joins SSH and SSM as a way to reach a remote crew, through SSM with no inbound network rule. Tasks live six hours by default and at most ten run at once.

Windows. Isolated worktree pods now run on Windows through Task Scheduler, and the Gateway cold start dropped from about seventeen seconds to about four.

Skills load by search. skills.max_triggered now defaults to 0: sessions get a short skill index and agents search it, instead of every matching skill being injected into every message. Set a positive number to bring the old behaviour back.

Upgrade note. 0.7.2 closed a hole where any member of a configured WhatsApp group could drive the agent; groups now only accept the linked account and the numbers in Allowed WhatsApp IDs. If you connected WhatsApp, upgrade.

Crew 0.6.0

0.6.0 (5 September 2026) changed enough about how Crew is set up and supervised to be worth reading before you upgrade an instance that is already running.

Selectable agent harnesses. You can choose what runs behind a session — Claude Code, Codex, or KAS (with more added in 0.7.0) — under Settings → Developer → Agent Backend. It is a preview feature, so treat the choice as something to test rather than to standardize on.

Remote crews. You can start a chat on a connected remote crew without leaving the sidebar. The transcript stays local while the remote crew does the work, which makes a remote instance feel like the one on your desk.

Worker dispatch. Agents can start, revise, and stop monitoring loops, and crew members can dispatch workers of their own. Those workers inherit the trust posture of whoever created them. Said plainly: if you put a crew member on Autopilot, every worker it dispatches runs on Autopilot too, and you approved that once rather than each time. Set approval levels for what the members you trust might go on to start, not only for what they do themselves.

Apps Launchpad. Installed apps now appear in a grid under Apps → Library, where you can open, pin, update, disable, and uninstall them. Third-party apps are still disabled by default.

Longer timeouts for long-running work. A chat turn can now run up to 4 hours (agent.chat_turn_timeout_secs, default 14400), a subagent up to 3 hours (agent.subagent_timeout_secs, default 10800), and a subagent can take up to 1000 tool calls (agent.subagent_max_turns). Useful for overnight jobs, and worth remembering that four hours of unattended work is also four hours of credit consumption.

Python 3.12 is the minimum. If you are on 3.10 or 3.11, upgrade Python before upgrading Crew.

The security model

This is the part that deserves the most attention, because an always-on agent on your own machine is a different risk profile from a chat window.

• Owner lock on channels, so a Slack or Telegram connection answers to you rather than to anyone who finds it.
• 137 denied command patterns, covering things like rm -rf /, pushes to protected branches, reading ~/.aws/credentials, and requests to the instance metadata service.
• Governance ceiling: where policies overlap, the tightest one wins.
• Sensitive-path blocking and input validation.
• Tool approval levels: Interactive by default, with Trust this command, Trust this tool, and Autopilot. Deny rules are still enforced under Autopilot.
• OS sandbox with three modes. Auto hides .gnupg, .gcloud, .azure, and .docker. Strict additionally hides .aws, .ssh, and .kube. Off is available on Linux and macOS only.
• Output redaction of more than fifteen credential patterns, plus an encrypted secrets vault.
• A signed audit log, inspected with kirocrew security events, kirocrew security audit, and kirocrew security verify.

What it costs

Crew’s documentation lists no separate price for Crew itself. The software is Apache 2.0 and runs on hardware you already pay for. Its model calls go through kiro-cli, so Kiro credits apply to the work it does, drawn from the same pool as the IDE, CLI, and Web. A scheduled job every fifteen minutes is a standing credit commitment; treat it like one. Credits & Pricing covers the plans and the pool.

Common mistakes

Exposing port 5476. The dashboard binds to loopback for a reason. The fix: SSH tunnel, not a firewall rule.

Enabling third-party apps to see what they do. An app can add agents, MCP servers, cron jobs, and backend processes. The fix: read first, enable one at a time.

Turning on computer use because it sounds impressive. Desktop control is off by default, and an agent that can move your mouse is a much larger blast radius than one that can edit files. The fix: leave it off until a specific job needs it.

Undersizing the host. Below roughly 10 GB of RAM you are fighting the machine. The fix: size for 16 GB if this is going to run permanently.

Assuming this page is current. Crew was open-sourced weeks before this was written and is moving quickly. The fix: check the Crew documentation for anything you are about to depend on.

Where it fits

Crew is the persistent layer beside the four session-shaped surfaces. It shares Kiro’s vocabulary (agents, skills, steering, hooks, MCP) and its model access, but it is hosted by you rather than by AWS, which is the whole point of it. If the appeal is “an agent that is always there and answers in Slack”, that is Crew. If the appeal is “work on my repositories from a browser”, that is Kiro Web.

Learn more

• Run Kiro Crew 24/7 is the service and Docker walkthrough.
• Core Concepts maps the building blocks Crew shares with the rest of Kiro.
• Kiro Web is the hosted alternative for repository work.
• Cloud sessions covers AWS-hosted durable sessions.
• Credits & Pricing explains what Crew’s model calls consume.