XBackBone vs Zipline: Screenshot Hosts Compared

Quick Verdict

Zipline is the better choice for most people. It does everything XBackBone does and adds URL shortening, text paste, rich Discord/Open Graph embeds, folder organization, user invites, and a statistics dashboard. Pick XBackBone only if you want the absolute lightest screenshot host possible and nothing else — it uses a quarter of the RAM and runs on PHP with SQLite, so there is genuinely less to break.

Overview

XBackBone and Zipline are both self-hosted file upload servers designed as ShareX backends. You take a screenshot, ShareX uploads it to your server, and you get a shareable link. Both are open source under the MIT license, both run in Docker, and both handle the core use case well. The difference is scope: XBackBone is deliberately minimal, while Zipline has grown into a full-featured file sharing platform.

XBackBone is a PHP application built by Sergio Brighenti. It supports SQLite, MySQL, and PostgreSQL, runs behind Apache or Nginx, and provides a clean admin panel for managing uploads and users. Development is stable but slow — it does what it needs to do and not much more.

Zipline is a Next.js application built by diced. It requires PostgreSQL, ships a polished dashboard with upload statistics, and includes features like URL shortening, text/code paste with syntax highlighting, rich embeds for Discord and social media, folder organization, and an invite system. Development is active with frequent releases.

Feature Comparison

Feature	XBackBone	Zipline
Language/Runtime	PHP	Node.js (Next.js)
Database	SQLite, MySQL, PostgreSQL	PostgreSQL (required)
ShareX Support	Yes — custom uploader config	Yes — custom uploader config
URL Shortening	No	Yes
Text/Code Paste	No	Yes, with syntax highlighting
Rich Embeds (Discord/OG)	Basic Open Graph tags	Full embed customization (color, title, description, site name)
Folder Organization	No	Yes
User Invites	No	Yes
Storage Quotas	Yes, per-user	Yes, per-user and per-role
Upload Statistics	Basic (count, storage used)	Detailed dashboard (uploads over time, storage breakdown, views)
Multi-user	Yes	Yes, with role-based permissions
Thumbnail Generation	Yes	Yes
API	Basic upload/delete API	Full REST API
Two-Factor Auth	No	Yes (TOTP)
Chunked Uploads	No	Yes
S3/External Storage	No (local + LDAP via proxy)	Yes (S3, S3-compatible)
RAM Usage (idle)	~30 MB	~120 MB
License	MIT	MIT

Docker Compose Setup

XBackBone

XBackBone runs as a single container with no external database required — SQLite is the default. This is a LinuxServer.io image, so it follows their standard conventions for user/group IDs and volume paths.

Create a docker-compose.yml:

services:
  xbackbone:
    image: lscr.io/linuxserver/xbackbone:3.7.0
    container_name: xbackbone
    restart: unless-stopped
    environment:
      # User/group IDs — run `id` on the host to find yours
      - PUID=1000
      - PGID=1000
      # Timezone for correct timestamps on uploads
      - TZ=America/New_York
    volumes:
      # Persistent config and database (SQLite stored here)
      - xbackbone-config:/config
    ports:
      # Web UI — access at http://your-server:8080
      - "8080:80"

volumes:
  xbackbone-config:

Start it:

docker compose up -d

Open http://your-server:8080 in your browser. The first-run wizard walks you through database selection (SQLite works fine for single-user or small teams), admin account creation, and base URL configuration. Set the base URL to your domain if you are using a reverse proxy.

Zipline

Zipline requires PostgreSQL. The Docker Compose includes both services and wires them together.

Create a docker-compose.yml:

services:
  zipline:
    image: ghcr.io/diced/zipline:3.7.10
    container_name: zipline
    restart: unless-stopped
    ports:
      # Web UI and API — access at http://your-server:3000
      - "3000:3000"
    environment:
      # Core settings
      - CORE_RETURN_HTTPS=false
      - CORE_SECRET=CHANGE_ME_TO_A_RANDOM_STRING
      - CORE_HOST=0.0.0.0
      - CORE_PORT=3000
      - CORE_DATABASE_URL=postgresql://zipline:zipline_password@zipline-db:5432/zipline
      # Chunk size for large uploads (in MB)
      - CHUNKS_MAX_SIZE=95
      - CHUNKS_CHUNKS_SIZE=25
    volumes:
      # Upload storage — all files are stored here
      - zipline-uploads:/zipline/uploads
      # Public folder for custom branding assets
      - zipline-public:/zipline/public
    depends_on:
      zipline-db:
        condition: service_healthy

  zipline-db:
    image: postgres:16-alpine
    container_name: zipline-db
    restart: unless-stopped
    environment:
      # Database credentials — change the password
      - POSTGRES_USER=zipline
      - POSTGRES_PASSWORD=zipline_password
      - POSTGRES_DB=zipline
    volumes:
      # Persistent database storage
      - zipline-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U zipline"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  zipline-uploads:
  zipline-public:
  zipline-db:

Start it:

docker compose up -d

Open http://your-server:3000. The default admin credentials are administrator / password. Change the password immediately in the dashboard under User Settings. Then configure your site URL, embed settings, and upload limits from the admin panel.

