The most regulated industries on earth keep their code here.
Defence, finance, medical devices and national labs each hand engineering a different set of hard constraints — and the same platform has to satisfy all of them. Below: which constraint binds in which sector, and what it takes to meet it.
Financial services
Trading systems, ledgers and settlement code under change control that has to satisfy internal audit and a regulator who does not accept "the tool does not support that".
- Regulation
- MiFID II · SOX · DORA
- Repositories
- 2,000–8,000
- Binding constraint
- Segregation of duties, provable
- VCS mix
- Git + legacy SVN in risk
- Reviewer rules encode segregation of duties as a platform rule, not a policy document
- Immutable audit trail with long retention, streamed to your SIEM
- IP-restricted access for contractors and offshore teams
- Explicit deny survives group membership changes at offboarding
Cloud-only platforms cannot answer where settlement code physically resides, and Git-only tools leave the legacy risk code outside the audit boundary entirely.
Defence & government
Classified and export-controlled development on networks with no outbound connectivity of any kind — where an unexpected outbound connection is not a privacy concern but a security incident.
- Regulation
- ITAR · EAR · NIST 800-171
- Repositories
- 400–3,000
- Binding constraint
- No outbound connection permitted, ever
- VCS mix
- All three, often per-programme
- Fully offline installation and upgrade from a signed bundle
- No telemetry, and no connection to RhodeCode by design
- Deployment on hardware you physically control, in your facility
- Nationality and IP-scoped access for export-controlled repositories
Every managed platform requires egress for licensing or telemetry. An air-gapped install is not a configuration option there; it is outside the product.
Automotive & embedded
Decades-old toolchains pinned to Subversion running beside modern Git projects, in one organisation and one audit scope, on programmes measured in vehicle generations.
- Regulation
- ISO 26262 · A-SPICE
- Repositories
- 900–4,000
- Binding constraint
- Cannot migrate off SVN
- VCS mix
- Git + SVN + acquired hg
- All three systems under one permission model, no conversion required
- Large binary and artifact handling for calibration data
- Long-lived release branches with protection rules per programme
- Path-level control inside monolithic SVN repositories
Git-only platforms force a migration the certified build environment cannot absorb, so the legacy repositories stay ungoverned on a separate server.
Healthcare & life sciences
Validated software where every change needs a traceable reviewer, a written rationale and a signature that survives a regulatory submission years later.
- Regulation
- FDA 21 CFR 11 · IEC 62304
- Repositories
- 200–1,200
- Binding constraint
- Evidence must be exportable
- VCS mix
- Git, some hg in research
- Signed commits required on protected branches
- Approval evidence exportable as a submission artifact
- Fine-grained access for external CROs, expiring by default
- Reviewer rules that name a qualified approver per code area
Platforms that treat review as a social feature cannot produce the approval evidence a submission requires without a bolt-on audit tool.
Research & national labs
Large mixed-VCS deployments, high user churn as researchers rotate, and a budget that does not survive per-seat cloud pricing across thousands of accounts.
- Regulation
- Varies · often ITAR-adjacent
- Repositories
- 3,000–40,000
- Binding constraint
- Cost per seat at scale
- VCS mix
- Everything, historically
- Free Community Edition with unlimited users and repositories
- Discounted Enterprise licensing for institutions
- LDAP and SAML against directories you already run
- Indexed search across an repository set nobody can hold in their head
Per-seat cloud pricing across a rotating population of thousands is simply unaffordable, and free tiers cap exactly the thing labs need most.
Aerospace & space
Certification evidence under DO-178C and export control, on programmes that will outlive the tools they started on by a decade or more.
- Regulation
- DO-178C · ITAR
- Repositories
- 300–2,000
- Binding constraint
- Readable in twenty years
- VCS mix
- SVN heavy, Git growing
- Traceable approvals assembled into certification packs
- Export-controlled access scoped by nationality and IP range
- Standard repository formats on your disks — no vendor lock
- Air-gapped operation for classified programme segments
A proprietary hosted format is a twenty-year liability. If the vendor changes terms or disappears, the certification evidence goes with it.
Energy & utilities
Grid control, SCADA and safety-instrumented code on operational networks that must never touch the corporate network, let alone the internet.
- Regulation
- NERC CIP · IEC 62443
- Repositories
- 150–900
- Binding constraint
- IT/OT separation
- VCS mix
- SVN and Git, split by zone
- Air-gapped deployment inside the OT network
- Hard separation between IT and OT repository groups
- Change evidence in the form NERC CIP audits expect
- Vendor access that is technically impossible, not merely prohibited
Cloud platforms cannot be deployed inside an OT zone at all, so utilities end up running an ungoverned second server there.
Telecom
Carrier platforms assembled from acquisitions, vendor drops and internal builds, where three version control systems arrived with three companies.
- Regulation
- Lawful intercept · national
- Repositories
- 1,500–6,000
- Binding constraint
- Acquisition churn
- VCS mix
- All three, permanently
- Absorb an acquired code base under your permissions on day one
- One review workflow regardless of which company wrote the code
- Repository groups that mirror the organisation, with inheritance
- Per-vendor scoped access with expiry
Consolidating every acquisition onto one VCS before it can be governed means the governance never arrives.
Semiconductor & IP
Design IP worth more than the company, shared selectively with foundries and partners who must see one block and nothing else.
- Regulation
- Export control · NDA regime
- Repositories
- 400–2,500
- Binding constraint
- Path-level partner access
- VCS mix
- SVN heavy, Perforce-adjacent
- Path-level permissions so a partner sees one block, not the tree
- IP binding so credentials only work from the partner network
- Audit trail of every read as well as every write
- No third party ever holds the design database
Repository-level permissions are too coarse for selective IP sharing, so teams resort to manual exports that nobody can audit.
Who runs RhodeCode
A register of named customers by sector. Every organisation here chose a platform that keeps source code inside its own perimeter.
What people actually buy it for
Sector matters less than the situation. These are the eight that come up in almost every evaluation.
- 01 Absorb an acquisition without a migration project The company you just bought runs Mercurial. Bring its repositories under your permission model on day one, and decide about converting them later — or never.
- 02 Develop on an air-gapped network Install from an offline bundle, upgrade from an offline bundle. In an air-gapped install the application opens no outbound connection, so there is nothing to justify to the security team.
- 03 Prove segregation of duties Reviewer rules make the policy machine-enforced rather than documented: the author cannot approve, and the merge is blocked until the named owners have.
- 04 Give contractors the narrowest possible access Path permissions plus an IP binding mean a third party sees one directory, from one network, and a leaked credential alone achieves nothing.
- 05 Retire Subversion at the pace of the slowest toolchain Host both, move teams individually, keep the legacy build green throughout. No cut-over weekend and no frozen release.
- 06 Govern code written by AI agents Record which agent produced each change, under which prompt and model, so an auditor can tell machine-written code from human-written code.
- 07 Keep multi-gigabyte assets in version control Git LFS, Mercurial largefiles and very large Subversion repositories, under the same review workflow as the source beside them.
- 08 Run one review standard across every team Git, Mercurial and Subversion teams get identical pull requests, identical inline review and identical merge gates — so the standard is one document, not three.