Self-hosted pastebins in 2026: revisit PrivateBin, Opengist and MicroBin before you paste another config file into a public pastebin

Every team has done it at least once. Someone needs to share a long log, a YAML file or a stack trace with a colleague, the chat tool truncates it, and the quickest fix is a public pastebin. The paste goes out with a database hostname, an internal IP range or, on a bad day, an API key. Public pastebins are also regularly scraped by people looking for exactly such leaks.

A self-hosted pastebin removes that habit by giving people a fast, safe place inside your own boundary. In this post we revisit three active open-source options, PrivateBin, Opengist and MicroBin, and look at history, licences, stacks, encryption model, operations, hardening and backups. This is not a ranking and no benchmark or hands-on drill was run for this post; the facts come from each project’s own repository, README, configuration files and release notes as of early November 2026.

Why revisit pastebins now

All three projects are alive, which matters for software that will hold sensitive text:

  • PrivateBin released 2.1.1 on 5 November 2026 (IST), shortly after 2.1.0 on 18 October 2026.
  • Opengist released v1.15.3 on 21 October 2026.
  • MicroBin released v2.1.4 on 9 March 2026 (IST), and its repository had commits as recently as September 2026.

The latest PrivateBin release notes are a good reminder of why updates matter here. Among the fixes is one where SVG attachment previews could turn non-ASCII characters into markup after sanitisation, enabling script execution. In a tool whose whole promise depends on the browser, a script injection bug is serious, so the upgrade path should be part of your plan from day one.

First, unlearn one idea: not every pastebin is encrypted

The word “pastebin” covers two very different designs:

  • Zero-knowledge pastebins encrypt in the browser. The server stores only ciphertext and never sees the key. PrivateBin is built this way.
  • Snippet stores keep text readable on the server so they can offer search, syntax highlighting, history and Git access. Opengist is built this way.
  • Hybrids let the user choose per upload. MicroBin offers server-side encryption and client-side end-to-end encryption as separate options.

Neither design is wrong. They solve different problems. A one-time secret handover needs the first; a team’s library of reusable scripts needs the second. Decide which problem you have before you pick a tool.

PrivateBin

History and licence. PrivateBin is a fork of ZeroBin, originally written by Sebastien Sauvage in 2012. The PrivateBin repository was created in July 2016. The project’s own code falls under the Zlib/libpng licence, and bundled libraries carry their own licences (GPLv2, BSD 3-clause, MIT, Apache and CC-BY are listed in the LICENSE file). Read that file if your legal team tracks every dependency.

Stack. PHP on the server and JavaScript in the browser. Pastes can be stored on the filesystem or in a database, and the configuration file controls the storage backend.

Encryption model. Data is encrypted and decrypted in the browser using 256-bit AES in Galois Counter Mode. The key sits in the URL fragment, the part after #, which browsers do not send to the server.

What it does well

  • The server has zero knowledge of paste content. A server breach exposes only ciphertext.
  • Optional password per paste, on top of the URL key.
  • Expiry times including “burn after reading”.
  • Optional discussions, Markdown and syntax highlighting, all switchable in the configuration file.

What to check before you commit

  • The README is honest about limits: users must trust the administrator not to inject malicious code, so the instance has to run over HTTPS, ideally with HSTS.
  • Anyone holding the full URL can read a paste that has no password. Treat the link itself as the secret.
  • Access logs still show who fetched a paste. Decide how long your web server keeps them.
  • There is no search and no user accounts by design. That is a feature for secrets and a gap for a snippet library.

Opengist

History and licence. The Opengist repository was created in April 2023 and is licensed under AGPL-3.0. It describes itself as a self-hosted pastebin powered by Git, similar to GitHub Gist.

Stack. A Go application with a web front end. It runs as a single binary or as the ghcr.io/thomiceli/opengist Docker image, listening on port 6157 for HTTP and optionally 2222 for SSH. A Helm chart is also provided. Building from source needs Git 2.28 or later, Go 1.23 or later and Node.js 16 or later.

Encryption model. Snippets are stored in Git repositories on the server, readable by the server. Protection comes from visibility settings and authentication, not from client-side encryption.

What it does well

  • Every snippet is a Git repository. You can clone, pull and push over HTTP or SSH, and you get revision history for free.
  • Public, unlisted and private snippets, with an option to restrict what anonymous users can see.
  • Search across snippets, topics, forks, likes and embedding.
  • OAuth2 login with GitHub, GitLab, Gitea and OpenID Connect, so it can sit behind your existing identity provider.

What to check before you commit

  • AGPL-3.0 matters if you modify Opengist and offer it to users over a network. For internal use without changes it is usually simple, but let your legal team confirm.
  • Because content is readable on the server, disk and backup access must be controlled like any other source code store.
  • It is a place for scripts and notes, not for passwords. Make that rule explicit, or people will paste secrets there too.
  • If you expose SSH on port 2222, include it in your firewall and monitoring plan.

MicroBin

History and licence. The MicroBin repository was created in April 2022 and is licensed under BSD 3-Clause. It describes itself as a tiny, self-contained pastebin that needs only a few megabytes of memory and disk.

Stack. Rust, shipped as a single executable, via Cargo or the danielszabo99/microbin Docker image. Data goes to SQLite by default, with a JSON file option.

