Supported Runtime and Operating Modes
Canonical support contract for PatchPatrol runtime baselines, deployment modes, and support tiers.
Supported Runtime and Operating Modes
This page is the canonical support contract for PatchPatrol runtime baselines and operating modes.
Use it when you need a clear answer to:
- what is first-class today
- what is supported with caveats
- what is out of scope
PatchPatrol is self-hosted-first. Do not infer support posture from scattered README, roadmap, or operator notes when this page says otherwise.
Operating-mode support tiers
| Operating mode | Tier | Current contract |
|---|---|---|
| GitLab merge-request review job with artifact-first rollout | First-class | This is the documented public path. Start with the latest release image, AI_REVIEW_FEEDBACK_MODE=artifact-only, and readiness checks before enabling optional delivery modes. |
| Self-hosted GitLab runner with a customer-controlled provider endpoint | First-class | This is the recommended production posture for privacy-sensitive teams. Keep the runner, PatchPatrol runtime, and provider endpoint inside the customer boundary. |
Local source or container execution for dry-run, working-tree, staged, or branch review | Supported with caveats | Supported for evaluation, local iteration, and validation. Treat it as an operator or developer workflow, not as the canonical production rollout contract. |
| Customer-managed container execution of the official PatchPatrol image | Supported with caveats | Supported when you preserve the same runtime contract as the GitLab job: mounted workspace, explicit environment variables, writable artifact path, and provider reachability. PatchPatrol remains a CLI/container process, not a long-running hosted control plane. |
| Restricted-network or air-gapped-adjacent deployment | Supported with caveats | Supported when you can mirror or pin required images, keep GitLab/provider reachability inside the customer boundary, and satisfy readiness checks locally. A turnkey zero-egress distribution bundle is not published as a first-class path today. |
| Public hosted API provider path | Supported fallback | Supported when teams accept the trust-boundary tradeoff. Use it for quick evaluation or temporary fallback, not as the primary privacy-first posture. |
| Vendor-hosted PatchPatrol control plane or PatchPatrol-managed SaaS data plane | Out of scope | PatchPatrol does not currently publish a hosted control plane or vendor-managed review service. |
| Non-GitLab primary integration surfaces | Out of scope | The current support contract is for GitLab-centered review flows. |
Current baseline matrix
Support is evidence-backed and intentionally narrow. Where the repo does not prove a broader version matrix yet, this page states the current baseline instead of guessing.
| Layer | Supported baseline today | Why this is the current line |
|---|---|---|
| GitLab | GitLab merge-request pipelines using the artifact-first contract and the standard MR CI variables consumed by PatchPatrol | Public docs, examples, and readiness flows are GitLab-centered. A numeric GitLab version floor is not published yet. |
| Python | Python 3.13+ for source execution | pyproject.toml requires >=3.13, and repository CI validates on Python 3.13. |
| Container image | Official runtime image based on python:3.13-slim-bookworm | The root Dockerfiles and container-build tests lock this as the supported base path. |
| Container architecture | Standard Linux OCI images for linux/amd64 and linux/arm64 release publication | The release workflow publishes both architectures; other runtime architectures are not claimed as first-class. |
| Runtime shape | Customer-managed CI job or container process that can mount repo/workspace state and write .ai-review artifacts | PatchPatrol is a CLI/container runtime, not a hosted review control plane. |
| Provider reachability | The configured provider endpoint must be reachable from the same runner or container that executes the review job | Readiness checks and trust-gate behavior assume direct runtime-to-provider connectivity. |
First-class rollout contract
Treat the following as the supported starting point:
- Use GitLab merge-request pipelines.
- Use the official PatchPatrol
latestimage tag unless you need a specificvX.Y.Zpatch version pinned. - Keep the first rollout artifact-first.
- Prefer a customer-controlled or self-hosted provider endpoint for production.
- Enable MR feedback or semantic mode only after readiness checks and the first review path are stable.
If your environment deviates from that path, use the support-tier table above before treating it as production-ready.
What this page does not claim
This page intentionally does not claim:
- a numeric GitLab version matrix beyond the documented merge-request pipeline contract
- a turnkey fully air-gapped distribution bundle
- a vendor-hosted PatchPatrol service
- non-GitLab primary integrations
Those may be discussed elsewhere as roadmap or commercialization ideas, but they are not first-class support commitments today.