XBackBone: a self-hosted ShareX server built on Laravel 13 and Livewire 4

What XBackBone solves, and who it is for

The problem is the upload endpoint. ShareX, ScreenCloud, ishare, Spectacle on KDE and the macOS Share sheet all want somewhere to send a screenshot or a file and get back a link. Hosting that yourself means writing the receiving side, the authentication, the storage layer and the gallery, which is more work than most people want for a personal screenshot server.

XBackBone is that receiving side, packaged. The README describes it as a self-hosted file and media sharing platform with first-class ShareX support, and it covers images, GIFs, video, audio, PDFs, code and arbitrary files. The intended user is someone with a server who wants clean short links and rich social embeds without handing their screenshots to a third party. The multi-user management, admin roles and per-user disk quotas suggest it is also meant for small teams sharing one instance, not only for a single person.

The scope is wider than a ShareX endpoint. The feature list includes pastes, link shortening, password protection and expiration per resource, and an activity log that admins can filter across the whole instance. That is a file manager with a sharing layer on top, and the repository topics (filemanager, gallery, self-hosted, uploader) match that reading.

The monorepo split between core/ and app/

The architecture is the most consequential design decision here. The repository is a monorepo with two directories. core/ holds the full application and is published as the xbackbone/core Composer package. app/ is a minimal installation skeleton containing config, bootstrap and the public entrypoint, and it pulls xbackbone/core in as a Composer dependency.

The skeleton boots the core package and remaps its public, storage and environment paths to the skeleton root. The stated benefit is that an instance can be upgraded or downgraded by changing the required version of xbackbone/core, without touching the rest of the deployment. If that holds in practice, it is a cleaner story than the usual PHP upgrade path of overwriting files and hoping local customisations survive.

It also means the thing you deploy is not the thing you read in core/. Anyone auditing the code has to keep two directories in mind: the logic lives in the package, while the paths, environment and public document root live in the skeleton. The README points to core/README.md for the application's technical details and the development setup, so the top-level file is deliberately thin.

The rebuild is on Laravel 13 and Livewire 4, which the README calls the next-generation XBackBone. That is a full framework stack, not a micro-framework, and it sets the floor for what the host must provide.

Installing XBackBone and generating your first ShareX config

The top-level README does not carry install commands. It says full installation, configuration and usage instructions are available in the documentation, and links to the XBackBone Documentation site at sergix44.github.io/XBackBone/. The repository also ships a docs/ directory. Start there rather than inventing a sequence.

What the README does describe is a guided web installer that sets up the database, storage and admin account from the browser. So the shape of a first run is: get the skeleton onto a PHP host, point it at a database, then finish configuration in the browser instead of editing files by hand.

The first genuinely useful thing after that is the ShareX integration. The README states that XBackBone generates ready-to-use uploader configs for ShareX, ScreenCloud, ishare, Spectacle (KDE), the macOS Share sheet, Xerahs and a CLI script, all pre-filled with your instance URL and a personal token. You generate the config from the web UI and import it into the client; the token is per-user, so each person on the instance gets their own.

If you would rather script against it, the REST API is versioned with token authentication and auto-generated OpenAPI docs. The README does not publish the endpoint paths, so read the OpenAPI output from your own instance rather than guessing at routes.

The storage side is configurable, and the README names four backends: local disk, Amazon S3 (and S3-compatible), FTP and SFTP. Pick one during the guided installer. Uploads are de-duplicated by content fingerprint, which the README calls content-addressed storage; if the same file is uploaded twice, the second upload should resolve to the existing content rather than a second copy. The README does not document what happens to the link or the metadata when the last reference to a piece of content is deleted, so treat that as an open question for your own testing.

Where XBackBone is the wrong tool

The obvious failure mode is the platform requirement. This is a PHP application on Laravel 13 with a database, a document root and a web server. There is no single binary to drop on a machine, and no static build. If your constraint is a host with no PHP runtime, or a deployment model where you cannot run a database, XBackBone is not a candidate no matter how well the feature list fits.

