Imagine you're setting up a server on Ubuntu, and something goes wrong. The screen fills with hundreds of lines of journalctl output, you head to a forum or chat for help — and the question immediately arises: how do you share all that text? Pasting two hundred lines directly into a message is unreadable. Attaching a file takes extra steps that aren't even supported everywhere. This is exactly what pastebin services are for.
Ubuntu used to ship with pastebinit, which by default sent text to paste.ubuntu.com. The service works, but has its limitations: data isn't encrypted, automation via curl is awkward, and paste lifetime isn't under your control. Over time, the Linux community has built up a whole arsenal of alternatives — more convenient, faster, and more flexible.
This article covers the best Ubuntu Pastebin alternatives for sharing Linux logs and errors: from simple CLI tools to encrypted services and self-hosted solutions. It's useful for beginners looking to get help on a forum and for system administrators who need to quickly share Linux logs with a colleague or plug publishing into an automated pipeline.
What is a pastebin and how does it help when working with Linux
A pastebin is an online service for publishing text snippets. You send the contents of a file, command output, or an error trace there, get a short link — and share it wherever needed. No attachments, no walls of text in chat.
For Linux, this is convenient for several reasons. System logs like /var/log/syslog, dmesg output, or the result of apt install can easily run to thousands of lines. Asking a question on Stack Overflow, in IRC, or in a Telegram support group without a paste link means putting the person you're asking in an uncomfortable position. On top of that, a good pastebin highlights syntax: reading configs and scripts in a browser becomes much easier.
Notably, pastebin services have long been used for more than just forum questions. In CI/CD pipelines they publish build logs; in monitoring scripts they report errors; in DevOps teams they share config snippets during quick idea exchanges. It's a simple but universal tool.
Why paste.ubuntu.com stops being enough
paste.ubuntu.com is a simple and reliable service that has handled its basic job for years. But it has several limitations that get in the way of regular work.
First — no encryption. Paste contents are accessible to anyone with the link. If logs contain internal IP addresses, hostnames, or paths to files with a sensitive structure, publishing them on an open service is undesirable.
Second — a limited API. There's no native support for sending via curl in a single command, and setting it up via pastebinit requires a separate config file. For a server without a GUI, that means extra steps.
Third — no control over retention period. A paste either stays indefinitely or gets deleted by the service's internal policy, with no way to specify a concrete lifetime.
None of this is critical for a one-off task. But for regular work, in a team environment, or when handling confidential data — it starts to feel limiting. That's why more flexible alternatives exist alongside Ubuntu Pastebin.
Selection criteria: what matters when working with Linux logs
Before looking at specific services, it helps to define your priorities. This will save time avoiding a tool that looks good but doesn't fit your use case.
CLI support and automation. If you work on a server without a GUI, you need a service that's convenient to call via curl, nc, or wget. A single terminal command should return a link — without a browser or forms.
Encryption. For logs containing internal infrastructure data, it's important that the server stores only encrypted text, with the key embedded in the link. This approach is called zero-knowledge: the service administrator physically cannot read the paste contents.
Retention period. For debugging, a few days is usually enough. For configs or scripts that need a permanent link — different requirements apply.
Syntax highlighting. For configuration files and scripts — it matters. For raw system logs — not essential.
Self-hosting. Some services in this review are open source and can be deployed on your own VPS. This resolves all confidentiality concerns and removes dependency on external platforms.
Comparison table: best Ubuntu Pastebin alternatives
Below is a summary table by key parameters. It helps you quickly get oriented and choose the right option.
| Service | CLI Access | Encryption | Retention | Limit | Self-hosting |
|---|---|---|---|---|---|
| termbin.com | nc | — | ~1 month | ~500 KB | ✓ (fiche) |
| ix.io | curl | — | 30 days | not specified | — |
| PrivateBin | curl (API) | AES-256, zero-knowledge | configurable | 10 MB | ✓ |
| paste.debian.net | curl / XMLRPC | — | configurable | ~512 KB | — |
| 0bin | JSON API | AES-256, zero-knowledge | configurable | ~1 MB | ✓ |
| Hastebin | curl | — | 30 days | ~400 KB | ✓ |
| GitHub Gist | gh CLI | — | permanent | 100 MB | — |
| dpaste.org | curl (REST API) | — | up to 365 days | ~100 KB | ✓ |
| sprunge.us | curl | — | unlimited | not specified | — |
Detailed breakdown: what each service can do
termbin.com — as fast as it gets
Termbin is a minimalist service whose main value is one thing: it works via nc (netcat). No browser, no parameters — just a pipe. If you're seeing an error in the terminal right now, the command cat /var/log/syslog | nc termbin.com 9999 returns a link in seconds.
Termbin's server side runs on the open-source fiche engine — which can be deployed on your own VPS. Data isn't encrypted, pastes are stored for about a month, and the limit is around 500 KB. For sharing logs on a forum or with a colleague in chat, that's plenty. The one thing to watch out for is not sending sensitive data there in plain text.
ix.io — curl paste in one line
ix.io is oriented towards curl and fits naturally into scripts. The syntax is simple: curl -F 'f:1=<-' ix.io accepts stdin and returns a link. This is convenient in command chains where you need to share a result immediately without an intermediate file.
In practice, ix.io lets you update an already-published paste, set a language for syntax highlighting, and make a paste conditionally private. No encryption; data is stored for about 30 days without access. One of the most convenient options for automation.
PrivateBin — zero-knowledge encryption
PrivateBin answers the main security question: paste content is encrypted right in the browser (or via API) using AES-256 before being sent to the server. The key is embedded in the hash portion of the URL and is never transmitted to the server. This is zero-knowledge: even if the service's database is compromised, reading the paste contents is impossible.
A public instance is hosted at privatebin.net, but PrivateBin's main value is the ability to deploy your own server. It supports Markdown, syntax highlighting, retention periods ranging from "one view" to a full year, and paste deletion after viewing. The limit is 10 MB per paste. CLI operation is possible via the JSON API, though it requires a small script or ready-made wrapper.
paste.debian.net — the Linux community's choice
The official Debian community pastebin. In the Linux world it earns trust precisely because it's maintained by an organization rather than an anonymous project. It supports sending via XMLRPC API and direct curl requests, has syntax highlighting for a large number of languages, and lets you set a retention period. No encryption; the limit is around 512 KB. A solid choice when sharing a log in the Debian/Ubuntu community — where this link format is immediately recognized.
0bin — encrypted and open source
0bin is a Python project with the same zero-knowledge concept as PrivateBin. A public instance is available at 0bin.net, but the main value is deployment on your own Python-compatible hosting or VPS. The interface is minimalist and browser-based. There's no built-in CLI, but there's a JSON API for automation. A good fit for those who want an encrypted pastebin under full control, without complex infrastructure.
Hastebin — clean and simple
Hastebin is one of the most visually pleasant pastebin services: a clean interface, instant loading, syntax highlighting. At first glance it looks like a simple tool, but that simplicity is exactly what makes it popular in team environments. Many DevOps teams deploy it on an internal server for use within a closed network.
Sending via curl: cat log.txt | curl -X POST --data-binary @- https://hastebin.com/documents returns a JSON object with a key, from which the link is assembled. The original project is in Node.js; Go forks also exist. The source code is open.
GitHub Gist — for code and configs with version history
GitHub Gist is a full git repository for one or more files. Pastes are created through GitHub's web interface or via the gh CLI tool. The main advantages — permanent links, version history, syntax highlighting for hundreds of languages, and the ability to comment.
For system logs, Gist isn't the most convenient option: you need a GitHub account. But for scripts, config files, and small programs it's the best choice on this list. The per-file limit is 100 MB; gists are stored permanently.
dpaste.org — REST API without registration
dpaste.org is a Django-based pastebin with a clearly documented REST API. It accepts requests via curl, supports syntax highlighting, and retention period is set at upload time (from one hour to 365 days). Worth noting — the API documentation is detailed and current, making it easy to embed into automation scripts. The limit is around 100 KB; not suitable for multi-megabyte dumps, but sufficient for most logs.
sprunge.us — ultra-minimalism
sprunge.us is a maximally simple service with no extra features. Send via curl -F 'sprunge=<-' http://sprunge.us, get a direct link to plain text. No browser interface with syntax highlighting — just plain text at the URL. The retention period is not officially specified; the service has been running since 2011. A good fit for those who just need a quick link with zero configuration.
Advantages and limitations of different approaches
All services in this review handle the basic task — share a log via a link. But each approach has its own area of application.
Public CLI-oriented services (termbin, ix.io, sprunge.us) offer speed and simplicity. They require no configuration, work out of the box on any Linux system, but aren't suitable for confidential data. In practice, they're great when you need quick help from the community.
Encrypted services (PrivateBin, 0bin) address the privacy question, but require slightly more effort when working via CLI — you'll need a script or a ready-made wrapper. It's worth noting that zero-knowledge encryption here isn't a marketing term: the key truly never leaves the client's browser.
GitHub Gist is convenient for code and configs that need to be stored long-term, but requires an account and isn't suitable for publicly sharing sensitive infrastructure data.
Self-hosting is the most flexible option. You fully control the data, can customize limits to your needs, and remove dependency on external services. The only constraint — you need your own server and time for initial setup.
How to send a log from the terminal in one command
Below are ready-to-use commands for the main services. All of them work on Ubuntu and most other Linux distributions with curl and nc installed.
termbin.com — the shortest option, via netcat:
ix.io — via curl with stdin:
sprunge.us:
dpaste.org — with a specified retention period in seconds:
--data-urlencode "content@/var/log/syslog" \
-d "lexer=text" \
-d "expires=86400"
Hastebin — extracting the key from the JSON response:
https://hastebin.com/documents | python3 -c \
"import sys,json; print(json.load(sys.stdin)['key'])")
echo "https://hastebin.com/$KEY"
GitHub Gist — via the official CLI (requires prior authentication with gh auth login):
A useful trick: to avoid memorizing the syntax each time, add an alias to ~/.bashrc or ~/.zshrc:
# Usage: cat /var/log/syslog | tb
After that, sharing any command output is a single line in the terminal. No browsers, no forms.
Practical use cases
Getting help on a forum or in chat
The most common scenario. You're installing a package, updating a kernel, or configuring a service — something goes wrong. You need to ask on AskUbuntu, in an IRC channel, or in a Telegram support group. Any service from the table works: termbin or sprunge.us for speed, paste.debian.net or dpaste.org if you want something familiar to the Linux community. The main thing — check the log for tokens or passwords before sending.
Automatic log publishing in CI/CD
In a build or deploy pipeline, it's convenient to automatically publish the log when a job fails. Instead of hunting for an artifact in the CI interface, the developer gets a direct link in Slack or an email notification. ix.io or dpaste.org work best for this scenario — clean API, minimal syntax, predictable response format.
Sharing confidential infrastructure data
Need to share an nginx config that contains internal addresses? Or pass along a log with hostnames? PrivateBin or 0bin are the right choice for such cases — zero-knowledge encryption ensures that only someone with the full link, including the key in the hash portion, can read the contents.
Internal pastebin for a team
If several people regularly exchange configs, scripts, and logs, it's worth deploying your own instance of Hastebin, PrivateBin, or dpaste on an internal server. This speeds up work and removes dependency on external platforms that can change their terms or go down at the worst possible moment.
Long-term storage of scripts and configs
If you want a permanent link to a frequently used script or config — GitHub Gist is the answer. Versioning, comments, the ability to fork. It's no longer a pastebin in the traditional sense, but a full-featured code-sharing environment with a minimal barrier to entry.
Common mistakes and how to avoid them
| Mistake | Cause | Solution |
|---|---|---|
| Publishing logs with tokens and passwords | System logs sometimes contain sensitive data in plain text | Review the log before sending; use PrivateBin or 0bin; filter with grep or sed |
| Sending a file that exceeds the size limit | Most public services have a 100–500 KB limit | Trim the log with tail -n 200 or grep ERROR; for large files — GitHub Gist |
| The link stopped working after a week | The service deleted the paste after the retention period expired | For permanent links — GitHub Gist or a service with configurable retention |
| curl returns HTML instead of a link | Wrong request syntax or the service API has changed | Check the current service documentation; add the -s (silent) flag and the required Content-Type header |
| Sending the entire syslog | The file is too large and most of it is irrelevant | Send only the relevant portion: tail -n 100 /var/log/syslog | nc termbin.com 9999 |
One important rule: never publish SSH keys, API tokens, passwords in configs, or private IP addresses of your internal network to an open pastebin. The link may seem random, but services are often indexed by search engines, and links end up in public logs and chats.
Self-hosted pastebin server: when is it worth it
If you work with logs regularly, in a team, or with data that shouldn't leave your network perimeter — deploying your own pastebin service on a VPS is well worth it. It removes dependency on external platforms that can change their terms, go down, or shut down entirely, and gives you full control over data storage.
Hastebin, PrivateBin, and dpaste deploy on a standard Linux server in 15–30 minutes. Hastebin is a Node.js application with minimal dependencies. PrivateBin runs on PHP. dpaste is Django on Python. Each project has detailed documentation and ready-made Docker images.
For this scenario, renting a VPS server from Serverspace is a natural fit. A configuration with 1 CPU core and 2 GB of RAM is enough for a small team. After installing nginx and getting an SSL certificate via Certbot, the internal pastebin service is ready to use. No third parties, no questions about who accessed a paste and when.
Summary: what to choose and when
Choosing a pastebin service comes down to a few practical questions. Need something fast without a GUI — termbin via nc or sprunge.us via curl. Need automation in a script — ix.io or dpaste.org. Need encryption — PrivateBin. Need a permanent link with history — GitHub Gist. Need full control — your own instance on a VPS.
Ubuntu Pastebin isn't going anywhere and still works fine for one-off tasks. But if you work with Linux regularly, five minutes to set up an alias in the terminal or an hour to deploy your own service is an investment that pays off in the first week. The tools in this review are free, and most are open source. Choose by task — and sharing logs will be faster than finding the right line in the log itself.
Most public services limit paste size from 100 KB to 10 MB. For large files, GitHub Gist (up to 100 MB per file) or a self-hosted PrivateBin instance where the limit is configured by the administrator are suitable options. The most practical approach is to trim the log down to the relevant fragment using tail, head, or grep before sending.
It depends on the contents. Logs often contain internal IP addresses, hostnames, file paths, and sometimes command fragments with tokens or passwords. Before sending a log to a public service, it's worth reviewing it for such data. If that's not possible — use PrivateBin or 0bin with zero-knowledge encryption.
Yes. The pastebinit utility supports different backends via a configuration file at ~/.pastebinit.xml. The service address, request format, and parameters are all specified there. Configuring paste.debian.net, for example, just requires adding the corresponding config block. This lets you keep the familiar pastebinit interface while simply switching the target service.
Via a pipe. Most services accept stdin directly: command | nc termbin.com 9999 or command | curl -F 'f:1=<-' ix.io. No intermediate file is needed — it's all done in one line.
Technically — yes, but access will only be available from within the same network. For a team inside a secured network, this is perfectly normal practice. If external access is needed, a VPS with a public IP and Nginx configured as a reverse proxy in front of the application is the way to go.