Gitly: a lightweight self-hosted Git forge written in V

What Gitly replaces and who it targets

Gitly targets developers and organizations that want Git hosting and development workflow features without adopting a complete GitLab distribution. The README describes public and private repositories, multiple users, personal and organization repositories, Git operations over HTTP(S) and OpenSSH, issues, labels, assignees, merge requests, reviews, approvals, branches, and protected-branch rules. It also includes discussions, projects, milestones, releases, stars, watches, forks, mirrors, snippets, and Git LFS.

The project is explicitly described as beta software and as a lightweight forge. That distinction matters. Gitly presents an integrated control plane for repository and development workflows, but scanner engines, native LDAP and SAML protocol handling, managed observability backends, multi-region orchestration, and the separately maintained CI runner remain external services. A team expecting those capabilities to be supplied by Gitly itself will find a different scope from the one advertised.

The repository contains separate areas for API routes, authentication tokens, administration, commits, configuration, forks, discussions, feeds, governance, package delivery, LFS routes, and issue and merge request workflows. Based on this layout, Gitly is a self-contained application rather than a thin wrapper around GitHub or GitLab services.

How Gitly stores and moves repository data

Gitly uses the host OpenSSH server for SSH transport rather than embedding a second SSH daemon. Administrators enable SSH and identify the SSH endpoint, account, and authorized-keys file through `GITLY_SSH_ENABLED`, `GITLY_SSH_HOSTNAME`, `GITLY_SSH_PORT`, `GITLY_SSH_USER`, and `GITLY_SSH_AUTHORIZED_KEYS_PATH`. The process must be able to atomically update the authorized-keys file, and the documented security model says it preserves entries outside its managed block.

The application supports SQLite or PostgreSQL. PostgreSQL is the default build target, while SQLite is useful for a simpler local setup or the tracked test suite. Repository, archive, avatar, and binary artifact storage can be separated from the application paths. Binary artifacts use a content-addressed store by default, with an optional authenticated HTTP adapter through `GITLY_OBJECT_STORAGE_URL` and `GITLY_OBJECT_STORAGE_TOKEN`.

Credentialed repository mirrors require configuration. The README states that mirror passwords, access tokens, and SSH private keys fail closed when `GITLY_STORAGE_SECRET` is not configured. This is a useful failure boundary for operators because an unconfigured deployment does not silently store those credentials in plaintext. Multiple Gitly instances, however, must share the database, repository volume, object store, storage secret, and HTTPS and session configuration.

Building Gitly and creating a first local instance

The documented build requires a recent V compiler, Git, and a C compiler. A clean checkout also needs `sassc` to compile the stylesheet. PostgreSQL users create the default local role and database with the setup script, then build and start Gitly.

v run setup_db.vsh

This command creates the default PostgreSQL role and database described in the README. After that, build the application and start it from the repository directory.

v run build.vsh
./gitly

The README also provides a SQLite build path. This is a direct alternative to PostgreSQL for local use and is the same storage mode used by the tracked SQLite test command.

v -d sqlite -o gitly .
./gitly

With SQLite enabled, the database defaults to `gitly.sqlite`. Operators can change that location with `sqlite.path` in `config.json` or with `GITLY_SQLITE_PATH`. Repository, archive, and avatar locations can be overridden with `GITLY_REPO_STORAGE_PATH`, `GITLY_ARCHIVE_PATH`, and `GITLY_AVATARS_PATH`. The first-run documentation therefore supports both a PostgreSQL installation and a lighter SQLite path, but it does not describe a container deployment.

Pull requests, CI status, and production security controls

Gitly models development work with merge requests rather than only presenting Git hosting. The documented capabilities include reviews, required approvals, squash and merge support, branch creation and deletion, protected-branch wildcard rules, push and merge controls, deletion protection, and force-push rejection. The repository includes `branch_management_test.v`, which indicates that branch policy behavior has a dedicated tracked test area.

CI is optional. When CI is enabled, `ci_secret` must contain a long random value and must match the value configured in the CI service. The README states that callbacks are rejected when the secret is empty. The callback URL is derived from `hostname` and `cookie_secure`, or can be replaced with `ci_callback_url` or `GITLY_CI_CALLBACK_URL`. A deployment behind a reverse proxy therefore needs to verify that the externally reachable callback endpoint matches the route expected by the CI service.

The CI runner is not part of the Gitly process. The README says `gitly_ci` is separately maintained and should run on an isolated runner host, VM, or equivalent sandbox with a minimal environment and no access to Gitly's database credentials, storage secret, repository storage, or host filesystem beyond its disposable workspace. This separation limits the impact of untrusted CI code, but it also means Gitly does not provide a complete, self-contained CI deployment.

Where Gitly stops short of full GitLab coverage

The clearest limitation is stated in the README itself. Gitly is not complete GitLab parity while major platform areas remain outstanding. Native LDAP and SAML protocol handling is external, so an organization whose identity requirements depend on those protocols cannot treat Gitly as a drop-in replacement without separate services.

Scanner engines, managed observability backends, and multi-region orchestration are also outside the application. Gitly provides security-report ingestion, vulnerability management, compliance and merge policies, audit export, cluster agents, feature flags, incidents, alerting, telemetry, and on-call schedules, but the README does not claim that the underlying scanners or observability systems are bundled. These control-plane features should therefore be evaluated as integrations and policy surfaces, not as replacements for the external systems that produce or store telemetry.

The project also has no GitHub releases. The repository was last pushed on 2026-09-09 and is not archived, but there is no published release sequence to use as a deployment or upgrade contract. The README points to `docs/gitlab-parity.md` for the current comparison and remaining implementation sequence. That document is the first project-specific source to check before selecting Gitly over GitLab.

Gitly compared with GitHub and GitLab

GitHub is presented as one of the hosted alternatives, but the README does not document a GitHub import or migration workflow. GitHub's usual hosted service model and Gitly's self-hosted application model are consequently different deployment choices. Gitly supplies the Git server, web interface, database, repository storage, access tokens, and policy controls inside the repository, while a hosted service shifts those operational responsibilities to the provider.

GitLab is the more direct comparison because Gitly explicitly documents its remaining capability gap in `docs/gitlab-parity.md`. GitLab is named as the full platform Gitly does not attempt to match in every area. Gitly emphasizes a smaller V codebase and a focused forge, with SQLite or PostgreSQL, local repository storage, optional object storage, and optional CI integration. GitLab distribution is not described as part of Gitly, and native identity, observability, scanning, orchestration, and runner concerns remain external.

The practical difference is scope. Gitly may fit a team that wants the documented repository and workflow features under its own control. It is the wrong choice when replacing an existing GitLab installation requires those unimplemented or external areas without separate infrastructure.

Editorial conclusion

Adopt Gitly when a small, self-hosted forge with repository hosting, pull requests, issues, packages, and explicit storage controls is more useful than full GitLab coverage. Do not choose it when native LDAP, SAML, managed observability, multi-region orchestration, or an integrated CI runner are mandatory. Verify first that `docs/gitlab-parity.md` matches the platform areas your deployment requires, then test the documented SQLite or PostgreSQL setup, SSH configuration, storage secret, and CI callback path.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. vlang/gitly on GitHub