Important: Change CORE_SECRET to a long random string before first launch. This secret signs session tokens — leaving it as the default is a security risk. Generate one with openssl rand -hex 32.

ShareX Integration

Both apps work as ShareX custom uploaders. The setup is nearly identical.

XBackBone ShareX Config

In XBackBone, go to your profile page and click “Generate ShareX config.” It downloads a .sxcu file. Double-click it to import into ShareX. The config looks like this:

{
  "Version": "14.0.0",
  "Name": "XBackBone",
  "DestinationType": "ImageUploader, FileUploader",
  "RequestMethod": "POST",
  "RequestURL": "https://your-domain.com/upload",
  "Headers": {
    "token": "YOUR_API_TOKEN"
  },
  "Body": "MultipartFormData",
  "FileFormName": "upload",
  "URL": "{json:url}"
}

The token is generated per-user in the XBackBone admin panel.

Zipline ShareX Config

In Zipline, go to the dashboard, click your avatar, and select “ShareX Config” to download the .sxcu file. Import it into ShareX the same way. The config looks like this:

{
  "Version": "14.0.0",
  "Name": "Zipline",
  "DestinationType": "ImageUploader, TextUploader, FileUploader, URLShortener",
  "RequestMethod": "POST",
  "RequestURL": "https://your-domain.com/api/upload",
  "Headers": {
    "authorization": "YOUR_API_TOKEN",
    "Format": "random",
    "Embed": "true",
    "Original-Name": "true"
  },
  "Body": "Binary",
  "URL": "{json:files[0]}"
}

Notice that Zipline registers as an image uploader, text uploader, file uploader, and URL shortener — ShareX can route all four upload types to a single Zipline instance. XBackBone only handles image and file uploads.

Performance and Resource Usage

XBackBone is significantly lighter. A PHP-FPM process behind Nginx with SQLite uses around 30 MB of RAM at idle and barely ticks the CPU. It handles hundreds of uploads per day without breaking a sweat on minimal hardware. A Raspberry Pi can run it comfortably.

Zipline uses around 120 MB of RAM at idle (the Next.js server plus the PostgreSQL instance). Under load with many concurrent uploads, expect 200-300 MB. It is still lightweight by modern web app standards, but it is four times heavier than XBackBone. A 1 GB RAM VPS handles it fine; a Raspberry Pi 4 with 2 GB or more works too, but you will feel the PostgreSQL overhead.

Resource	XBackBone	Zipline
RAM (idle)	~30 MB	~120 MB
RAM (under load)	~50 MB	~200-300 MB
CPU	Negligible	Low
Disk (application)	~50 MB	~250 MB
Disk (data)	Depends on uploads	Depends on uploads
Minimum server	512 MB RAM	1 GB RAM

Community and Development

XBackBone has a smaller community. The GitHub repository has moderate activity with periodic maintenance releases. The codebase is compact and easy to audit. Documentation is adequate but not extensive — the app is simple enough that you rarely need docs beyond the initial setup. Issues are addressed, but new features are rare.

Zipline has a more active community and development cadence. The GitHub repository sees regular commits and releases. There is an active Discord server where users help each other and request features. Documentation is thorough, covering every configuration option, API endpoint, and integration. New features are added regularly — recent additions include S3 storage support, chunked uploads, and TOTP two-factor authentication.

Use Cases

Choose XBackBone If…

• You want the simplest possible screenshot host with no extra features
• You are running on minimal hardware (Raspberry Pi, 512 MB VPS)
• You want SQLite — no external database to maintain or back up separately
• You only need image and file uploads (no URL shortening or text paste)
• You prefer PHP and want to customize the codebase yourself
• You want the smallest attack surface possible

Choose Zipline If…

• You want URL shortening alongside screenshot hosting
• You share screenshots in Discord and want rich embeds with custom colors and descriptions
• You want text/code paste with syntax highlighting (replacing Pastebin)
• You want folder organization for your uploads
• You want detailed upload statistics and a polished dashboard
• You need user invites to onboard friends or team members
• You want two-factor authentication
• You want chunked uploads for large files
• You plan to use S3 or S3-compatible storage for uploads
• You want an active project with frequent updates and a community Discord

Final Verdict

Zipline wins for most people. The resource overhead is modest — an extra 90 MB of RAM is not meaningful on any server built in the last decade — and you get a dramatically more capable platform. URL shortening, text paste, rich embeds, folders, invites, 2FA, chunked uploads, and S3 support are all features you will eventually want if you are serious about self-hosted file sharing. Zipline delivers them out of the box with a polished UI and active development.

XBackBone is the right pick if you have a specific reason to stay minimal: ultra-low-resource hardware, a preference for SQLite simplicity, or a philosophical commitment to running the smallest possible software for the job. It does screenshot hosting well and nothing else. There is value in that — but for most setups, Zipline’s feature set justifies the slightly higher footprint.

Related

• How to Self-Host XBackBone
• How to Self-Host Zipline
• Best Self-Hosted File Sharing Tools
• How to Self-Host Chibisafe
• Docker Compose Basics
• Reverse Proxy Setup
• Backup Strategy