Ubuntu Pastebin Is Closing: What to Use for Logs, Errors, and Configs Instead?

Ubuntu Pastebin is closing, and for thousands of Linux users that is real news. Canonical is retiring paste.ubuntu.com, the service that made it easy to share logs, configs, and error messages for years. In this article we explain what happened, how long the service still runs, and most importantly, what to use instead.

Canonical’s IS team posted the announcement on May 22, 2026. The stated reason is short: the shutdown is part of a larger infrastructure modernization and migration project. The first cutoff was set for the end of May, which left only eight days between the announcement and the shutdown. After the community pushed back on the short notice, Canonical moved the date to the end of June 2026.

One technical detail matters. The addresses paste.ubuntu.com and pastebin.ubuntu.com are the same service. Both domains serve identical content and share the same paste IDs. So it does not matter which address you saw in a guide. Once the service goes offline, both stop working.

What a pastebin is and why the service became part of Linux support culture

If you have never run into the term, here is the plain version. A pastebin is a web service where you paste a block of text and get back a short link to it. You then share that link in a chat, on a forum, or in a bug report. The benefit is that a long block of technical output stays out of the conversation itself. The other person just opens the link and sees everything.

Most often people share terminal output, system logs, configuration files, and error messages through a pastebin. Picture someone whose service will not start and who wants to show a log that runs to hundreds of lines. Dropping that wall of text straight into a message is awkward for everyone. A paste link solves it.

A pastebin also beats a screenshot in one important way. Text in a paste can be copied, searched, and quoted in a reply. A screenshot cannot, so whoever is helping would have to retype commands by hand. That is why technical communities usually value a paste link over a picture of the screen.

Ubuntu Pastebin ran from late 2007, almost eighteen years. In spirit it works like GitHub Gist, only without revision history. It was created in part to keep the official IRC support channels from drowning in terminal output, since newcomers kept dumping huge blocks of journalctl, dmesg, and apt into them. Over time the wider community adopted it everywhere: forums, Ask Ubuntu threads, bug trackers, and Reddit. That is how it became a fixture of everyday Linux support.

Why the shutdown affects the whole Linux world and old guides

It might seem simple. One service closed, so we find another. The problem runs deeper, and it reaches far beyond the people using the service right now.

Canonical offered no archive of old pastes, no redirect system, no migration tool, and no built-in replacement. That means every link to paste.ubuntu.com will simply stop opening after the shutdown. And there are a huge number of those links out there. They sit in old how-to guides, forum threads, bug trackers, mailing list archives, and Reddit posts.

The result is what people call link rot. An old discussion where someone once solved your exact problem and attached a log through the pastebin loses half its value, because the error text and the fix disappear. Sometimes that paste held critical debugging information available nowhere else.

The Wayback Machine helps a little, since some pastes made it into its snapshots. It is not something to rely on, because only a small share of links were saved, finding them is manual work, and fresh pastes will not get archived in time.

There is also a wrinkle inside Ubuntu itself. Some packages and system scripts still reference paste.ubuntu.com directly. Those spots will need edits too once the service is gone. The takeaway is simple: plan your move early and do not wait for the end of June.

What to use instead of Ubuntu Pastebin: a tour of working alternatives

The good news is that there are plenty of replacements, and almost all of them are free. It helps to split them into three groups: services that work straight from the terminal, familiar web pastebins, and the self-hosted option. We will go through each group and then bring everything together in a table.

Services that work straight from the terminal

This group suits anyone who lives in the command line. The main convenience is that your output flies into the pastebin with a single command, no browser needed.

The best known option is termbin.com. No account is required. You just send text through a network utility, for example with a command like cat error.log | nc termbin.com 9999. A ready link comes back. dpaste.com, bpa.st, paste.rs, and the classic sprunge.us all work the same way.

It is worth naming the pastebins of the major distributions too: paste.debian.net for Debian and paste.centos.org for CentOS. They are stable, long lived, and happily accept command output. For a one off task of showing someone a log, this is the fastest route.

Another upside of terminal services is how easily they slot into scripts. You can set up a short shell alias, and then sending a log to a pastebin becomes a single word. That is handy when you have to show output often, for example while troubleshooting across several servers at once.

Pastebins with a web interface and an account

If you prefer the browser, there are well proven web services, and each has its strengths.

GitHub Gist is probably the most capable option. It offers syntax highlighting, version history, and a tie in to your GitHub profile. The one catch is that it needs an account, while most other pastebins work anonymously. For a developer who already lives on GitHub, that is a plus rather than a cost.

The classic pastebin.com is familiar to almost everyone. It is convenient, supports paste expiration, and offers private pastes. Among newer options you can name pastecode.dev and Pastezen. The common point for every public service is this: you are trusting your text to someone else’s server, so secrets and passwords are best kept out. We will come back to privacy shortly.

Your own pastebin on your own server

The third path is to host a pastebin yourself. It sounds harder than it is, and it gives you the most control.

Among open source options, PrivateBin, Hastebin, and 0bin are popular. All of them install on your server, and you decide how long pastes live, who can reach them, and where the data physically sits. An instance like this comes up easily on an ordinary virtual server, for example in the Serverspace cloud, and from there it runs as your own private service. We will give a short PrivateBin walkthrough below. For now, here is a table that brings the options together for easy comparison.

How to set up pastebinit so your usual commands keep working

