Loading...
Source Control & Integrations
CrewWork connects to GitHub, GitLab.com, Bitbucket Cloud, and Jira Cloud through provider-native OAuth or a direct API token. Every organization holds exactly one authoritative connection per provider, and all four kinds can coexist side by side. Each connection appears in the workbench’s Source Control surface, where the same lifecycle described in How It Works picks it up.
Providers
GitHub, GitLab.com, and Bitbucket Cloud are full source-control connections: CrewWork lists repositories, clones them, and pushes to them. Jira Cloud is issue-tracking only, with no repository or code hosting behind it.
Full source control, PR authoring
Repository listing, clone, push, native issue sync, and pull request authoring. GitHub is the only provider where CrewWork opens pull requests today, and the only provider with automatic PR review comments (see below).
Full source control
Repository listing, clone, direct push, and issue plus merge request sync. Multi-segment subgroup paths (group/subgroup/project) are supported, not just top-level projects. Locked to the public gitlab.com API: self-hosted GitLab instances are not supported.
Full source control
Repository listing, clone, direct push, and issue plus pull request sync, at the standard owner/repo path shape. Locked to the public Bitbucket Cloud API: Bitbucket Server and Data Center are not supported.
Issue tracking only
Native Jira issue keys (like PROJ-123) sync as external issues. Jira is not a code hosting provider, so there is no repository, clone, or push support. Must be a Jira Cloud site (an atlassian.net origin): Jira Server and Data Center are not supported.
A database-enforced unique constraint gives every organization exactly one connection per provider (one GitHub connection, one GitLab connection, one Bitbucket connection, one Jira connection), while letting all four coexist for the same organization. Connections belong to the organization, not the individual who created them. See Organizations & Teams for how tenancy and access control work across a workspace.
Connect
Not every operator wants to register an OAuth app before connecting a provider. CrewWork supports both paths as first-class citizens, not one as a workaround for the other.
A one-click connect flow for GitHub, GitLab.com, Bitbucket Cloud, and Jira Cloud, each using its own OAuth app rather than a shared bridge. Refresh tokens are encrypted at rest and rotate automatically on every use, and the OAuth state binds the initiating user, organization, and provider so a connection can never land in the wrong place.
A first-class path for self-hosted operators: connect GitLab, Bitbucket, or Jira with a personal or API access token and skip OAuth app registration entirely. GitLab accepts a token on its own; Bitbucket and Jira pair the token with the account email tied to it.
Your CrewWork account itself is not tied to any one code host. Create it or sign in with GitHub, GitLab.com, or Bitbucket Cloud OAuth, and link the other providers to the same account later from Settings. Signing in proves who you are; connecting a repository is a separate, organization-owned step. Jira Cloud is a connection only, never a sign-in option.
What syncs
External-issue sync understands each provider on its own terms. GitLab merge requests and Bitbucket pull requests sync alongside native issues, so HotFix triage and linking see the same review objects your team does.
| Provider | Native issues | Change requests |
|---|---|---|
| GitHub | Issues | Pull requests, authored and reviewed by CrewWork |
| GitLab.com | Issues | Merge requests, synced as external issues |
| Bitbucket Cloud | Issues | Pull requests, synced as external issues |
| Jira Cloud | Issue keys (like PROJ-123) | Not applicable: no code hosting |
One important detail
On GitLab.com and Bitbucket Cloud, CrewWork pushes branches directly and reads and syncs issues and merge or pull requests as external issues. It does not open merge requests on GitLab or pull requests on Bitbucket. Authoring and reviewing pull requests remains GitHub-only today.
One nuance for Bitbucket Cloud: issue sync depends on the repository’s built-in issue tracker being enabled. If a workspace administers issues elsewhere, for example through a connected Jira site, and has Bitbucket’s native tracker turned off, CrewWork skips issue sync for that repository and keeps syncing pull requests.
GitHub PR intelligence
GitHub is where CrewWork’s review automation goes deepest: a default-on webhook path turns every open or updated pull request into a reviewed one, with evidence posted directly to the PR itself.
Every GitHub pull request that is opened or updated with new commits automatically queues an AI code review. It is on by default, and can be turned off globally, per review domain (HotFix, Platform Self-Repair, suggestions, diagnostics), or per project. Reviews are idempotent, so a redelivered webhook never queues a duplicate.
The review comment reports CODEOWNERS resolution status and any changed paths with no listed owner, the PR’s owning project team plus any linked service-catalog owner teams, and a blast-radius read on the change: risk level, confidence score, index freshness, and counts of affected files, routes, tests, and workers.
Review coverage paginates up to 3,000 changed files instead of stopping at the first page, preserves original filenames across renames, and raises an explicit error rather than silently reviewing an empty file list when GitHub is unreachable.
A five-part quality gate (tests, coverage, security, code health, and live preview quality) posts as its own GitHub commit status alongside the review comment. Defaults require 80 percent minimum line coverage, a health score of 70 or higher, and zero new critical or high severity findings. See Testing & Quality Gates for how each part is scored.
CrewMate MCP server
CrewMate exposes a spec-compliant Model Context Protocol endpoint on your CrewWork deployment: a single JSON-RPC route implementing the MCP 2025-11-25 lifecycle (initialize, tools/list, tools/call) over stateless Streamable HTTP. Any MCP-capable external client, including Claude Desktop and Cursor, can connect to a project and read files, search code, and inspect git status without going through the workbench at all.
Every call rechecks the connecting actor’s live project-read permission. Requests authenticate with a session cookie or a scoped CrewWork API key, and the endpoint validates the request Origin and enforces its own request-size and rate limits, independent of the rest of the API.
All six tools are read-only: there is no write path and no shell access through MCP, the same read-only posture as the workbench’s code reader.
Error monitoring
Source providers connect your code. Sentry connects your running application’s errors to HotFix, CrewWork’s error-to-fix remediation lane, with its own triage, validation, and STAGED review flow.
See exactly how CrewWork keeps a model honest, explore the architecture, or reach out to talk it through.
Or view the architecture for the full technical picture.