onedev sends your issues to another host, and hides the instruction

Contributions go to a different host, and the note is hidden

The first element in the file is a block of markup, and it contains the single most important line for anyone arriving here.

The project is developed at code.onedev.io, for the sake of dogfooding, and contributors are asked to submit issues and pull requests there.

That whole note is wrapped in a div with the class d-none, which is the Bootstrap class for something that should not be displayed.

So the instruction is in the source, where a maintainer or someone reading the raw file will find it, and absent from the rendered page. A visitor to the repository front page sees a normal-looking README and no indication that this is not the place to report anything.

Everything else on the page points the same way. The code search, coverage, code discussion, Kanban, smart query and project tree demonstrations are all hosted on code.onedev.io, and the live deployment being demonstrated is the project's own instance.

So if you open an issue or a pull request here, you are using the wrong tracker. Find code.onedev.io first, create an account, and work there. That is not an unusual arrangement for a project that ships its own forge, but this one does not surface the requirement.

The one-line summary is corrupted with stray markup

Every project carries a short description alongside its name, the field that appears in search results and in directory listings. This one is visibly broken.

It begins with the project's own positioning line, that this is the unified and autonomous development platform. It then continues with the fragment Tutorial, followed by two asterisks with nothing to close them, and then runs straight into a feature heading about a service desk linking emails with issues, followed by the body text of that feature.

So the summary field contains a stray markdown emphasis marker and a copy-pasted fragment of a section heading and its paragraph, merged into one string.

That matters more than a cosmetic blemish would suggest, because this is exactly the text that appears when someone searches for the project. A reader sees a broken sentence rather than a description of the software.

The same pattern appears in the front page itself, where two separate sections are headed almost identically: one on built-in AI for DevOps intelligence, and a second further down headed AI for DevOps intelligence without the built-in qualifier. Their content is also related, with the first covering query, explanation and assistance and the second covering autonomous work. Whether that is two features or one feature documented twice, the front page does not resolve it.

An enterprise-edition module sits in the tree beside an MIT licence

The repository root is a Maven layout, with a pom file, a Maven directory, and four server modules: a server core, a server plugin module, a server product module, and one whose name is abbreviated in a way that stands out.

That module is named for an enterprise edition. There is also a licence file whose name is in lower case, alongside an agents file, a development document, a development shell script, an end-to-end test directory and a build specification file.

The project records an MIT licence, and the visible feature sections of the front page do not mention editions or that module.

So for anyone planning a deployment, the tree tells you a boundary exists and the front page declines to describe it. Whether the enterprise module contains additional functionality, is merely a packaging variant, or carries different terms is not answered by the documentation on this page.

There is also a file whose purpose is implied rather than explained, a trivy ignore file, which is the conventional name for suppressing findings from a vulnerability scanner. Its presence means some security findings are being filtered out somewhere in the build, and the list is not something the front page summarises.

Two patch releases shipped on the same afternoon

The three most recent releases are close enough in time to say something about the upgrade cadence.

Version 17.0.2 is dated 2026-10-30. Version 17.0.1 is dated 2026-10-29. Version 17.0.0 is dated 2026-10-28.

So a new major and two patch releases went out on three consecutive days.

That is a fast patch train, and for a self-hosted platform it has a straightforward consequence. Whatever version you run, something newer appeared within days, so a deployment that pins strictly for stability is pinning something old within a week, and one that tracks the newest release is restarting on someone else's schedule.

Questions such as long-term support and backported fixes are for the release notes and the documentation site.

The version number itself is worth registering too. This is the seventeenth major release of a self-hosted Java application, which tells you something about how long the API and upgrade path have been accumulating.

AI users are described as working autonomously in the issue and pull request flow

Two of the front page sections are about AI, and the second makes a claim that deserves to be read carefully.

AI users work autonomously in your issue and pull request flow. They implement assigned issues, review and improve pull requests, fix CI/CD failures, and resolve merge conflicts. Alongside that they can explain code, summarise long discussions, help write CI/CD specifications and answer project questions.

So the agent is not only answering questions about the codebase. It is taking issues, writing code to close them, reviewing incoming pull requests and fixing failing builds.

That is a considerably larger surface than a chat panel over your repository. An agent that resolves merge conflicts and fixes CI failures is, by design, one with write access and enough autonomy to act on it.

If you enable these features, the interesting question is not whether they work but who is accountable for the changes they make. Plan that before turning them on.

Workspaces put terminal coding agents on the server, in the browser

One feature blurs a boundary that used to be firm, and it is described in a section about working in a way the project labels as vibe coding.

You work on any branch with preconfigured development containers on the server, and use OpenCode, Claude Code, Codex or other terminal agents in the browser without setting up a local environment.

Read that carefully. The development container is on your server. The agent running inside it is one of the terminal coding agents you would normally run on your own laptop. The interface is a browser.

The benefit is real: a contributor or an AI agent gets a working environment without installing a toolchain, and the environment is reproducible because the container is defined by the server.

The consequence is that a coding agent now executes on infrastructure that also holds your source, your build history and your package registry. The README offers isolated sandbox VMs as an alternative to dev containers for these workspaces.

The other agent-facing feature sits beside it. A CLI and a set of shipped skills let coding agents query and edit issues, pull requests and builds, run CI/CD jobs against local changes and check out pull requests locally.

The unusual capability here is per-user, per-file, per-branch protection

Most platforms give you branch protection or required reviewers. This one lets you condition on all three variables at once.

Set a rule to require review or CI/CD verification when certain users touch certain files in certain branches.

That is a materially finer grain than a branch rule. It lets you require review for one person on one path, and leave the rest of the repository open, which is the situation most teams actually have: a small number of people editing a small number of sensitive files.

Two other capabilities in the same category are worth noting because they are unusual in a self-hosted tool. Confidential issues in public projects, which lets an internal tracker stay on a public instance without exposing the issue itself. And a service desk that uses issues as a ticket system, supporting customers by email without requiring them to register accounts, with different support contacts assignable per project or customer.

Both trade isolation for reach. An external correspondent interacting by email is not an authenticated user in the usual sense. Neither is documented as a limitation on the front page, so decide whether your threat model tolerates them before enabling.

Editorial conclusion

OneDev suits a team that wants issue tracking, review, CI/CD and package hosting in one Java application rather than four, and that appreciates fine-grained rules such as requiring review when specific users touch specific files. Two things to check first. Register on the project's own forge, because that is where issues and pull requests are accepted and where the live demos live. And confirm which components you need under which terms, because an enterprise-edition module sits in the tree and its contents and terms need checking. The AI features are substantial enough to plan permissions around.

Frequently asked questions

Official sources

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