Self-hosted repository management, honestly reviewed. Written for technical founders and small teams tired of paying per-seat for something they could own outright.

TL;DR

What it is: A self-hosted repository management server for Git, Subversion, and Mercurial — no database, no Apache, no external dependencies required [README][2].
Who it’s for: Small to mid-sized teams that need centralized, on-premises repository hosting with access control, and especially teams running legacy Mercurial or SVN repositories alongside Git [2].
Cost savings: GitHub Team runs $4/user/month; a 10-person team pays $40/month. GitLab’s paid tier starts at $29/month. SCM Manager runs on a $5–10/month VPS and the software itself is free [4].
Key strength: Dead-simple deployment — no database to provision, no web server to configure. One installer, one Java process, done [README][1].
Key weakness: Not a DevOps platform. No built-in CI/CD, no container registry, no issue tracker. For repository hosting it works; for everything else, you’re wiring in external tools [2][5].
License note: Multiple review aggregators incorrectly list SCM Manager as MIT-licensed [1][4]. The actual license is AGPL-3.0-only [merged profile][README]. For commercial SaaS use, this distinction matters significantly — read it before deploying.

What is SCM Manager

SCM Manager is a self-hosted source code management server that gives you a web UI and REST API for managing repositories and developer access. It supports Git, Subversion (SVN), and Mercurial (Hg) from a single interface — meaning you don’t need three separate servers if your organization is mid-migration from SVN or Mercurial to Git [2][README].

The project is backed by Cloudogu GmbH, a German software company that also maintains the Cloudogu EcoSystem platform. SCM Manager is the open-source community product; Cloudogu sells enterprise support and commercial extensions on top [1][homepage].

What makes it genuinely different from Gitea or Gogs is two things. First, the multi-VCS support — Git, SVN, and Mercurial all managed from one admin panel [README]. Second, the zero-dependency deployment — no database required, no Apache, no Redis, no PostgreSQL. SCM Manager ships as a self-contained Java application, which is unusual in a category where most competitors require a full Postgres stack [README][1].

The project has 12,607 commits according to one aggregator [3], and the current codebase targets Java 11 with Gradle as its build system. GitHub shows 167 stars in the merged profile, though third-party aggregators have shown higher counts — the official star count should be verified against the GitHub repository directly.

Why people choose it

There are no published user reviews on GetApp, SoftwareAdvice, or FitGap for SCM Manager at the time of this writing [1][2][4]. That’s a genuine data gap — it means the “social proof” signals you’d normally use to calibrate a tool’s real-world reception don’t exist here. What does exist is positioning context from the tool’s own documentation and independent analysis from code review tooling comparisons.

The case for SCM Manager over hosted alternatives comes down to three arguments:

Zero-infrastructure overhead. Gitea and Gogs also run lightweight, but they still want a database. SCM Manager’s embedded storage model means you can spin up a working instance faster, with fewer moving parts to break [README][1]. For a 5–15 person team that just needs private repository hosting, this is genuinely attractive.

Legacy VCS support during migrations. Organizations that built workflows on Subversion or Mercurial over the past decade face a real problem: most modern self-hosted Git forges don’t support SVN or Mercurial at all. SCM Manager is one of the few tools that lets you run Git, SVN, and Mercurial repositories in parallel under one access control system while you migrate [2]. The Augment Code analysis [5] explicitly categories SCM Manager as a “specialized review system” alongside Gerrit and RhodeCode — as opposed to a general-purpose platform like GitLab.

Plugin-based extensibility without forking. Over 50 plugins exist for integrating Jenkins, Jira, Redmine, PlantUML, Prometheus Metrics, LDAP, and CAS. These are installable from a plugin center rather than requiring code changes [1][4]. For teams that need to wire repository events into an existing ticketing or CI system, this reduces custom glue code.

