OneDev: A Self-Hosted DevOps Platform That Ties Code, Issues, and CI/CD Together

What OneDev Solves and Who It Targets

OneDev addresses the fragmentation problem in software development tooling. Most teams stitch together a code host, an issue tracker, a CI/CD system, a package registry, and a wiki. That creates context switching and integration glue. OneDev bundles all of these into one application. The README calls it "The Unified and Autonomous Development Platform." The target user is a small to mid-sized engineering team that wants to self-host its entire DevOps toolchain on its own infrastructure. It is also aimed at teams that want to reduce the number of third-party SaaS subscriptions. The service desk feature is particularly relevant for product companies that provide customer support through email. Instead of a separate help desk tool, they can use OneDev issues as a ticket system, and customers can submit and track tickets without registering an account. That is a specific niche that most general-purpose DevOps platforms do not address directly.

The Core Architecture: Everything in One Application

OneDev is written in Java and distributed under the MIT license. The repository layout shows a server product with a Docker build script, indicating a container-based deployment model. The platform is not a set of microservices; it is a monolithic application that runs as a single server. That design choice simplifies deployment and upgrades, but it also means that scaling is vertical rather than horizontal. The README mentions high availability and scalability through project replication across servers, which is a form of horizontal distribution, but the core server itself is a single unit. The data model is built around projects, issues, builds, and pull requests, all linked together. For example, the README describes how a commit, CI/CD job, or pull request can transit an issue state. That means the system tracks a change from code to build to release, and it can show which build fixed a particular issue. This cross-referencing is a central architectural idea. It is not just a set of modules bolted together; the entities are designed to reference each other deeply.

Getting OneDev Running: Commands and Configuration

The README does not provide explicit installation commands, but it links to the documentation at docs.onedev.io. Based on the repository contents, the typical path is to run the Docker image. The repository has a file at server-product/docker/build.sh, which suggests that a Docker image is built from the server product. The standard deployment would be something like docker run -p 6610:6610 -v /var/onedev:/opt/onedev onedev/onedev, but this exact command is not in the README. The docs would contain the precise instructions. The platform also supports a Kubernetes executor for CI/CD, which means you can configure a Kubernetes cluster to run build jobs. That requires setting up a kubeconfig and defining executor parameters in the OneDev web UI. The configuration for CI/CD jobs is done through a GUI, not YAML files, which is a deliberate departure from tools like GitHub Actions or GitLab CI. The README says "CI/CD as code without writing code," meaning you define pipelines visually with typed parameters and matrix jobs. For Renovate integration, you would configure a Renovate bot to create pull requests, and OneDev can merge them automatically when required reviewers approve or tests pass.

The Service Desk: Turning Issues into a Customer Support Ticket System

The service desk feature is the most distinctive part of OneDev. It links emails to issues, so a customer can send an email to a support address and that email becomes an issue in a project. The customer does not need to register an account. This is a direct alternative to dedicated help desk software like Zendesk or Freshdesk, but it lives inside the development platform. The README states: "Use issues as ticket system to support customers via email, without requiring them to register accounts." You can assign different support contacts for different projects or customers, which means you can route emails to specific team members based on the project or the customer's domain. The mechanism works by configuring an email inbox that OneDev polls. Incoming emails create or update issues, and replies from the team are sent back as email responses. The documentation has a tutorial for this, but the README does not detail the exact configuration steps. This feature is a genuine differentiator. Most code hosting platforms treat issues as internal tools for developers, not as a customer-facing communication channel. OneDev blurs that line, which can be useful for small teams that want to keep support and development in one place, but it also means your issue tracker becomes a customer-visible system, so you need to manage issue visibility carefully.

CI/CD and Executors: From Bare Metal to Kubernetes

OneDev's CI/CD system is designed to be flexible in where jobs run. The README lists several executor types: container, bare metal, Kubernetes, and agents. For a simple setup, you can run jobs in a container on the same server. For larger workloads, you can use a Kubernetes farm to run massive numbers of jobs concurrently. There is also an agent farm, which lets you attach remote machines as build agents. The GUI-based job definition includes typed parameters, matrix jobs, and cache management. The README also highlights debugging tools: you can pause a job execution, open a web terminal to inspect the job environment, and run a job locally against uncommitted changes. That last feature is unusual and useful for developers who want to test a pipeline before committing. The CI/CD system is tightly integrated with the rest of the platform. For example, a build can be linked to issues that it fixes, and you can query which issues were fixed between two build versions. This integration is a strength, but it also means that if you are used to writing pipelines as code in a repository, the GUI approach may feel restrictive or opaque for complex workflows.