Many Ubuntu users sent text to a pastebin through the pastebinit utility. It is a small program that takes a file or command output and uploads it to your chosen service. The good news is that switching it to a different pastebin is simple, and your usual commands will keep working.

First, let us see which services pastebinit supports out of the box. We run:

The list shows several ready addresses, among them bpa.st, dpaste.com, paste.debian.net, paste.centos.org, and sprunge.us. Importantly, dpaste.com is already built into the utility, which makes it a convenient default replacement.

To change the service, the easiest way is to edit the config. We create or open the settings file in the home folder:

After that, old commands like cat config.txt | pastebinit will send text to the new address. If your scripts had paste.ubuntu.com hardcoded in them, you will need to replace it by hand. That way you avoid the situation where a familiar workflow breaks the moment the service goes offline.

You can confirm the switch right away. Send any small file and check that the link in the reply points to the new address. If the link opens and shows your text, the utility is set up correctly and your old workflows will keep running past the end of June.

How to host your own PrivateBin on a VPS in a few steps

If the data in your logs is sensitive, or you simply want full control, the best option is your own pastebin. We will use PrivateBin as the example, because it is among the easiest to deploy and it handles privacy well.

First, what makes PrivateBin good. It is an open source project where the server knows nothing about the contents of a paste. The text is encrypted and decrypted right in the browser using AES with a 256 bit key, and only an encrypted blob reaches the server. Even if someone gained access to the storage, they could not read the pastes without the key that lives in the link.

The minimum requirements are modest: a web server and PHP. The simplest way is to deploy PrivateBin in Docker, so you do not have to configure the environment by hand. The general flow looks like this.

Step 1. Rent a Linux virtual server. A minimal configuration is enough for a personal pastebin, and you can spin up a suitable VPS at Serverspace in a couple of minutes.

Step 2. Install Docker and connect to the server over SSH. Then start the official PrivateBin container with a single docker run command, specifying the port and a folder for storing pastes.

Step 3. Put a web server in front of the container as a reverse proxy, for example Nginx. It will accept requests and pass them to PrivateBin.

Step 4. Add a free Let’s Encrypt certificate and turn on HTTPS. This is required, because without a secure connection PrivateBin’s in browser encryption will not work.

After that, your own pastebin opens at your domain. In the config you can set paste expiration, size limits, and a password for writing. Here is why this is convenient for logs and configs specifically. Such files often contain internal addresses, paths, and sometimes access tokens. When the service runs on your own server, the data never leaves it, and if your team has internal security policies or compliance requirements that say sensitive data must stay inside infrastructure you control, self hosting covers that too.

A self hosted service needs only minimal upkeep. It is worth enabling automatic certificate renewal, updating the PrivateBin container to a fresh version from time to time, and optionally setting up a regular data backup. A personal pastebin usually sees light load, so even a modest server configuration lasts a long time.

Cloud Servers from $5 / moIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelTry

How to pick a replacement for a specific task

There is no one size fits all answer, so the choice depends on the task. Let us walk through five typical scenarios.

• One off help in a chat. You need to show someone command output quickly and then forget about it. Terminal services like termbin or dpaste win here: one command, a ready link, no registration.
• Collaborating on code and configs. If a paste lives a long time and people keep coming back to it, GitHub Gist is more convenient. Syntax highlighting and version history help the team.
• Sensitive logs. When the output contains internal addresses, paths, or tokens, a public service is a poor fit. Here it makes sense to host your own PrivateBin on a VPS, for example at Serverspace, so the data stays under your control, especially when security or compliance rules require it.
• Long term storage of snippets. For a library of frequently used commands and templates, Gist works well again, or your own instance with auto deletion turned off.
• Attachments for a bug report. If you are filing a bug against a distribution, it is logical to use that distribution’s own pastebin: paste.debian.net or paste.centos.org. The link will last longer and feel familiar to maintainers.

From there it is easy to check these options against the table above, which shows where an account is needed, whether encryption is available, and whether you can host the service yourself.

Common mistakes when moving off Ubuntu Pastebin

The move looks simple, but it is easy to trip on. We gathered the typical mistakes and how to avoid them.

• Leaving old links as they are. If addresses like paste.ubuntu.com remain in your documentation, on your site, or in scripts, they will stop opening after the end of June. It is worth searching for them in advance and updating them.
• Pasting secrets into a public pastebin. Logs and configs often contain passwords, API keys, or tokens. Before uploading, read the text over and strip anything sensitive, and for regular work with such data, set up your own service.
• Choosing a pastebin with no control over lifetime. Some services keep pastes forever and in public. It is better to pick options where you can set auto deletion or a password.
• Failing to save important old pastes. If you had your own entries on Ubuntu Pastebin, export them before the shutdown. After the end of June you will no longer have access to them.
• Betting on yet another external service. The story of Ubuntu Pastebin shows that any free service can close. If the data matters, keeping it on your own side is more reliable.

What to do right now: a short plan

Let us wrap up. Ubuntu Pastebin goes offline at the end of June 2026, and a familiar tool for sharing logs and configs is going away. There is no need to panic, since there are enough replacements. You only have to pick the right one and prepare.

A short action plan looks like this. First, save the old pastes you need while the service still works. Then choose a replacement from the table in this article to fit your tasks. After that, update any paste.ubuntu.com links in your scripts, documentation, and notes. And finally, if you work with sensitive data, deploy your own pastebin on a server. That way the move goes smoothly, and your logs and guides stay available.

FAQ