Skip to main content

How CrewWork compares

CrewWork combines autonomous implementation, ongoing maintenance, and independent validation in a self-hosted workspace. Evaluate it around the work you want to delegate, the evidence you need to review, and the infrastructure you want to control.

What makes CrewWork different

Build, Repair, and Improve in One Workflow

Start with a feature request, an error, a security finding, or a measured coverage gap. CrewWork connects that work to planning, execution, validation, and review in one workspace.

Independent Completion Evidence

Completion depends on validation evidence the platform produces itself. Inspect the changes and executed checks before deciding what merges.

Built-In Error Monitoring and Automated Remediation

Connect Sentry-powered monitoring to proposed fixes on separate branches. Automated triggers are opt-in, with cooldowns and daily budgets; required validation and review remain part of the workflow.

Private by Default

Run CrewWork and its model endpoints on infrastructure you control. Public model endpoints require an explicit opt-in; source-control and monitoring integrations use the providers you configure.

Platform Self-Repair

CrewWork repairs its own codebase through Platform Self-Repair, a stricter, purpose-built lane: disabled by default, admin-triggered, run in an isolated git worktree, and validated through a tiered test matrix and LLM review before landing as a draft pull request (PR), never an autonomous merge.

Full Observability Into the Automation

Prometheus, Grafana, Loki, and Tempo ship in the default Docker Compose stack: metrics, logs, traces, and alerting for the platform and the automation itself, out of the box, on the same single host.

Compliance Evidence for Regulated Teams

Any project member with read access can pull a point-in-time compliance evidence report: security scans, SBOM/VEX records, quality-gate results, release provenance, and the audit trail, grouped into PCI DSS-oriented and OWASP ASVS-oriented views. It saves assembly work for your auditors without claiming certification or attestation.

CrewWork is a good fit if

  • You want to delegate feature work, error repair, and code improvement
  • You need self-hosted deployment with data sovereignty
  • You want a configurable, local-first model stack
  • You want one place to follow runs, review evidence, and make decisions
  • You want a platform that improves itself with the same safety guardrails
  • You want to control repair triggers, execution budgets, and review
  • You need compliance-oriented evidence (PCI DSS and OWASP ASVS views) assembled per project for your auditors, without claiming certification

Consider alternatives if

  • You primarily need inline code completions (use Copilot or Cursor alongside CrewWork)
  • You need a cloud-hosted SaaS with zero infrastructure management
  • You want a no-code builder for non-technical users

Application hosting and model serving

CrewWork is self-hosted via Docker Compose. The platform itself runs on PostgreSQL, Qdrant, Redis, an event bus, and a Prometheus, Grafana, Loki, Tempo observability stack on a single host. Model endpoints can run on separate LAN hosts. The current development configuration uses two generative model hosts running the same Qwen3.8 27B artifact, with a separate embedding model alongside one of them. This describes the development setup, not a minimum hardware requirement. See Architecture for the full topology.

It can also build a release artifact once and deploy it to other hosts on your own LAN through an outbound-only, mutual-TLS release agent, with no inbound connectivity to the target hosts. Your code, your infrastructure, your models.

Local model hosting keeps inference within your environment. Review the source-control, monitoring, and external model providers you choose to connect when evaluating your data boundaries.

System topology
View

What you need to self-host

Self-hosting requires infrastructure and operational capacity. Here’s what’s involved.

Infrastructure

  • Docker and Docker Compose
  • PostgreSQL, Redis, and the Qdrant vector store, included in the Compose stack, with no separate database provisioning required

Model Serving

  • An OpenAI-compatible generation endpoint, with model-serving hardware sized separately from the application host
  • A separate embedding endpoint for semantic search
  • Public model endpoints require explicit opt-in

Team Skills

  • Familiarity with Docker Compose
  • Basic database administration
  • Ability to manage local services

Self-hosting still takes operational work

Self-hosting means you run and manage the Docker Compose stack in your own environment. CrewWork itself runs as a single-host stack. The workbench’s Releases surface adds self-service deploys to other LAN hosts through the outbound-only release agent, though initial provisioning (release CA setup, per-host agent certificates, and registry credentials) remains an operator command-line step. See the Releases & On-Call page for the full deploy and escalation model.

Operators should budget for Sentry webhook configuration and suggestion governance tuning (critic confidence/risk thresholds and embedding-based dedupe) as part of normal setup and release operations, and weigh that operational commitment against the control and cost predictability of running on your own infrastructure.

Discuss your deployment

Talk through your project, hardware, and access to CrewWork with the team.