How Opengist Handles Authentication and Instance Administration

Opengist supports two layers of access control: user authentication (via OAuth providers, LDAP, or local accounts, with optional TOTP/WebAuthn second factors) and instance-level administration (login requirements, anonymous snippet policy, user management, and Prometheus metrics). Both are configured by whoever self-hosts the instance, which means the exact behavior depends on your deployment rather than on a fixed hosted service.

Authentication options

Opengist lets users log in through external identity providers or a local account, depending on what the administrator enables.

The practical implication: if your team already uses GitHub, GitLab, or Gitea, you can let people sign in with those accounts instead of creating separate credentials. For internal deployments, OIDC or LDAP keeps user management in your existing directory. TOTP and WebAuthn are account-hardening options layered on top, so a user can protect an account with a second factor even when the primary login is an external provider.

Instance administration controls

Administrators configure how open or closed the instance is. The documented controls include:

• Require login for a private instance — you can make the whole instance private so only authenticated users can view content.
• Allow anonymous snippets — you can decide whether unauthenticated visitors may create snippets.
• Manage users — administrators can administer the user list on the instance.
• Prometheus metrics — the instance can expose metrics for monitoring.

These settings interact. A private instance that requires login will generally not allow anonymous snippet creation, since there is no anonymous user to attribute the snippet to. Conversely, an open instance that allows anonymous snippets is suited to public sharing where attribution is optional.

Choosing a configuration

The right setup depends on who you are serving:

• Public or community instance — enable anonymous snippets and public visibility so anyone can paste without an account; keep OAuth providers available so regular users can claim and manage their snippets.
• Internal team instance — require login, use OIDC or LDAP so access follows your existing directory, and enable TOTP or WebAuthn for accounts that need stronger protection.
• Private personal instance — require login, disable anonymous snippets, and rely on a single provider or local account.

Because Opengist is self-hosted, none of these are fixed defaults you must accept — they are choices the operator makes. The authentication and admin features are part of the same instance you deploy as a single binary, Docker image, or Kubernetes deployment, backed by SQLite, PostgreSQL, or MySQL.

What this means in practice

If your question is "can I control who gets in and what they can do," the answer is yes, at both levels: identity (who you are) and policy (what the instance allows). The main thing to verify before deploying is which identity provider you will use, since that determines the login flow your users see, and whether you need the instance to be private or open to anonymous contributions.