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. Prefer the pinned GitLab component include when it is available on the same GitLab instance; otherwise use the direct job fallback with the official PatchPatrol latest image tag, artifact-only feedback, 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.
- Prefer the pinned GitLab component include when it is available on your GitLab instance; use the direct
latestimage job only as a fallback or when you need a specific custom image workflow. - 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.
Self-Hosted License v1
Self-Hosted License v1 authorizes Licensed Review Work in a customer-managed runtime. Before PatchPatrol extracts review context or calls a real provider, the configured Signed License is evaluated locally for trust, validity, and the requested feature entitlement. The license check does not call a vendor-hosted licensing or review service.
This is a Commercial Compliance Boundary: it gives customers and support a clear, inspectable authorization result for commercially licensed review work. It is not anti-tamper protection and does not claim to prevent a determined operator from bypassing the check through source modification or patched Docker images.
Managed Service Usage is a separate commercial and operating model. Self-Hosted License v1 neither requires nor implies a PatchPatrol-managed service; the vendor-hosted control-plane and data-plane modes remain out of scope as stated in the support table above.
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.