| Change Stack runs on four providers, and they do not offer the same thing. Reading an artifact works everywhere; writing back to the pull request does not. This page is the reference for where each capability works — the task pages explain how each one behaves.

​

The four providers

Because self-hosted aliases normalize, a self-hosted host generally behaves as its cloud counterpart in the matrix below. The exceptions are called out in the per-provider notes.

​

Reading the matrix

Availability in this table is about the provider. Individual capabilities carry their own conditions on top of it — your plan, your provider write access, and whether the displayed artifact is current.

​

Capability matrix

​

Reading and access

​

Review actions

​

Chat and discussions

Slack and Discord discussions are not gated by the code provider — their availability depends on the connected Slack or Discord destination and its resolved channel access. See Collaborate in Slack and Discord. Chat is unavailable on Azure DevOps because Change Stack artifacts there are read-only. Write-access requirements apply to providers where chat is supported.

​

GitHub

GitHub is the most complete provider path. It is the only one with direct merge and merge-queue controls, it is the only one where a draft review lives natively in the provider, and it is the only one whose timeline is built from real provider events rather than synthesized review checkpoints. Commenting also requires OAuth consent for the repository: public_repo or repo for a public repository, and repo for a private repository. A connection with only read:org and user:email cannot post comments, even on a public repository. Change Stack prompts you to reconnect when that consent is missing. Reconnecting does not grant repository permissions you do not already have or change the write-access requirements for other actions. Two bounds are worth knowing when a pull request is very large. GitHub compare recovery switches away from the API at 300 files, and it refuses a raw diff beyond 10,000 files, 20 MiB of retained patches, a single line over 1 MiB, or a fetch that takes longer than 10 seconds. Past those bounds the diff material for that artifact is not recoverable through that path. Self-hosted GitHub carries one gap: older instances may not report whether a review thread was resolved. The comments themselves are still shown, so the history is complete — the resolved marker on a thread is what can be missing.

​

GitLab

GitLab supports reading, inline and file-level review comments, submitting reviews, and applying committable suggestions, but two mechanics differ from GitHub. Draft reviews are held by CodeRabbit rather than by GitLab. They are invisible in GitLab until you submit them, and an unsubmitted draft expires after 24 hours. Suggestion application uses different mechanics from GitHub’s, so a suggestion that applies on one provider is not guaranteed to apply the same way here. There is no direct merge or merge-queue control on GitLab, and the timeline contains synthesized review checkpoints rather than native merge-request event history.

​

Bitbucket

Bitbucket supports reading and review authoring on both Bitbucket Cloud and Bitbucket Data Center, with several gaps that apply to both. Artifacts cannot be read anonymously — a Bitbucket Change Stack link always requires authentication, even for a public repository. Review authoring does not support file-level comments without a line anchor, so every comment needs a line to attach to. Committable suggestions are refused. And Change Stack chat does not dispatch repository inspection through a Bitbucket provider client, so chat answers here do not draw on repository content the way they do on GitHub and GitLab. Like GitLab, Bitbucket draft reviews are held by CodeRabbit, stay invisible in the provider until submission, and expire after 24 hours. There is no merge control, and the timeline is synthesized.

​

Azure DevOps

Azure DevOps also does not receive the live freshness comparison the other active provider paths get, so an Azure artifact cannot tell you that the live head has moved past the snapshot you are reading. Check the pull request in Azure DevOps itself before drawing conclusions from an artifact’s age. See Snapshots and freshness. The timeline on Azure DevOps, as on GitLab and Bitbucket, contains synthesized review checkpoints rather than native provider event history.

​

Generated links on non-GitHub hosts

When Change Stack falls back to a reduced read path, a link it builds out to the provider can keep a GitHub-shaped URL even on a non-GitHub host. If a link out of Change Stack points somewhere that does not exist on your provider, open the pull request from the provider’s own interface instead.

​

What’s next