Your data and Intelligence
stay where you decide
GitMir runs in three deployment modes, and they differ in exactly one thing that matters: which boundary your data crosses, and which it does not — the repository, and the business, customer and operational data your agents work on. This page states that plainly, mode by mode, without adjectives.
What crosses which boundary
| What | Cloud | Private Source | Private deployment |
|---|---|---|---|
| Where the source code is read | On GitMir’s servers, from your git host | Inside your network, by the GitMir Local Connector | Inside your boundary, by your own GitMir installation |
| Where derived intelligence is stored | On GitMir’s servers | Synchronized outward to GitMir and stored there | Inside your boundary |
| Where MCP answers come from | GitMir’s MCP endpoint | GitMir’s MCP endpoint, from the synchronized intelligence | A private MCP endpoint inside your boundary |
| What leaves your network | The code GitMir reads, and the questions your people and agents ask | Derived intelligence and the questions asked — not the source code | Only requests to hosts your administrator names, such as a model or a mail gateway; any other request is refused before it is sent |
| Business, customer and operational data you connect | Read by GitMir | Stays in your environment | Stays inside your boundary |
| Where product analytics go | To GitMir: which actions happen and when, not your code | To GitMir, as in Cloud | Stay inside your boundary, or are switched off; a weekly count leaves only when a person exports it |
| Who operates it | GitMir | You run the connector; GitMir runs the service | You, on your infrastructure, with GitMir’s help as your contract sets out |
In Private Source your source code stays with you, but derived intelligence is synchronized to GitMir 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 a private deployment.
Public Intelligence and private
Intelligence never mix
GitMir publishes Intelligence built from open-source systems under their own licences. That work and your work are separate systems, and neither reaches the other.
Nothing of yours becomes public
Your Intelligence is never added to the public registry, never shown to another customer, and never used to answer a public question. Publishing anything of yours would take an explicit act by you, and there is no path that does it automatically.
Nothing of yours trains anything
Your sources and the Intelligence derived from them are not used to train models, not used to improve the public registry, and not pooled with other customers' work. They exist to answer your questions.
THE PUBLIC REGISTRY IS BUILT ONLY FROM EXPLICITLY LICENSED OPEN-SOURCE REPOSITORIES. IT IS A SEPARATE SYSTEM, NOT A SHARED ONE.
Pick the boundary first
Everything else follows from it
Fastest start
You authorize a repository and GitMir 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.
Source code stays in your environment
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.
Everything inside your boundary
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.
What we do not do
with what you connect
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.
The operational detail,
in a reviewed document
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.
Hosting and regions
Where the service runs and where data is stored.
Encryption
In transit and at rest, with the specifics rather than the adjective.
Retention and deletion
What is kept, for how long, and what disconnecting a repository removes.
Sub-processors
The current list, and how changes to it are notified.
Access control
Who inside GitMir can reach customer data, under what approval, and how it is logged.
Business continuity
Backups, recovery objectives and incident response.
What we hold,
and what we do not
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.
Found something?
Tell us before you tell anyone else
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.
Start where your policy allows
Cloud to try it today, Private Source if the code cannot leave, Enterprise if nothing may.