OneDev: a self-hosted Git server that puts CI/CD, issues and AI agents in one application

The problem OneDev solves: too many tools for one repository

A typical self-hosted setup for a small engineering team is a Git server, a CI system, an issue tracker, and a package registry. Each has its own accounts, its own upgrade cycle, and its own way of referring to a commit. Linking a build to the issue it fixes usually means writing glue: webhook handlers, commit message parsers, or a bot that copies state between two APIs.

OneDev's answer is to make those four things one application. The README describes it as "The Unified and Autonomous Development Platform", and the feature list backs the word unified: issues transit state via commit, CI/CD or pull request, builds show the issues they fix, and pull requests can be queried between package versions. Because the issue tracker and the build engine share a database, that cross-referencing is a query rather than an integration.

Who is this for? Teams that already run their own infrastructure and are tired of paying the integration tax between a code host and a pipeline. It is also aimed at teams that want a service desk: the README describes using issues as a ticket system so customers can email in without registering accounts, with different support contacts per project or customer. That is a helpdesk-shaped feature sitting inside a Git server, which tells you the intended audience is not only developers.

How the pieces fit: Git, issues, builds and packages in one server

The repository layout shows a Java application split into modules: server-core, server-plugin, server-product, plus a server-ee directory and an e2e-test module. The build is Maven, driven by pom.xml and .mvn/, and the project's own CI definition lives in .onedev-buildspec.yml at the top level. That last file is the clearest architectural statement available: OneDev builds itself with OneDev, and the build specification is a checked-in file rather than a pipeline script written in a general-purpose language.

The README's phrase for this is "CI/CD as code without writing code": an intuitive GUI creates jobs, with templates for typical frameworks, typed parameters, matrix jobs, and logic reuse. The artifact is still a file in the repository, so it is reviewable and versioned, but the authoring surface is a form. That is a real design decision with consequences, and it is the main thing to weigh against script-based CI.

Executors are the other half. The README lists running jobs out of the box in a container or on bare metal, and scaling to many concurrent jobs with Kubernetes or agents. There are also debugging affordances that most CI systems treat as an afterthought: a command to pause job execution, a web terminal into the job environment, and the ability to run a job locally against uncommitted changes. If you have ever pushed a throwaway commit just to get a shell in a failing build, that last one is the feature to look at first.

Installing OneDev and creating your first project

The README does not contain install steps. It points to docs.onedev.io under "Get Started", and the tutorial links for CI/CD, packages and issues all live on that same documentation site. The repository root has no docker-compose file, no install script and no deployment manifest, so there is nothing to copy from here into a terminal. The only build tooling visible in the repository is Maven, through pom.xml and the .mvn/ directory, and that builds OneDev from source rather than deploying it.

So the honest answer to "how do I install it" is: read the getting started page the README links to. That page is the source of truth for the container image, the ports, the volume paths and the first-run setup screen, and none of those details appear in the repository files. The README's own feature list tells you what you will be configuring once it is running: container or bare metal executors for CI/CD, Kubernetes or agents for concurrency, and the built-in package registries.

For a first real use, the README's service desk entry is the most self-contained thing to try, because it does not depend on a pipeline. The README states that issues can be used as a ticket system so customers can email in without registering accounts, and that different support contacts can be assigned for different projects or customers. The linked tutorial is at docs.onedev.io/tutorials/issue/service-desk. Expect to configure a mailbox and an inbound address there; the repository does not document the mail settings.

The second thing worth trying first is the project tree. The README describes defining common settings in a parent project and inheriting them in child projects, which is the mechanism that keeps a multi-project deployment from becoming a settings-copying exercise. Both of these are configuration tasks in the web UI, not commands, which is consistent with how the project presents itself.

Code search and protection rules are the parts worth evaluating closely

Two features in the README are more specific than the rest of the list, and both are the kind of thing you only appreciate after using a weaker tool.

The first is language-aware symbol search and navigation in any commit. Clicking a symbol shows its occurrences in the current file, and code search supports regular expressions. Searching an arbitrary historical commit, not just the default branch, is uncommon in self-hosted Git servers and matters when you are trying to find when a function changed shape.

The second is the protection rule model. The README describes rules that require review or CI/CD verification when certain users touch certain files in certain branches. That is a three-way condition (who, which paths, which branches), which is finer-grained than the usual branch-level protection. It is also the feature most likely to be misconfigured, because a rule that looks correct in the settings page can be bypassed by a path pattern that does not match what you assumed. Test the rule with a throwaway user before trusting it.

