Skip to content
RhodeCode
Fig. 1.0 Spec

Security specification

RC-SEC · rev 5.14.0

The posture an auditor asks about, stated plainly. Where a control is Enterprise-only it says so rather than implying the Community Edition has it.

Security specification for RhodeCode security
Area Supported Edition
Deployment Self-hosted on your own hardware or private cloud CE
Data residency Wherever you install it — no vendor region to choose CE
Encryption in transit TLS for HTTPS and SSH; Subversion write over HTTPS CE
Encryption at rest Provided by your storage layer; repositories are standard on-disk formats CE
Permissions Global → group → repository → path → user; explicit deny wins CE
Network binding Per-subject IP restrictions and VPN-only access CE
Authentication LDAP + Groups, Active Directory, PAM, HTTP headers, auth tokens CE
Enterprise SSO SAML 2.0 (Azure Entra ID, OneLogin, Duo), Atlassian Crowd, CAS, OAuth, 2FA EE
Branch protection Protected patterns; merge only after the approval rule is met EE
Audit Immutable log, 7-year default retention, streamable to an external SIEM CE
Telemetry None collected; the instance never contacts RhodeCode CE
Disclosure security@rhodecode.com; acknowledged and triaged, fix shipped in a release CE

Full requirements and tuning guidance in the system administration docs.

Fig. 1.1 Posture
1.1 Posture CE

The code never leaves your network.

RhodeCode is installed on hardware you control, in a jurisdiction you chose. There is no vendor tenancy to reason about and no region setting to get wrong.

Self-hosted on your own servers or private cloud
Encryption in transit over TLS for every protocol
Data residency follows the machine, not a vendor policy
Fully air-gapped installation supported
Tenancy Single tenant, yours
Transit TLS · HTTPS · SSH
Residency Your jurisdiction
Fig. 1.2 Permissions
1.2 Permissions Core: CE · Enterprise auth: EE

Grants at five levels, and deny always wins.

Inheritance flows down from the global default to the individual user, and an explicit deny anywhere on that chain ends the evaluation. Bind subjects to IP ranges so a stolen credential is not sufficient on its own.

Path-based permissions, including inside Mercurial repositories
Per-subject IP restrictions and VPN-only access
Branch protection with force-push controls
Access simulation before a change is committed
Levels Global → group → repo → user
Conflicts Explicit deny wins
Auth LDAP · AD · SAML · CAS · OAuth · 2FA
Fig. 1.3 Evidence
1.3 Evidence CE

An answer for the auditor, not a support ticket.

Every authentication, permission change, push and merge is recorded in an immutable log you can export or stream, so the evidence is yours to produce.

Immutable audit log with a 7-year default retention
Export to CSV or stream to an external SIEM
Access logs and activity reports per repository and user
Published vulnerability disclosure process with a named contact
Retention 7 years by default
Export CSV · SIEM stream
Disclosure security@rhodecode.com
Fig. 3.0 Next

The same posture, stated for procurement

Trust and security collects the shared-responsibility split, the subprocessor position and the disclosure process in the form a security review asks for.