The second is operational. The README advertises in-app updates: admins can check for new releases and upgrade the instance from the browser, with no shell access required. That is convenient and it is also a write path into your deployment triggered from a web session. If your policy is that production changes go through a pipeline and nothing else, the in-app updater is a feature you will want to disable or ignore in favour of the Composer version pin in app/.

The third is scale and shape. The README's own word is lightweight, and the feature list is oriented around individual uploads, galleries and short links. Nothing in the README describes chunked uploads, resumable transfers, or a large-object workflow. For very large media files or high-volume programmatic ingestion, verify against the API docs before assuming it fits.

Finally, the documentation is split. The top-level README is a feature list and a pointer; the technical detail lives in core/README.md and the documentation site. If you need everything in one file to evaluate the project, you will be following links.

XBackBone compared with Zipline and other uploaders

The comparison people reach for is Zipline, and the difference in approach is the stack. Zipline is a Node.js application; XBackBone is PHP on Laravel 13 with Livewire 4. That single fact decides most deployments: you pick the one whose runtime you already operate. If your servers are PHP and your team reads PHP, XBackBone is the lower-friction choice, and the reverse is equally true.

The second difference is the packaging model. XBackBone splits into a published xbackbone/core Composer package plus a thin app/ skeleton, with the explicit goal that upgrading or downgrading is a version change in Composer. Zipline is a single application you deploy and update as a unit. The package split is a real advantage for controlled upgrades and a real cost in extra indirection when reading the code.

The third is breadth. XBackBone's README lists one-click config generation for ShareX, ScreenCloud, ishare, Spectacle, the macOS Share sheet, Xerahs and a CLI script, plus multiple storage backends (local, S3 and S3-compatible, FTP, SFTP), a legacy import path from an older XBackBone instance with old links redirected, and authentication covering TOTP two-factor and passkeys. If any of those specific integrations is what you need, the comparison is decided by that, not by benchmarks.

On the topic of Docker: the README does not describe an official image, and the repository layout at the top level shows no Dockerfile or compose file. The linuxserver.io image that people search for is not mentioned in the README. Treat container deployment as something to verify in the documentation, not something to assume.

Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-08-01. Release 3.8.2 is dated 2026-06-27, following 3.8.1 on 2025-01-26 and 3.8.0 on 2025-01-18. Note the gap between the 3.8.0 and 3.8.1 pair in January 2025 and the 3.8.2 release in June 2026: this is not a project that ships every week, so plan upgrades around releases rather than expecting continuous change.

The upgrade mechanism is the interesting part for cost. Because app/ depends on xbackbone/core as a Composer package, changing the required version is the documented way to move an instance forward or back. That gives you a rollback path that most PHP deployments lack, and it means the upgrade surface is the package version plus whatever migrations the core ships. The README does not document rollback behaviour in detail, and it does not say what happens to database schema when you downgrade a core version. Verify that against the documentation before you rely on it.

The in-app updater is the second path, aimed at admins without shell access. Two upgrade mechanisms mean two things to keep consistent; decide which one is authoritative for your instance.

Licensing is Apache-2.0, stated in the README and in the LICENSE file at the repository root. That is a permissive licence with an explicit patent grant and a requirement to preserve notices. It is not legal advice, and if you plan to redistribute a modified XBackBone, read the licence text and the NOTICE handling yourself.

There is also a migration path from an older XBackBone: the README describes a legacy import that moves users and uploads from a legacy instance, with old links transparently redirected. If you are already running the previous generation, that is the cost you avoid.

Editorial conclusion

Adopt XBackBone if you want a self-hosted ShareX endpoint with a web UI, multi-user accounts, quotas and a versioned REST API, and you are comfortable running a PHP application with a database behind it. Do not adopt it if you need a static binary, a single-file deployment or a service with no database at all; the guided installer and the in-app updater both assume a conventional PHP web host. Before committing, verify two things: that the storage backend you intend to use is one of local disk, Amazon S3 (or S3-compatible), FTP or SFTP, and that the core version you pin in app/ is the one you actually want, because that single line is what an upgrade or a rollback changes.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sergix44/xbackbone on GitHub