The honest counterweight: SCM Manager has a smaller community footprint than Gitea (which has tens of thousands of GitHub stars), less documentation outside of its own official docs, and no SaaS option if you decide self-hosting is too much operational overhead. The tool exists for a specific scenario — small teams needing multi-VCS, zero-dependency, self-hosted repository management — and it doesn’t try to be more than that.

Features

Based on the README and official documentation:

Repository management:

Git, Subversion, and Mercurial supported natively [README]
Web-based repository browsing, file viewer, and diff view [1][4]
Browser-based code editor [1][4]
Import of existing repositories [docs]
Granular repository-level permissions per user and group [README][2]

Authentication and authorization:

Built-in user and group management [README]
LDAP integration via plugin [1][4]
Central Authentication Service (CAS) support via plugin [1]
Fine-grained permission model — assign specific access levels per repository [README][2]

REST API:

Level 3 RESTful Web Service API (JSON and XML) [README]
Covers all core functions for automation and integration [README]
Available endpoints for repository provisioning and administration [2]

Plugin ecosystem:

50+ available plugins [1][4]
Jenkins CI/CD integration [1][4]
Jira and Redmine issue tracker linking [1][4]
Prometheus metrics export [1]
Workflow-controlled code reviews [1][4]
PlantUML diagram rendering in repository [1]

Deployment options:

Docker and Helm for containerized deployments [README][merged profile]
Native installers for Linux (RPM, DEB), Windows, macOS [1][4]
No external database required — embedded storage [README]
No web server required [README]

UI:

Web interface with dark/light contrast modes [1][4]
Available in English and German [1][docs]

What’s not there:

No built-in CI/CD pipeline [2][5]
No container registry [2]
No built-in issue tracker (must integrate Jira or Redmine via plugin) [2]
No artifact management [2]

Pricing: SaaS vs self-hosted math

SCM Manager has no SaaS tier. It’s free software under AGPL-3.0, deployed on your own infrastructure. The cost model is: software free, server costs money, your time costs money.

What you pay for hosted alternatives:

Service	Pricing
GitHub Team	$4/user/month ($40/month for 10 people)
GitLab (paid tier)	Starts at $29/month
Bitbucket Cloud	$3.30/user/month ($33/month for 10 people)
Bitbucket Data Center	Enterprise pricing, typically $2,300+/year

[Pricing data from SoftwareAdvice comparisons][1]

What you pay for SCM Manager:

Software: $0 (AGPL-3.0)
VPS with 2GB RAM (Hetzner, Contabo, Linode): $5–10/month
Domain + TLS (Caddy handles this automatically): ~$10/year

10-person team math over 12 months:

GitHub Team: 10 × $4 × 12 = $480/year
SCM Manager self-hosted: ~$10/month VPS = $120/year
Savings: ~$360/year

For a 25-person team:

GitHub Team: 25 × $4 × 12 = $1,200/year
SCM Manager self-hosted: same $120/year VPS
Savings: ~$1,080/year

The math gets more compelling the larger the team, because SCM Manager’s server cost doesn’t scale with headcount. One VPS handles many users — you pay once for the infrastructure.

AGPL-3.0 caveat on commercial use: The AGPL license requires that if you run SCM Manager as a network service and modify its source code, you must make those modifications available. For most teams using SCM Manager internally as a repository server with no code changes, this doesn’t matter. For SaaS builders thinking about embedding it in a product, consult a lawyer before assuming it’s MIT-style free [merged profile][2].

Cloudogu GmbH offers enterprise support with SLA-backed contracts — pricing is not published and requires contacting them directly [1][2].

Deployment reality check

The README’s core pitch — “no Apache and no database installation required” — holds up. Deployment is straightforward compared to GitLab (which wants 8GB+ RAM and a full PostgreSQL stack) [5].

What you actually need:

A Linux VPS with 1–2GB RAM minimum (2–4GB recommended for multi-user instances)
Java 11 (or Docker, which bundles the JVM)
A reverse proxy for HTTPS (Caddy or nginx)
A domain name

