GitMir runs in three deployment modes, and they differ in exactly one thing that matters: which boundary your source code crosses, and which it does not. This page states that plainly, mode by mode, without adjectives.
| What | Cloud | Private Source | Enterprise |
|---|---|---|---|
| Repository source code | Read by GitMir Lab | Stays in your environment | Stays in your environment |
| Processing of that source | GitMir Lab | GitMir Local Connector, inside your infrastructure | Your private GitMir deployment |
| Derived intelligence | Hosted by GitMir Lab | Synchronized to GitMir Lab | Stays inside your boundary |
| MCP endpoint | GitMir Lab | GitMir Lab | Private MCP, inside your boundary |
| Questions your team asks | Answered by GitMir Lab | Answered by GitMir Lab | Answered inside your boundary |
In Private Source your source code stays with you, but derived intelligence is synchronized to GitMir Lab so that your team and agents can query it. That is a real transfer and we name it, because a security page that overstates its guarantee is worth less than one that states a smaller guarantee accurately. If nothing at all may leave, the mode you want is Enterprise.
You authorize a repository and GitMir Lab reads it directly. Suitable when the code is already hosted with a third party you trust and the speed of getting started matters more than isolation.
The GitMir Local Connector runs inside your infrastructure and processes only the sources you permit. Your code is never transmitted; the intelligence derived from it is synchronized to GitMir Lab.
A private GitMir deployment with a private MCP endpoint, in your VPC, on-premises or in an isolated environment. Nothing traverses a GitMir-operated service.
IF YOUR POLICY NAMES A BOUNDARY, START THE CONVERSATION THERE — THE MODE IS A PROCUREMENT DECISION, NOT A PRICING TIER.
Nothing you connect is used to train models, and nothing derived from it is used to improve the service for anyone else.
Your sources and the intelligence derived from them are not sold, licensed or shared with third parties.
It runs inside your boundary and it is owned by you.
SSO and RBAC are available on Enterprise deployments.
THESE ARE CONTRACTUAL COMMITMENTS, NOT MARKETING LINES — THEY BELONG IN YOUR AGREEMENT, AND WE WILL PUT THEM THERE.
Hosting, encryption, retention, sub-processors and continuity are the questions your security team will ask in writing, and they deserve an answer in writing — reviewed, dated and specific to the mode you are deploying. We send that rather than paraphrase it on a marketing page.
Where the service runs and where data is stored.
In transit and at rest, with the specifics rather than the adjective.
What is kept, for how long, and what disconnecting a repository removes.
The current list, and how changes to it are notified.
Who inside GitMir can reach customer data, under what approval, and how it is logged.
Backups, recovery objectives and incident response.
We will not list a certification we do not hold, and we will not leave the question unanswered either. Ask us directly and you will get the current status in writing, including what is in progress and what is not planned. It is published here as soon as there is something true to publish.
Write to [email protected] with the details and how to reproduce it. We will acknowledge, keep you updated while it is being fixed, and credit you if you want to be credited. Please give us a reasonable window to fix an issue before disclosing it publicly.
Cloud to try it today, Private Source if the code cannot leave, Enterprise if nothing may.