Encryption model. Configurable. The sample .env enables both MICROBIN_ENCRYPTION_SERVER_SIDE and MICROBIN_ENCRYPTION_CLIENT_SIDE. The “secret” privacy level is end-to-end encrypted so the server cannot read content; other levels such as unlisted and read-only are not.

What it does well

  • Text, file uploads, raw serving, QR codes and even URL redirection in one small binary.
  • Per-upload privacy and expiry choices.
  • Very low resource needs, which suits a small VM or a home lab.
  • A server-wide read-only mode with an uploader password, useful as a “postbox” where outsiders can send you files.

What to check before you commit

  • The sample .env ships with MICROBIN_ADMIN_USERNAME=admin and MICROBIN_ADMIN_PASSWORD=m1cr0b1n. Change both before the instance is reachable by anyone.
  • File uploads are on, and the sample limits are large (2048 MB unencrypted, 256 MB encrypted). Lower them to what you actually need.
  • URL redirection means an open instance can be abused for phishing. Restrict who can upload.
  • The sample sets MICROBIN_DISABLE_TELEMETRY=false. Read the docs and decide your own setting.
  • The release pace is slower than the other two. Watch the repository before you rely on it for critical work.

Security hardening for any pastebin

  • HTTPS only, with HSTS. For a browser-encryption tool this is not optional.
  • Put it behind your SSO or VPN unless you truly need external users. Most leaks start with “it was only for internal use”.
  • Set a sensible default expiry. A paste that lives forever is a future incident.
  • Limit size and rate at the reverse proxy so the service cannot become free file hosting for strangers.
  • Watch logs and referrers. Keep only what you need, and make sure the URL fragment never lands in any custom logging.
  • Subscribe to releases. All three publish on GitHub; route the release feed to your ops channel.
  • Write a one-line rule for users: secrets go to PrivateBin or MicroBin “secret” with a password, never to a readable snippet store.

Backups and operations

  • PrivateBin: back up the data directory or the database, plus the configuration file. Remember that a backup only holds ciphertext; without the URL the content cannot be recovered, which is the point.
  • Opengist: back up the whole data volume (/opengist in the Docker example). It holds Git repositories and the database together, so take a consistent copy.
  • MicroBin: back up MICROBIN_DATA_DIR, which holds the SQLite or JSON database and uploaded files.
  • Test a restore on a fresh machine at least once a quarter. A backup you have never restored is only a hope.
  • Mind expiry and backups together. Burn-after-reading content may still exist in last night’s backup. Set backup retention with that in mind.

When to pick which

  • Pick PrivateBin when the main need is handing over sensitive text, such as a temporary credential, a customer log or a config with secrets, and the server should know nothing.
  • Pick Opengist when the team wants a shared, searchable library of scripts, queries and snippets with history and Git access, behind company SSO.
  • Pick MicroBin when you want one small binary for text, files and quick links on a tiny server, and you are willing to lock its defaults down carefully.
  • Run two if you have both needs. PrivateBin for secrets plus Opengist for snippets is a common and sensible pairing.

A small example

Consider an imaginary 30-person IT services team in Indore. Support engineers often send customer logs to developers, and developers share deployment scripts with each other. Today both go through a public pastebin and chat.

A calm plan would be: run PrivateBin on an internal subdomain with HTTPS, a default expiry of one day and passwords encouraged for anything with customer data. Run Opengist behind their existing OpenID Connect login for scripts and runbook snippets, with a clear rule that no secrets go there. Back up both nightly, test a restore every quarter, and block the public pastebin domains at the proxy after a two-week notice. The cost is two small services; the gain is that sensitive text no longer leaves the company by default.

Practical checklist

  • Decide your need: secret handover, snippet library, or both.
  • Confirm the licence fits: Zlib/libpng for PrivateBin, AGPL-3.0 for Opengist, BSD 3-Clause for MicroBin.
  • Deploy behind HTTPS with HSTS and, where possible, SSO or VPN.
  • Change every default credential, especially MicroBin’s admin password.
  • Set default expiry, size limits and rate limits.
  • Back up data and configuration, and test a restore.
  • Subscribe to release notes and plan regular upgrades.
  • Publish a short usage rule for the team and retire the public pastebin habit.

Closing thought

A pastebin is a small tool that quietly decides where your team’s sensitive text ends up. Revisit the habit, pick the design that matches the job, and keep it boring: patched, backed up and behind your own door.

comments powered by Disqus

Releted Posts

Self-hosted URL shorteners in 2026: revisit Shlink, YOURLS and Kutt before you share another link through a public shortener

A short link looks like a small thing. It goes into a printed brochure, a QR code on a shop counter, an SMS to customers, a slide in a conference talk.

Read more

Self-hosted push notifications in 2026: revisit ntfy, Gotify and Apprise before you wire another alert to a chat webhook

Most teams send alerts the same way. A cron job fails, a backup does not finish, a disk fills up, and a script posts a message to a chat webhook.

Read more

Self-hosted code search in 2026: revisit Zoekt, OpenGrok and Hound before you clone another fifty repos to find one function

Every growing engineering team reaches the same moment. Someone asks “where else do we call this function?”, and the honest answer is to clone fifty repositories and run grep across them.

Read more