What you don’t need:

PostgreSQL or MySQL
Redis or Memcached
Apache or nginx as an app server (only needed for HTTPS termination)

Installation paths:

Docker: docker run with the official image — fastest path [README][merged profile]
Helm: for Kubernetes deployments [merged profile]
Native packages: RPM for RHEL/CentOS/Fedora, DEB for Debian/Ubuntu, MSI for Windows [1][4]
macOS: available installer [4]

What can go sideways:

Java-based applications have occasional memory management quirks under load. Monitor heap usage after initial deployment with real repository sizes.
Mercurial must be installed separately on the host system if you’re using Mercurial repositories — it’s not bundled [README].
Plugin compatibility with major version upgrades. The plugin center manages this, but check plugin compatibility before upgrading SCM Manager itself.
The FitGap analysis [2] notes that “larger organizations may need to validate feature coverage for regulated environments” — advanced audit dashboards and fine-grained compliance reporting require external SIEM tooling.
The last commit date shown on some aggregators is February 2023 [3], which would indicate low activity. This should be verified against the GitHub repository before making a deployment decision.

Realistic time for a technical user on Docker: 20–40 minutes to a working HTTPS instance. For someone who’s never run a Java application on Linux: 2–3 hours with troubleshooting.

Pros and cons

Pros

Zero external dependencies. No database, no cache, no web server. One process to run, one process to monitor, one process to back up [README]. Simpler than every Git forge competitor that requires Postgres.
Multi-VCS support under one roof. Git, SVN, and Mercurial from one admin panel. If your team is migrating from SVN or running legacy Mercurial repos, this is the only self-hosted option that doesn’t require parallel infrastructure [2][README].
Genuinely free deployment. AGPL-3.0, no per-seat cost, no “community edition” limitation on core functionality [1][README].
50+ plugins. Jenkins, Jira, Redmine, LDAP, CAS, Prometheus, PlantUML — installable from a plugin center without touching code [1][4].
Level 3 REST API. Mature enough for repository automation and provisioning scripts [README][2].
Cross-platform. Linux, Windows, macOS, Docker, Kubernetes — actual installer packages for each, not just “run it on Linux and figure out the rest” [1][4].
Browser code editor included. Small thing, but useful for quick edits without cloning [1][4].
Dark mode. Listed specifically in multiple reviews as a differentiator, which says something about the baseline quality of competing tools’ UIs [1][4].

Cons

AGPL-3.0, not MIT. Multiple review sites list it as MIT — this is wrong [1][4][merged profile]. AGPL-3.0 has network-service copyleft requirements that matter for commercial embedders.
Not a DevOps platform. No CI/CD, no issue tracker, no container registry. You’re getting repository hosting. GitLab CE gives you all of that; SCM Manager does not [2][5]. If you need a complete DevOps suite, this is the wrong tool.
Smaller community than Gitea or Gogs. Few public user reviews, lower GitHub star count relative to competitors [1][2][4]. Smaller ecosystem means fewer community answers to ops questions.
Java runtime overhead. Heavier than Go-based alternatives (Gitea: ~170MB RAM) [5]. Not a dealbreaker on modern VPS hardware, but worth noting if you’re running on minimal compute.
Limited enterprise governance features. Advanced compliance dashboards, fine-grained audit reporting, and policy enforcement at scale require external tools [2]. This is fine for a 10-person team and a problem for a 200-person regulated environment.
Mercurial ecosystem declining. Supporting Mercurial is a strength for legacy migration scenarios and a liability for long-term strategic positioning. The industry has consolidated on Git [2]. If your team is already Git-only, the multi-VCS selling point adds no value.
No SaaS fallback. If self-hosting becomes too painful (ops overhead, incident response, backup failures), there’s no hosted version to migrate to. You’re on your own or moving to a different product entirely.
Zero published user reviews. No Trustpilot page, no G2 reviews, no GetApp reviews [1][4]. This isn’t necessarily a product quality signal, but it makes independent calibration harder.

