opengist: a Git-backed pastebin that documents Node 16 while building with Vite 8 and Go 1.26

The stated build floors sit three years behind the pinned toolchain

The from-source section lists four requirements: Git 2.28 or newer, Go 1.23 or newer, Node.js 16 or newer, and Make, described as optional. None of those floors is the one the build actually uses. The module file declares a Go version of 1.26.5, the container copies its toolchain from a Go image tagged 1.26.5, and the frontend bundler is on its eighth major version, which does not run on Node 16. So a developer who reads the requirements list, installs Node 16 on a clean machine and runs make will not get a working frontend build. The Git floor is the one number in that list that is plausible to still be right, since it exists to bound the Git features the storage layer relies on rather than to track a release.

The image exposes a port the quick start never explains

The container declares four ports in its development stage and three in production:

EXPOSE 6157 6158 2222
VOLUME /opengist
HEALTHCHECK --interval=60s --timeout=30s --start-period=15s --retries=3 CMD curl -f http://localhost:6157/healthcheck || exit 1

The documented port is 6157, which appears in all three install routes and in the health check. Port 2222 is the SSH port and the compose example maps it with a note that it can be removed if you do not want Git over SSH. Port 6158 appears in the image and nowhere in the quick start, and the development stage adds a fourth, 16157, which appears in no documentation at all. Exposing a port in an image is not the same as publishing it, since compose has to map it, but a reader assembling their own deployment has no way to find out from this file what 6158 is for.

The version string comes out of git describe

The build injects the version at link time rather than storing it in a file:

BINARY_NAME := opengist
GIT_TAG := $(shell git describe --tags)
VERSION := $(patsubst v%,%,$(GIT_TAG))
VERSION_PKG := github.com/thomiceli/opengist/internal/config.OpengistVersion

The tag comes from describing the local checkout, the leading v is stripped for the packaged asset name, and the unstripped tag is passed to the compiler as a linker flag that writes a variable inside the configuration package. That is a clean arrangement for a source build and a git checkout. It also means the version is a property of where you built rather than of the code: a build from an extracted source archive with no tags and no history resolves nothing, and the binary download route documented in the quick start gets a version that was stamped wherever it was built. The cross-compilation target hands the same job to a shell script in the scripts directory.

Three databases and two search engines, with the tests pinned to one

The dependency list reveals more about the deployment surface than the feature bullets do. Persistence goes through an ORM with three drivers in the tree, SQLite, MySQL and PostgreSQL. Search is doubled: an embedded search library and a client for an external Meilisearch service are both required, so full text search over snippets can run in-process or against a separate service, and the documentation does not say which is the default. The build file exposes a test database variable that defaults to SQLite, so the test suite exercises one of the three backends and leaves the other two to whoever deploys them. A self-hosted instance on MySQL is therefore running a combination the project's own tests do not cover by default.

LDAP, passkeys and one-time codes are in the dependencies, not the features

The login story the documentation advertises is OAuth2 with GitHub, GitLab, Gitea and OpenID Connect. The module file asks for more than that: an LDAP client, a WebAuthn implementation, and a one-time password library. Those three are passkeys, directory authentication and authenticator apps, and none of them appears in the feature list, which mentions only the OAuth providers. The same is true of the metrics client and the cron scheduler, which are required dependencies with no mention in the overview. So the honest summary of scope is wider than the readme: this is an application with pluggable authentication backends and scheduled background work, presented as a pastebin with Git storage.

AGPL-3.0 on a service you are explicitly meant to modify

The licence is stated once, in a single line at the bottom of the file, and the project is described as an open-source alternative to a hosted pastebin that you self-host. Those two facts pull in opposite directions for an internal deployment. AGPL-3.0 is the copyleft variant designed for network software: the obligation attaches when the modified program is offered to users over a network rather than when it is distributed on disk. An organisation that installs this, changes the templates or the authentication, and serves it to its own staff is in the exact situation the licence was written for. None of that appears in the documentation, which has no section on it. The practical check before you fork is simple, and it is worth doing before deployment rather than after.

The browser editor ships one language grammar

Syntax highlighting is a headline feature, with markdown and CSV called out, and the highlighting story is split three ways. A Go highlighting library does the server side, a JavaScript highlighting library does the browser, and the code editor itself is a modular editor package with a language abstraction and a JavaScript grammar as its only language dependency in the manifest. So the editor that a contributor writes a paste in has one grammar wired up out of the box, while the read-only rendering of that paste is highlighted by two other engines that know far more languages. There is also a sanitiser, a markdown parser, a maths renderer and a PDF embedder in the same list, which is what a paste viewer needs and what a paste editor does not.

Editorial conclusion

Use it when the Git repository is the point rather than an export format, because that is the one thing it does that a hosted pastebin cannot, and it does it over both HTTP and SSH with init and clone support. Three things to check before you deploy it. The licence is AGPL-3.0, which for a network service means a modified instance offered to users has to carry its source, and the documentation does not discuss this at all, so read it before you fork it internally. The build documentation is out of date in a way that will bite you: it asks for Node 16 and Go 1.23, while the module directive, the container base and the bundler all sit much further forward. And the image opens more ports than the quick start explains.

Frequently asked questions

Official sources

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