Harness puts four developer services behind one server
Harness Open Source combines Git hosting, automated pipelines, browser development environments called Gitspaces, and artifact registries. The repository and binary still use the Gitness name in several places, while the product is presented as Harness Open Source. Its scope is closer to GitLab or OneDev than to a standalone CI runner. A web interface and REST API cover the platform, and a basic CLI handles development and server operations.
The integrated pitch is sensible for a team already operating separate code, CI, workspace, and registry services. One permission model and one backup boundary can be easier than four products. It also concentrates risk. A flaw in repository authorization or Gitspace networking sits next to source code, credentials, artifacts, and the Docker daemon that executes pipelines. Platform consolidation makes security review more important, not less.
The Docker trial is short and highly privileged
The README starts a published image on ports 3000 and 3022, stores data in a bind mount, and mounts /var/run/docker.sock. That is enough to open the web interface at localhost and execute container-based pipelines. The persistent volume is essential because stopping a container without one can remove repositories and database state.
Mounting the Docker socket gives the application powerful access to the host daemon. Treat the server as privileged infrastructure: isolate it, restrict who can define pipelines, and do not place untrusted projects beside sensitive workloads without a threat model. Rancher Desktop and Colima users can configure their alternative sockets through GITNESS_DOCKER_HOST; the application can negotiate a Docker API version or use an explicit version such as 1.45.
What happened when we ran it
Our sandbox tested commit ad5c876 in Go 1.24 on Debian. Installing dependencies took 104 seconds and added 799 packages. The build succeeded in 4 seconds. Tests ran for 504 seconds and failed overall: 87 passed and 1 failed out of 88.
The provided end of the test log listed passing packages such as store, stream, tests/load, types, and version, then printed only FAIL. It did not name the failing assertion in those last lines, so we cannot responsibly assign a cause. The result is one real failure in our environment and a reason to inspect the full suite before deployment, not evidence that a particular subsystem is broken.
The checkout contained 6,183 files, about 604,580 lines of source, and 26.9 MB. It had one CI workflow, a Dockerfile, and a tests directory. The 799-package dependency set and 504-second suite make source changes more expensive than the 4-second build suggests. Budget CI time for the tests and registry conformance checks rather than using compilation as the release gate.
Source development needs pinned generators and two toolchains
Building from source requires a current Node release, Go 1.20 or newer, protobuf 3.21.11, protoc-gen-go 1.28.1, and protoc-gen-go-grpc 1.2.0. Developers install and build the Yarn frontend before running make build. API changes also require regenerating Swagger and the TypeScript client used by the UI.
These exact generator versions reduce accidental diffs, but they make onboarding more involved than the single-container demo. The registry has separate conformance targets, and pipelines need a working Docker runtime. A contributor should reproduce the pinned toolchain in CI or a development image instead of relying on whatever Homebrew or Go happens to install that week.
The README's API example logs in with admin and changeit, then creates a personal access token valid for one year. That is test guidance, not a production credential policy. Change the initial password, shorten token lifetimes, bind the service to protected networks, and verify backups before importing real repositories.
Open security reports deserve version-specific review
Several open issues in 2026 concern meaningful boundaries. Issue 3695 describes blind SSRF in the Gitspace repository lookup endpoint through git ls-remote. Issue 3696 reports archive extraction writing outside the intended feature directory. Issue 3689 reports a missing authorization branch when listing Gitspaces. Issue 3697 covers authenticated reads of infrastructure-provider configuration without the expected space permission.
Repository protection also has an open report. Issue 3681 says plain API content writes can be treated as if push-protection bypass were requested. Fix pull requests exist for that report and the infrastructure-provider authorization issue, but an open fix is not the same as a released patch. Operators should map each report to the chosen image digest and confirm the relevant change has landed.
These reports do not prove every current deployment is exploitable, since versions and configuration matter. They are specific enough to affect a buying decision. Gitspaces accept repositories and development-container metadata, while pipelines reach Docker. A public instance with many untrusted users faces a different risk than a small internal server with controlled projects.
Drone parity is an aspiration, not current behavior
Harness describes itself as the next generation of Drone, adding source hosting, Gitspaces, and registries. The README says full pipeline parity with Drone is a goal and will take time. Drone continues on a snapshot branch so development can proceed separately. Existing Drone users should inventory required triggers, secrets, pipeline syntax, and plugins before considering migration.
Version 2.28.2 was released on 2026-04-20, and the repository was pushed on 2026-08-21. GitHub showed 106 open issues and pull requests combined, with active changes through August 25. That activity indicates maintenance, including security-related fixes, even though the latest release is several months older than the default branch.
Harness is most convincing when a team needs all four services and can operate them as privileged infrastructure. Gitea is easier to justify for a focused forge. GitLab CE offers a more established integrated platform at its own considerable cost. Run Harness in an isolated trial, reproduce the 88-part test result, inspect the chosen image against open security fixes, and migrate only the workflows that pass those checks.