# Harness Open Source: v2.28 releases, a binary called gitness, and three Go versions > Harness Open Source is an end-to-end DevOps platform covering code hosting, pipelines, Gitspaces, and artifact registries, built on the Go module github.com/harness/gitness. The releases are tagged v2.28.x, the binary is called gitness, the README asks for Go 1.20 while the module requires 1.26.6, and the CI engine is still a snapshot of Drone on its own branch. **harness/harness** — Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries. - Repository: https://github.com/harness/harness - Website: https://www.harness.io/open-source - Stars: 38,441 · Forks: 3,409 - Language: Go - License: Apache-2.0 - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/harness-harness ## The releases are v2.28.x and the module is still gitness Three names for one program run through this project. The release tags are v2.28.2 dated 2026-04-20, v2.28.1 dated 2026-03-30, and v2.28.0 dated 2026-03-27. The Go module is github.com/harness/gitness, the Makefile writes the binary to ./gitness from ./cmd/gitness, and the configuration variables carry the same older name, GITNESS_DOCKER_HOST and GITNESS_DOCKER_API_VERSION. The swagger spec is generated by running the ./gitness binary itself. The consequence is that searching for a problem by version number does not work unless you know the mapping, and anyone writing automation has to reconcile a Harness release number with a Gitness binary and a Gitness environment variable. There is a second gap on top of that: the repository is not archived and the last push is dated 2026-09-25, while the newest tag is from April 2026, so the default branch sits about five months ahead of the last release and the two are not interchangeable. ## The README asks for Go 1.20 and the module requires 1.26.6 The pre-requisites say to install the latest stable version of Node and Go version 1.20 or higher. The module file is more specific, opening with a go directive of 1.26.6. The container build agrees with the module and not with the README, using golang:1.26.6-alpine3.23 as its builder stage. The Node story is split as well. The README asks for the latest stable Node, while the first stage of the Dockerfile builds the web bundle from node:16. So the repository contains three separate statements about toolchain versions, and the one a reader checks first is the one that will not build. The consequence is that a developer who satisfies the documented pre-requisite and runs make build hits a toolchain error from the Go toolchain itself, with nothing in the README to explain it. The fix is to read the go directive rather than the prose, and the deeper cost is that every other pre-requisite in the list, including the protobuf version pinned to v3.21.11 and the two protoc plugins, has to be trusted only after this one was wrong. ## The Makefile exports .local.env into every recipe Two files named for local environment settings sit at the repository root, .local.env and .test.env, alongside the Makefile and the Dockerfile. The Makefile handles the first one like this: ``` ifneq (,$(wildcard ./.local.env)) include ./.local.env export endif ``` When the file exists, its contents are parsed as make variables and exported into the environment of every recipe, so GITNESS_DOCKER_HOST set there reaches the build as well as the server. The run step passes the same file to the binary by path: ``` ./gitness server .local.env ``` The consequence is that one file is read twice, once by make as configuration and once by the server as configuration, and anything you put in it becomes an environment variable for compilation, tests, and tooling. That is convenient until the file carries a machine specific value, since the file that holds your overrides is also present in the repository root where it can be committed by accident. ## The local install mounts the host Docker socket This is the documented install command, and one of its mounts is the important line: ```bash docker run -d \ -p 3000:3000 \ -p 3022:3022 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /tmp/harness:/data \ --name harness \ --restart always \ harness/harness ``` The socket mount is not incidental, because pipelines run inside Docker containers, so the platform needs a daemon to start them. The other mount is the one the README warns about: without a bind mount or named volume, all data is lost once the container stops, which is why /tmp/harness is mapped to /data. The consequence is that the quick start install is not sandboxed, since the container can drive the host daemon, and the restart always flag means it comes back on boot with that access intact. Treat the container as having the privileges of the machine, and keep the data directory somewhere you would be willing to lose. ## Rancher Desktop and Colima need a symlink or an env var The daemon expects its socket at /var/run/docker.sock, and two common desktop runtimes do not put it there. Rancher Desktop uses ~/.rd/docker.sock and Colima uses ~/.colima/default/docker.sock, while Docker Desktop and native Linux work by default. There are two documented ways to fix it, and they have very different blast radius. The symlink option needs root and rewrites the default path for every tool on the machine: ```bash # For Rancher Desktop sudo ln -sf ~/.rd/docker.sock /var/run/docker.sock # For Colima sudo ln -sf ~/.colima/default/docker.sock /var/run/docker.sock ``` The environment option scopes the change to one installation, written into .local.env: ```bash GITNESS_DOCKER_HOST=unix:///Users//.rd/docker.sock ``` The consequence is that the recommended option is the global one, and it is the option that changes behaviour for tools other than this project. If you also run Colima and Rancher Desktop on the same machine, the symlink points at whichever you created last. Version negotiation is automatic, and GITNESS_DOCKER_API_VERSION=1.45 is available when you need to pin it for compatibility testing. ## The UI client is generated from swagger and regenerated by hand The web client is not written by hand against the API. Adding a REST endpoint means regenerating the spec from the binary and then regenerating the service layer: ``` ./gitness swagger > web/src/services/code/swagger.yaml ``` followed by running yarn services in the web folder, with the result landing in web/src/services/code/index.tsx. The Makefile encodes the same ordering for the frontend, where the build target is cd web && yarn install && yarn build. The consequence is a step that is easy to forget. An endpoint added to the server without the regeneration leaves the UI calling code compiled against the previous shape, and the failure shows up as a client error rather than a build error. There is also no single spec to point a tool at: the main swagger is served at localhost:3000/swagger with raw yaml at localhost:3000/openapi.yaml, and the registry keeps its own at localhost:3000/registry/swagger/ with raw json at localhost:3000/registry/swagger.json, which the README says will be moved to the main endpoint later. ## Drone is a feature branch and main is not at parity The README is explicit about the state of the pipeline engine. Drone focused solely on continuous integration, Harness adds source code hosting, Gitspaces, and artifact registries, and the stated goal is full parity with Drone in pipeline capabilities so that users can migrate. The same paragraph says this is expected to take some time, and explains that the team took a snapshot of Drone as a feature branch named drone, with its own readme under .github, so that it can continue development. Harness itself is developed on main. The dependency list backs that up, with drone-runner-docker, drone-go, drone-yaml, drone-runner-go, drone-scm, and the drone spec module all still required by the module file. The consequence is that a shop already running Drone cannot treat this as a drop in replacement today, because the project itself names the gap and keeps the old engine on a side branch. The upside is that the migration path is a documented one rather than a rewrite, and the two systems can be read side by side, since the drone branch is in the same repository. The Drone pipeline knowledge you have transfers, but the runner and spec come from Drone rather than from a new Harness implementation. ## Conclusion Harness Open Source fits a team that wants code hosting, CI, developer environments, and a registry in one Apache-2.0 system, and it fits an existing Drone shop that wants to move without changing its pipeline language. It does not fit a team that expects Drone parity today, since the README says that gap will take time, and it does not fit a team that wants a small install, since the local container takes the host Docker socket. Before you commit, read the go.mod rather than the pre-requisites list, build the web bundle before the Go binary, and decide deliberately whether the Docker socket reaches your build through a root level symlink or through GITNESS_DOCKER_HOST. ## FAQ ### how to install harness Harness Open Source is installed with a single container run: docker run -d with ports 3000 and 3022 published, the host Docker socket mounted at /var/run/docker.sock, /tmp/harness mapped to /data, and the image harness/harness. The README warns that without a bind mount or named volume all data is lost when the container stops. ### how to use harness For local development you build the web bundle first with yarn install and yarn build in the web folder, then make build, then start the server with ./gitness server .local.env and open http://localhost:3000. The REST API is documented at http://localhost:3000/swagger, and the API client for the UI is regenerated with ./gitness swagger followed by yarn services. ### What is harness? In this repository, Harness Open Source is an end-to-end developer platform under Apache-2.0 covering source control management, CI/CD pipelines, hosted developer environments called Gitspaces, and artifact registries. It is described as the next generation of Drone, with Drone's pipeline engine kept on a separate feature branch while main is developed. ## Sources - [Official documentation](https://www.harness.io/open-source) - [Official README](https://github.com/harness/harness#readme) - [Project repository](https://github.com/harness/harness) - [Release notes](https://github.com/harness/harness/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/harness-harness