How ProPR works.

ProPR is self-hosted, Apache 2.0, and built around GitHub. These are the operational and security questions that decide whether it fits your infrastructure, with links to the documentation for the exact wiring — and the source when you want the final word.

No hand-waving

ProPR runs on your own infrastructure. The delivery layer, isolation model, logs, and credentials stay in the stack you run, open to inspection.

Source-visible Self-hosted Apache 2.0

Product path overview

For what ProPR is and why it centers on pull requests, start with the homepage FAQ. Configuration detail lives in the docs.

What ProPR connects to.

Does ProPR work with GitLab or Bitbucket?

ProPR supports GitHub. The loop uses GitHub's pull requests, review comments, status checks, and comment controls. GitLab and Bitbucket fall outside the current product boundary.

Does it run against GitHub Enterprise Server?

ProPR targets GitHub.com today. GitHub Enterprise Server is not supported. If your organization standardizes on a self-hosted GitHub, that is the constraint to weigh first.

Do we have to use the hosted ProPR GitHub App?

No. Bring your own GitHub App and skip the hosted relay entirely, or use the shared-app token relay through ProPR Connect for the fastest start. Either way GitHub access uses scoped permissions — contents, issues, pull requests — that you grant.

How events reach a stack on a private network.

Does connecting to GitHub open an inbound port into our network?

By default, no. Your stack makes an outbound connection to ProPR Connect and GitHub events flow back down it, so nothing on your network has to accept inbound traffic. If you would rather receive webhooks directly, run your own GitHub App and point it at an endpoint you control. The relay exists precisely so a stack on a laptop, workstation, or internal network needs no public ingress.

Who holds the keys, and can we revoke access?

You do. With the shared-app relay, your stack holds only a revocable relay credential — the shared GitHub App's private key never lands in your deployment, and you can revoke the credential at any time. With your own GitHub App, the key is yours and stays under your control. The trust and security page maps the full boundary.

Does ProPR Connect see our code?

Connect relays full GitHub webhook payloads, including any code included in an issue or review comment. It clears webhook payloads after successful delivery and retains delivery statistics separately. The optional MCP gateway also processes tool arguments and results, which can contain prompts, source code, context, and diffs. Direct MCP bypasses Connect. Agents and execution remain on your instance.

Where agents actually run.

Isolation boundary Main protected
Repositorymain checkout
Task workspace Arunning
propr-1689branch Docker containeragent runtime
Task workspace Brunning
propr-1690branch Docker containeragent runtime
Pull request Areviewable result
Pull request Breviewable result
Each task receives its own worktree, branch, and Docker container before the result reaches GitHub.
How is each agent run sandboxed?

Every implementation gets its own Git worktree, branch, and Docker workspace. The main checkout is never edited in place; the agent works in isolation and the result returns through commits and a pull request. ProPR performs the branch, commit, push, and PR steps deterministically — see the isolation model.

What does ProPR need on the host?

A Docker-capable Linux host. ProPR uses the host's Docker to launch each agent in its own container, alongside the app, workers, and local state directories. The self-hosting page covers the runtime shape, and the deployment docs spell out the exact requirements and access it needs.

Are agents cut off from the network by default?

Agent containers have normal outbound access by default. The optional allowlist firewall restricts traffic to required endpoints such as the model provider, GitHub, and DNS. It needs elevated container privileges, so deployments that require network restrictions must enable it deliberately.

What the model is given, and what it costs.

How does ProPR decide what code to send the model?

It builds a context preview before planning. ProPR ranks files using git history, path signals, and short model-written summaries, combines them with the files you name and any attachments, and shows the selection so you can adjust it. That gives the model the code it needs without dumping the repository — detailed in context gathering.

Does indexing ship our code to a cloud index?

No. Indexing and the file summaries run on your host, using the agent you already configured. There is no separate hosted vector service — the repository knowledge stays in the stack you run.

What stops a large monorepo from blowing up token cost?

The preview estimates size and cost up front, then keeps the high-value paths and drops low-value files. You see the estimate and the included files before planning starts, so a run never silently turns into an enormous prompt.

What ProPR knows about your checks.

Does ProPR read our CI logs?

No. ProPR knows whether checks pass — an Ultrafix loop waits for green before it continues — but it works from the pull request conversation and does not read your CI logs. When a build or test fails, paste the failing output into a PR comment and ask for a fix; ProPR routes that into another isolated run and lands the correction as a follow-up commit on the same branch.

After it resolves a merge conflict, does it verify the build?

It resolves the conflict and pushes the result; your existing checks then run on that branch like any other commit. Your CI remains authoritative. If the merge needs more than a clean resolution, treat it as you would any failing check and ask for a fix in the PR.

What stays, and what gets cleaned up.

What stays on our infrastructure?

Repository clones, task history, logs, provider credentials, and agent containers all live in your stack. GitHub receives branches, pull requests, comments, and status updates; the selected agent provider receives the prompt and code context for the task. MCP results also reach your chat host and, on the hosted route, Connect. The web UI and CLI keep the remaining history attached to each task.

Does ProPR clean up after itself?

ProPR removes each run's Git worktree and Docker container after the task completes, so working state does not pile up from normal operation. Task records and logs stay in your stack so the audit trail survives — history remains intact until you prune it.

Read the source, or run it yourself.

The honest test is the source and a running stack.