Opengist: a self-hosted pastebin where every snippet is a Git repository

The problem Opengist solves: pastes you can version and clone

Most pastebins end at a text box and a URL. GitHub Gist added versioning and a Git endpoint, but it is a hosted service tied to one account system, and its availability is not yours to decide. Opengist takes the Gist model and makes it self-hosted: the README describes it as a self-hosted pastebin powered by Git, where all snippets are stored in a Git repository and can be read or modified with standard Git commands or through the web interface.

The audience is narrow and specific. It suits teams that already run their own infrastructure and want internal paste storage that does not leave the network. It suits people who paste config fragments, logs or code and want revision history rather than a single overwritten blob. It also suits anyone who wants a snippet to be a normal Git remote, so a file can be pulled into a working tree instead of copied by hand. If you only need to share a link with a stranger once, a hosted pastebin is less work.

How the Git-backed storage model actually works

The mechanism is the whole point. Each snippet is a Git repository on disk, and the web UI is a front end over it. The feature list confirms Init, Clone, Pull and Push over HTTP or SSH, which means the same object store serves both the browser and a terminal.

The repository layout backs this up. The Go module depends on gorm with sqlite, mysql and postgres drivers, so relational metadata (users, visibility, likes, forks, topics) lives in a database of your choosing, while the snippet content lives in Git. Search is split the same way: bleve is vendored for local indexing, and a meilisearch-go client exists for deployments that want an external search service. The frontend is a Vite build with CodeMirror, htmx and Tailwind, embedded into the Go binary through the fs_embed build tag, which is why a single compiled binary can serve the whole app.

The trade-off is honest: you are operating two kinds of state. A database backup without the Git directory restores an empty shell, and a Git directory without the database loses ownership and visibility metadata.

Installing Opengist with Docker Compose

The README gives a Docker path first, and it is the shortest route. Images are published per release under ghcr.io. Create a docker-compose.yml with the service below, then run docker compose up -d. The README states the instance is then reachable at http://localhost:6157.

services:
  opengist:
    image: ghcr.io/thomiceli/opengist:1.15.1
    container_name: opengist
    restart: unless-stopped
    ports:
      - "6157:6157" # HTTP port
      - "2222:2222" # SSH port, can be removed if you don't use SSH
    volumes:
      - "$HOME/.opengist:/opengist"

The volume line matters more than it looks. The container declares /opengist as a volume, and the Dockerfile sets OG_OPENGIST_HOME=/opengist, so that mount is where both the Git repositories and the SQLite database land. The README also shows UID and GID environment variables for controlling which host user owns those files, which you want if the default container user does not match your host permissions.

services:
  opengist:
    # ...
    environment:
      UID: 1001
      GID: 1001

If you prefer not to run Docker, the release page carries per-platform archives. The README's Linux amd64 example downloads the tarball, extracts it, makes the binary executable and starts it, optionally with --config config.yml. A config.yml sits at the repository root, and the Dockerfile copies it to /config.yml in the production image.

SSH access, ports and the container healthcheck

The Dockerfile exposes 6157, 6158 and 2222. Port 6157 is HTTP, and 2222 is the SSH port for Git operations, matching the compose example. The third port, 6158, appears in the Dockerfile's EXPOSE line and in the development stage's wider list (6157 6158 2222 16157), but the README's compose file only publishes 6157 and 2222. If your deployment needs the extra port, check the documentation before assuming what listens on it.

The production image also declares a healthcheck that curls http://localhost:6157/healthcheck every 60 seconds with a 30 second timeout, a 15 second start period and 3 retries. That endpoint is a real path you can point your own orchestrator probes at, and it is the fastest way to tell whether the process came up after a restart. The entrypoint is a shell script at docker/entrypoint.sh rather than the binary directly, so container startup behavior is defined there, not in the Go program.

Where Opengist is the wrong tool

The AGPL-3.0 licence is the first boundary. If you plan to offer a modified Opengist as a network service to third parties, the licence obligations attach to that distribution and to network use. That is a real constraint for a commercial product, not a footnote.

Second, the README does not document a backup, export or restore command. The data directory and the database are the backup surface, and you have to design that yourself. Anyone expecting a one-command dump will not find it described here.

Third, the search story has two modes with different operational weight. Bleve indexes inside the application, while the meilisearch-go dependency implies an external Meilisearch instance for the other path. Choosing external search adds a service to run and keep in sync.

Finally, a pastebin is not a secrets manager. The README lists public, unlisted and private snippets plus a setting to restrict snippet visibility to anonymous users, but nothing here describes encryption at rest or per-snippet access expiry. For credentials, use a tool built for that.

How Opengist differs from Gitea and MicroBin

The comparisons people search for are mostly category errors, so it is worth separating them. Gitea and Forgejo are full forges: issues, pull requests, CI, package registries, organizations. Opengist keeps only the snippet slice of that model, wrapped in a paste-oriented UI with likes, forks and topics. If you need review workflows and issue tracking, a forge is the answer and Opengist is a supplement to it, not a replacement.

MicroBin sits at the other extreme. It is a lightweight paste service with no Git object model behind it, so there is no clone URL, no revision history you can address with Git commands, and no push from a local repository. The practical difference is what a paste is: in Opengist it is a repository you can add a remote for, and in a plain pastebin it is a row in a database with a rendered view.

That distinction should drive the choice. Pick Opengist when the Git interface is the feature you want. Pick something simpler when it is not.

Maintenance, releases and what AGPL-3.0 means in practice

The last push to the default branch was on 2026-08-04, and the newest release listed is v1.15.1 on the same date, following v1.15.0 on 2026-07-30 and v1.14.0 on 2026-07-21. That cadence suggests a project still moving, and the release tags are the upgrade unit: the README pins ghcr.io/thomiceli/opengist:1.15.1, so upgrading means changing that tag and restarting, then confirming the healthcheck passes.

Upgrade cost is mostly schema and index. A database migration runs on start, and if you use the Meilisearch path, the external index has to be rebuilt or resynced. Because snippet content is Git, the content side of an upgrade is usually the safe half; the metadata side is where you want a snapshot first.

On licensing: AGPL-3.0 is a copyleft licence with a network clause. Self-hosting for your own team is the ordinary case. Redistributing a modified version, or exposing one to users over a network, triggers obligations you should read in the LICENSE file rather than infer from this article. This is a description of the licence identifier, not legal advice.

Editorial conclusion

Adopt Opengist if you want paste storage you control and a workflow where snippets are ordinary Git remotes. Skip it if you need a hosted service with no server to run, or if AGPL-3.0 distribution terms do not fit your product. Before committing, verify your storage backend choice in config.yml, whether you need the Meilisearch-backed search path, and how you will back up the data directory, since the README does not document a built-in export or restore command.

Frequently asked questions

Official sources

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