AI Features: Built-In Intelligence and Autonomous Agents

OneDev includes a built-in AI for DevOps intelligence. This is not a separate product; it is part of the platform. The AI can answer queries in natural language, explain code snippets, review commits and pull requests, help write CI/CD specs, and investigate build errors. The README also mentions "AI users" that work autonomously in the issue and pull request flow. These AI users can implement assigned issues, review and improve pull requests, fix CI/CD failures, and resolve merge conflicts. That is a bold claim, and the README does not specify the underlying model or how it is hosted. This is a significant consideration for adoption. If the AI runs on external servers, then your code and issue data leave your infrastructure. The README does not say whether the AI is self-hosted or cloud-based. The documentation would clarify this, but the absence of that detail in the README is a red flag for teams with strict data privacy requirements. The AI also includes "Workspaces for Vibe Coding," which lets you work on any branch using preconfigured dev containers in the browser, with tools like OpenCode, Claude Code, or Codex. This is a newer trend, and it shows that OneDev is trying to stay current, but it also adds complexity to the platform.

Limitations and When OneDev Is the Wrong Tool

OneDev is not a lightweight tool. It is a full platform with many features, and that brings a learning curve and operational overhead. The GUI-based CI/CD is a limitation for teams that want version-controlled pipelines as code. You cannot easily review changes to your CI configuration in a pull request because the configuration lives in the database, not in a file. That is a real trade-off. The service desk feature, while useful, may not be suitable for large customer support operations that need SLAs, escalation rules, or advanced reporting. OneDev's issue tracking is not a replacement for a dedicated help desk. Another limitation is the lack of a managed cloud offering. You must self-host, which means you are responsible for backups, upgrades, and security patches. The README mentions high availability, but setting that up requires effort. Also, the AI features are a double-edged sword. If the AI is cloud-based, then using it means sending your proprietary code to a third party. That could be a deal-breaker for regulated industries. Finally, the project is developed on its own instance at code.onedev.io, which is a dogfooding approach, but it means that the public repository on GitHub may not be the primary place for issues and pull requests. The README explicitly says to submit issues and pull requests at code.onedev.io, not on the GitHub mirror. That is an unusual workflow and could be confusing for contributors.

Alternatives and How They Differ

The most direct alternative is GitLab, which also offers a self-hosted, integrated DevOps platform with CI/CD, issue tracking, and package registries. GitLab has a similar all-in-one philosophy, but its CI/CD is based on YAML files stored in the repository, which is a fundamental difference from OneDev's GUI-based approach. GitLab also has a built-in service desk feature, but it is less integrated with the issue workflow. Another alternative is Gitea, which is a lighter-weight, Go-based code hosting platform. Gitea is simpler and faster to set up, but it lacks the advanced CI/CD, AI, and service desk features. For teams that want a full platform, GitLab is the main competitor. For teams that want just code hosting, Gitea is a simpler option. OneDev's differentiators are the deep cross-referencing between code, issues, and builds, and the GUI-driven CI/CD that lowers the barrier for non-experts. The AI features are also ahead of GitLab's built-in offerings, but they come with privacy questions. If you value pipeline-as-code and a larger ecosystem, GitLab is safer. If you want a single tool with a strong visual workflow and an email-based support loop, OneDev is worth evaluating.

Editorial conclusion

Adopt OneDev if you want a single self-hosted platform that covers code hosting, issue tracking, CI/CD, and package registries, and if the email-based service desk model fits your support workflow. Skip it if you prefer best-of-breed tools or need a managed cloud service. Before committing, verify that the built-in AI features meet your privacy requirements, that the Renovate integration works with your dependency ecosystem, and that the Kubernetes executor setup matches your cluster's security policies. The project is actively maintained with frequent releases, so check the latest changelog for breaking changes before upgrading.

Official sources

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