What Do I Need to Self-Host Opengist?

You need a machine that can run a container or a single binary, a place to persist data, and a database — SQLite is the simplest option, while PostgreSQL or MySQL are supported for heavier use. Opengist ships as a single binary, a Docker image, or a Kubernetes deployment, so the practical requirement is basic server or container management rather than a full application stack. If you can run docker run and mount a volume, you can get an instance running.

The minimum setup

The official quick-start is a single Docker command:

docker run -p 6157:6157 -v "$HOME/.opengist:/opengist" ghcr.io/thomiceli/opengist:1.15

What each part does:

• -p 6157:6157 exposes Opengist on port 6157 of the host.
• -v "$HOME/.opengist:/opengist" mounts a host directory so snippets, Git repositories, and configuration survive container restarts. Without this, your data lives inside the container.
• The image tag 1.15 pins a specific release; the current release noted on the site is v1.15, which includes a major UI rework.

Expected result: the container starts, and you reach the web interface at http://<host>:6157. From there you create snippets, and each one is stored as its own Git repository.

What you actually need to provide

SQLite is the lowest-friction choice because it needs no separate service. Choose PostgreSQL or MySQL if you expect concurrent load or want to manage the database independently of the Opengist instance.

Deployment options and when to pick each

• Single binary — best when you want the smallest footprint and don't want a container runtime. You manage the process and its data directory yourself.
• Docker image — best default. One command to start, easy upgrades by changing the tag, and the volume mount handles persistence.
• Kubernetes — best when you already run a cluster and want Opengist managed alongside other services, with the database and storage handled by cluster primitives.

All three are backed by the same database choices, so the deployment form doesn't restrict your database.

Access and account setup

Once running, you decide how people log in and what they can do:

• Authentication: GitHub, GitLab, Gitea, or OIDC for OAuth; LDAP for directory-based login; TOTP or WebAuthn (passkeys) to secure accounts.
• Instance controls: require login for a private instance, allow or disallow anonymous snippets, and manage users from the admin area.
• Monitoring: expose Prometheus metrics if you run it as a service you need to observe.

For a private team instance, the common pattern is to require login and connect an existing identity provider rather than managing local accounts.

Using it once it's up

• Visibility per snippet: public, unlisted, or fully private.
• Git workflow: each snippet is a Git repository — clone and push over HTTP or SSH, or create one with a plain git push. You can also manage snippets from the Git CLI or the API.
• History: browse revisions with diffs between every version.
• Rendering: syntax highlighting for hundreds of languages, plus Markdown with Mermaid, LaTeX, CSV, and media files.
• Files: multiple files per snippet, including binary files and images, with ZIP download.
• Discovery and sharing: likes, forks, topics, full-text and code search, an embed widget, and JSON fetch.

Common snags to plan for

• Forgetting the volume mount — the most common mistake; snippets disappear when the container is recreated.
• Port conflicts — 6157 may already be in use; map a different host port.
• SSH access — if you want git push over SSH, that port must be reachable and configured, not just the web port.
• Database choice made too late — migrating from SQLite to PostgreSQL/MySQL after the fact is more work than choosing correctly up front.
• Upgrades — pin a tag (like 1.15) so you control when the UI and behavior change.

If you can run a container and mount a directory, self-hosting Opengist is a short setup. The real decisions are your database, your authentication method, and whether the instance is public or login-only.