# 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](https://crewwork.ai/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. ## 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](https://crewwork.ai/releases/) 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. [Discuss your project](https://crewwork.ai/about/#access) [Sentry Integration](https://crewwork.ai/sentry/) --- Canonical page: https://crewwork.ai/compare/