Who should use this / who shouldn’t

Use SCM Manager if:

You’re running a mixed-VCS environment — some teams on Git, some on SVN, some still on Mercurial — and you want one admin panel for all of it.
You want the simplest possible self-hosted Git server with no database to provision or maintain.
Your team is 5–50 people and you’re paying GitHub or Bitbucket per-seat and the math has started to bother you.
You need specific integrations (Jenkins, Jira, LDAP) that the plugin center covers, and you don’t want to build glue code.
You’re on a resource-constrained server and GitLab’s 8GB RAM floor isn’t viable [5].

Skip it (use Gitea instead) if:

You’re Git-only and don’t need SVN or Mercurial support. Gitea is lighter (Go, ~170MB RAM), has a larger community, and is actively developed [5]. It does the same job with less JVM overhead.

Skip it (use GitLab CE instead) if:

You need CI/CD, container registry, issue tracking, merge request workflows, and compliance controls under one roof. GitLab CE is heavier and more complex to operate, but it’s an actual DevOps platform [5]. SCM Manager is not.

Skip it (stay on GitHub/Bitbucket Cloud) if:

Your team is fewer than 10 people and the monthly bill isn’t a meaningful expense. The operational overhead of running a self-hosted server isn’t free — it costs your time.
You don’t have a technical person comfortable operating a Linux server. SCM Manager is easy to deploy, but you still need someone who can handle TLS renewal, disk management, and Java process troubleshooting.

Skip it (use Forgejo instead) if:

You want a Gitea-compatible fork with stronger community governance and no single-company control [5].

Alternatives worth considering

Gitea — The most direct lightweight alternative. Go binary, ~170MB RAM, active community, GitHub-compatible UI. Git-only. Better choice if you’re not dealing with SVN/Mercurial [5].
Forgejo — Community fork of Gitea with identical resource profile, different governance model. Good for teams that want distance from any single commercial entity [5].
GitLab CE — The full DevOps platform. 8GB+ RAM, PostgreSQL required, steep setup curve. The right choice if you need CI/CD, issue tracking, and code review in one place [5].
Gogs — Predecessor to Gitea. Go, minimal RAM, older codebase. Largely superseded by Gitea [5].
Gerrit — Specialized code review system designed around patch-set workflows (used internally at Google and Android). Powerful for large teams with formal review processes; steep learning curve [5].
RhodeCode — Enterprise-focused multi-VCS server similar to SCM Manager. Commercial licensing for most features [5].
GitHub/GitLab/Bitbucket Cloud — The obvious hosted alternatives. Pay per seat, no ops overhead, full feature sets.

For a small team escaping GitHub per-seat costs and running Git only: Gitea or Forgejo. For a team stuck in a mixed-VCS world needing one admin panel: SCM Manager.

Bottom line

SCM Manager fills a specific gap that most self-hosted Git forge tools ignore: organizations that need to manage Git, SVN, and Mercurial repositories under a single access control system, without provisioning a full database stack. If that’s your situation, it’s one of the few tools that actually solves the problem. The zero-dependency deployment story is real — no Postgres, no Redis, one Java process — and that operational simplicity has value.

For teams that are purely on Git and just want to stop paying GitHub per-seat, there are better options: Gitea is lighter, faster, has a larger community, and handles the same workload with less JVM overhead. And for teams that want an actual DevOps platform, not just repository hosting, GitLab CE is the tool despite its infrastructure requirements.

The AGPL-3.0 license is the thing most worth double-checking before you commit to a deployment. Several aggregator sites have this wrong — verify the actual license against the GitHub repo if you have any commercial embedding use case in mind.

If deploying and maintaining this server is the blocker, that’s a one-time problem upready.dev solves for clients — deploy once, hand it off, you own the infrastructure.