The code annotation feature belongs in the same category: coverage and problems found in a pipeline are annotated onto the code to help review. That only works if your coverage tool emits a format OneDev can read, and the README does not enumerate those formats.

Where OneDev is the wrong choice

The strongest argument against OneDev is that it is one application. If your team wants Git hosting and nothing else, you are deploying an issue tracker, a package registry, a CI engine and an AI subsystem to get it. Each of those is a surface you now patch. The README's own framing, "unified", is a description of the trade-off, not a rebuttal of it.

CI/CD as code without writing code is the second place to be careful. A GUI that emits a build specification is easier for a team of mixed experience, and harder when you need something the form does not expose. Script-based pipelines let you shell out to anything; a typed, form-driven spec is bounded by what the form supports. The README mentions CI/CD logic reuse and typed parameters, which mitigates duplication, but it does not claim arbitrary scripting.

The built-in AI features deserve the same skepticism. The README describes AI users that work autonomously in the issue and pull request flow: implementing assigned issues, reviewing pull requests, fixing CI failures, resolving merge conflicts. Autonomous agents acting on your repository are a policy question before they are a technical one, and the README does not discuss what the AI can and cannot merge on its own. Treat that as something to configure deliberately rather than accept by default.

Finally, the repository contains a server-ee directory alongside server-core. The README does not explain the split, so anyone planning a deployment should confirm from the documentation which features live where before assuming the MIT licence covers everything they intend to run.

OneDev compared with Gitea and GitLab CE

The most common comparison is with Gitea, and the difference is scope rather than quality. Gitea is a Git hosting service with issues, pull requests and a lightweight actions system; it is written in Go, ships as a small binary, and installs on modest hardware. OneDev is a Java application that also hosts Git, but the CI engine, package registries and AI features are first-class parts of the product rather than add-ons. If your main concern is a fast, small code host, Gitea is the closer fit. If your main concern is not running a separate CI system, OneDev is.

Against GitLab CE, the difference is the CI authoring model and the operational footprint. GitLab's pipeline definition is a YAML file you write by hand; OneDev generates its specification from a GUI. GitLab CE is a large multi-component deployment; OneDev is described in the README as a single server that can also be clustered, with projects replicated across servers for availability or distributed for horizontal scalability. Teams that already know GitLab CI YAML will find OneDev's form-driven approach either a relief or a constraint, depending on how much their pipelines deviate from the templates.

Forgejo is the other name that comes up. It is a fork in the same family as Gitea, so the same scope comparison applies: a focused code host versus an integrated platform.

Licence, upgrades and what maintenance actually costs

The project is MIT licensed, which is permissive and imposes no copyleft obligation on your own code. Two caveats are worth stating plainly. A permissive licence on the repository does not by itself tell you the terms of every component in the deployment, and the README does not document the server-ee directory's contents or licensing. Confirm that from the project's own documentation rather than from the repository root licence file alone. This is a description of what the repository shows, not legal advice.

On upgrade cost, the release cadence is visible: 16.5.6 on 2026-08-20, 16.5.7 on 2026-08-24, and 16.5.8 on 2026-08-25. Patch releases landing days apart suggests active bug-fix work, and the last push to the repository was on 2026-08-25, so the project is not dormant. Frequent patch releases also mean frequent upgrade decisions, and the README does not document rollback. For a self-hosted system holding issues, packages and build history, the absence of a documented rollback path is the operational risk to plan around: back up the data volume before an upgrade, and test the upgrade on a copy.

The CI side has its own ongoing cost. If you use the container executor, the server needs access to a container runtime. If you scale with Kubernetes or agents, you are maintaining that infrastructure too. The README presents Kubernetes and agent farms as options for massive concurrency, not as zero-effort features.

Editorial conclusion

Adopt OneDev if you want a single self-hosted application that covers Git hosting, issue tracking, package registries and CI/CD without assembling a Git server, a separate CI runner and a separate registry. Skip it if you only need lightweight Git hosting, because the CI, issue and registry machinery is part of the same deployment and you carry that surface area regardless. Before committing, verify two things on your own hardware: that the CI executor mode you intend to use (container, bare metal, Kubernetes or agent farm) is documented for your environment, and that the server-ee directory in the repository is not required for the features you plan to rely on. The README also does not document rollback, so test an upgrade path between 16.5.x releases on a copy of your data first.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes