Kiro Crew: A Self-Hosted Persistent Workspace for AI Development Work

What Kiro Crew Is and the Problem It Addresses

Most AI agent sessions end when the conversation closes. Kiro Crew addresses this by running a persistent Gateway process on hardware you control. Sessions, memory, lessons, and scheduled jobs survive Gateway restarts. Work continues between conversations without requiring the developer to re-establish context each time.

The README describes three key properties. Persistent: sessions and task checkpoints survive restarts, and scheduled or reactive work continues without someone at the terminal. Self-learning: corrections and task failures become durable lessons that change later behavior, with optional repo_scope to limit a lesson to one repository. Self-evolving: repeated patterns are synthesised into reusable skills that can be inspected, refined, or removed as the work changes.

The target user is a developer who runs regular multi-step work: summarising open issues on a schedule, researching options in parallel subagents, running a migration plan with per-step validation, or monitoring a system until something needs attention. Kiro Crew Apps extend this to purpose-built interfaces for specific jobs, combining a custom UI with agents, skills, schedules, integrations, and backend services.

Persistent Memory, Lessons, and Evolving Skills

The three self-improvement mechanisms in Kiro Crew work at different scopes. Memory records user preferences and project context that carry into new sessions. Lessons are created from corrections and failures: when the developer corrects an agent action or a task fails, the correction becomes a durable instruction that applies to future sessions. A lesson can be global or scoped to a repository by setting repo_scope.

Skills are higher-level than lessons: they are synthesised from repeated patterns and represent reusable procedures. All three (memory, lessons, skills) stay visible and editable in the interface, so the workspace grows more tailored without becoming opaque.

Crew Members, the README explains, keep private lessons in their own memory store. This means a shared Kiro Crew Gateway can host multiple members with separate, private lesson stores while sharing the same underlying infrastructure.

The README documents that long-running tasks plan steps, execute them, validate results, retry failures, and resume from checkpoints. The example given is "Implement this migration plan and stop if the tests fail", which runs as a checkpointed task with validation at each step.

Installing Kiro Crew: Desktop App, One-Line CLI, Docker, and Source

The fastest path for macOS or Windows is the desktop app, available as a DMG for macOS or an EXE installer for Windows x64 from the download URLs listed in the README.

For a server or Linux, the one-line install fetches and runs the signed Stable wheel:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

After install, open http://localhost:5476. To pin a specific release (minimum pinnable version is 0.1.2):

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.6.0

For always-on servers, a Docker image is published on GHCR:

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

To build from source, the prerequisites are Python 3.12+, Node.js 22+ (24 LTS recommended), and npm. The default ACP backend also requires kiro-cli installed and signed in on the Gateway host:

git clone https://github.com/kirodotdev/KiroCrew.git
cd KiroCrew
make build
source .venv/bin/activate
kirocrew setup
kirocrew doctor
kirocrew gateway

Three release channels exist: Stable is the default, Insider follows release candidates, and Nightly tracks the main branch.

Scheduled Work, Delegation, and Unattended Autonomy

Kiro Crew can run work without a developer present in three ways. Scheduled agent work runs on a timezone-aware cron schedule; the README example is "Every weekday at 9, summarize the open work I should review" delivered to the surface the developer chooses. Reactive work responds to messaging events and authenticated webhooks. Deterministic scripts and commands run without a model call at all.

Delegation is the third mechanism: a task can spawn isolated subagents for parallel work and bring their results back to the parent conversation. The README example is "Research these three options in parallel and recommend one", which fans out and synthesises. This differs from a single sequential agent: the parallel subagents run independently in isolation.

Heartbeat monitoring is documented as a fourth unattended pattern: the agent monitors a system or condition until something needs attention, then surfaces the result to the developer. All four patterns (scheduled, reactive, scripted, heartbeat) run in the same persistent Gateway process without requiring the terminal to stay open.

Kiro Crew vs the Kiro IDE, and Known Limitations

The Kiro IDE is a different surface of the same platform: an editor-integrated development environment for local, interactive work. Kiro Crew is for persistent, scheduled, and unattended work that runs beyond a single IDE session. The README describes the Kiro IDE as "Local development with editor integration, chat, specs, and hooks" and Kiro Crew as the surface suited for "A persistent open-source development workspace with memory, scheduling, and multi-channel access". The two complement each other in the same agent harness.

Cloud-based AI assistants such as general-purpose chat tools work per-session and do not retain memory between conversations unless the developer re-provides context. Kiro Crew's Gateway retains memory across sessions, which changes how multi-day and multi-week projects work: the agent accumulates context over time rather than starting fresh each time.

The primary practical limitation is the self-hosting requirement. The Gateway process must stay running for scheduled and reactive work to continue. The one-line install is designed to be low-friction, but the developer is responsible for keeping the host available. The README does not document an official managed-hosting option for the Gateway. Version 0.8.0 is the current package version, and the most recent release at the time of the last repository push was v0.7.1, published on 2026-09-25. The license is Apache-2.0.

Editorial conclusion

Kiro Crew is the right choice for a developer who needs a self-hosted workspace that keeps context across sessions, learns from corrections over time, and runs autonomous scheduled work without requiring anyone at the terminal. It is not appropriate for teams that cannot or do not want to manage a self-hosted server: the one-line install is straightforward, but the Gateway process must remain running for scheduled and reactive work to continue. The last push was on 2026-09-27, and v0.7.1 shipped on 2026-09-25. The license is Apache-2.0, which permits commercial use, modification, and distribution subject to the notice requirements in the NOTICE file.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes