XBackBone 3.8.2: A Laravel and Livewire Rebuild of a ShareX Upload Server
A lightweight file manager with full ShareX support and more
At a glance
- What is it?
- XBackBone is a self-hosted PHP file and media sharing platform built around ShareX. The current generation is a monorepo split into a versioned Composer package and a thin install skeleton, which is the most consequential design decision in the repository.
- Who is it for?
- Adopt XBackBone if you already run ShareX or ScreenCloud and want the upload target on your own hardware, and if you are comfortable operating a Laravel application with a database and PHP 8. Do not adopt it if you need a static file server with no application layer, or if you cannot take a database backup before each upgrade.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem XBackBone solves is the upload destination, not the file manager
Most self-hosted file managers assume a human sitting in a browser dragging files into a web form. XBackBone assumes the opposite: a screenshot tool firing an HTTP POST at an endpoint and expecting a URL back. The README describes it as a "self-hosted, lightweight file and media sharing platform with first-class ShareX support", and the feature list backs that framing with one-click config generation for ShareX, ScreenCloud, ishare, Spectacle on KDE, the macOS Share sheet, Xerahs and a CLI script, each pre-filled with the instance URL and a personal token.
That token detail matters. The generated configs are per-user, so the upload endpoint is authenticated by default rather than open. Anyone who has run a public screenshot uploader knows the alternative: an anonymous POST target that gets discovered and abused within weeks. XBackBone's answer is that you hand out configs, not URLs.
The audience is narrow and specific. It is for people who already use one of those capture tools and want the resulting links to live on a domain they control, with per-user quotas and an admin view of who uploaded what. It is not aimed at teams wanting a collaborative document store, and the README does not claim otherwise.
A monorepo split into a versioned core package and a thin skeleton
The repository has two directories. core/ holds the whole application as a Laravel plus Livewire app and is published to Composer as xbackbone/core. app/ is an installation skeleton containing config, bootstrap and the public entrypoint, and it pulls xbackbone/core in as a dependency.
The README states the skeleton "boots the core package and remaps its public, storage and environment paths to the skeleton root". So the package does not assume it owns the filesystem root. It is told where public assets and storage live at boot time. That is what lets one package serve many installations with different directory layouts.
The stated payoff is that "an instance can be upgraded or downgraded by simply changing the required version of xbackbone/core, without touching the rest of the deployment". Read that as a claim about the intended workflow, not a guarantee. The application still owns a database, and the README does not describe a migration policy or a rollback path for schema changes. Downgrading a package whose migrations have already run is the kind of operation where the version constraint is the easy part.
Content-addressed storage and what it implies for de-duplication
The README lists "content-addressed storage" and says uploads "are de-duplicated by content fingerprint". The mechanism follows from the name: the stored object is keyed by a hash of its bytes rather than by filename or upload time. Two users uploading the same screenshot produce one stored object.
The README does not state whether the fingerprint is computed over the raw bytes or a normalised form, which hash function is used, or how reference counting works when one user deletes a resource that another user also references. Those are the questions that decide whether de-duplication is safe in a multi-user instance, and the supplied material does not answer them. Treat this as a feature to verify against the source in core/ before you rely on it for anything where accidental sharing between accounts would be a problem.
Storage backends are Local disk, Amazon S3 and S3-compatible services, FTP and SFTP. FTP and SFTP as object stores are an unusual pairing with content addressing, since neither offers the cheap existence check that S3 does. Whether that costs a round trip per upload is not something the README addresses.
Getting an instance running: the installer path and the Composer path
The README points to the documentation site for "full installation, configuration and usage instructions" and does not inline the commands. What it does describe is a "guided web installer" that sets up "the database, storage, and admin account from the browser". For the target audience, that is the intended route: you deploy the skeleton, hit it in a browser, and fill in database credentials and an admin account without a shell.
The second route is the monorepo itself. Because app/ is a Composer skeleton depending on xbackbone/core, the dependency version is the upgrade lever. The README's architecture section is explicit that changing the required version of xbackbone/core is how you move between releases, so composer.json in the skeleton is the file to look at when planning an upgrade.
Configuration keys are not enumerated in the supplied material beyond the categories the installer handles (database, storage, admin account) and the feature flags the README mentions, which "toggle sign-ups, default theme and more without redeploying". I cannot list specific env variable names from what is given here. If you need them before installing, the documentation site is the place to look, not this article.
The release cadence visible in the material is worth noting for planning: 3.8.0 in January 2025, 3.8.1 a week later, then 3.8.2 in June 2026. That is a long gap between the last two, which suggests either a stable codebase or a quiet maintainer. The repository metadata shows a push in August 2026, after the 3.8.2 tag.
The in-app updater is the feature most likely to bite you
The README advertises that "admins can check for new releases and upgrade the instance from the browser, with no shell access required". This is genuinely useful for the hosting profile XBackBone targets, which is often a shared PHP host where shell access is not available.
It is also the feature with the least visible safety net in the supplied material. A browser-triggered update has to write to the skeleton's Composer files, run the dependency resolution and then run database migrations, all inside a web request or a background job. The README does not describe a pre-update backup, a maintenance mode, or what happens if the process is interrupted halfway. The in-app updater is a convenience that converts a deployment step into a button press, and you should treat that button as equivalent to running the upgrade by hand.
The same caution applies in reverse to the downgrade story. The README's claim that you can downgrade by changing the required version of xbackbone/core is about code, not data. There is no mention of reversible migrations.
Where XBackBone is the wrong tool
If your requirement is a shared folder that a team browses and edits, XBackBone is the wrong shape. It is an upload-and-share service with a gallery and an activity log, not a sync client. There is no desktop sync agent in the feature list, no file locking, no collaborative editing, and no mountable filesystem.
The second case is scale. The README describes the project as "lightweight" and the stack is PHP with Livewire, which renders UI on the server. Every gallery page and activity log view is a PHP request. Content-addressed de-duplication reduces storage growth, but it does not reduce request cost, and the README gives no caching layer or CDN story beyond putting an S3-compatible backend behind it.
The third case is a single-user instance with no interest in ShareX. If you only want to drop files somewhere and get a link, the multi-user management, roles, quotas, two-factor authentication, passkeys and activity log are all overhead you will maintain and never use. The registration and account features are switchable through feature flags, but the database schema and the admin surface remain.
Alternatives: what changes if you pick something else
The obvious comparison is a plain web server directory with an upload endpoint bolted on. That approach has no database, no PHP application layer, no migrations and no upgrade ceremony. It also has no per-user tokens, no quotas, no activity log and no de-duplication. The difference is not features versus no features; it is whether you want an application with state to operate. XBackBone's whole value proposition is that the upload target knows who uploaded what and enforces limits. If you do not need that, you are paying for it in operational surface.
A second comparison is a static site generator or object storage bucket with a CDN in front. That gives you cheap serving and no PHP at request time, but the upload path becomes manual or scripted, and ShareX integration becomes something you write yourself rather than something you generate from a settings page. The README's one-click config generation for seven different clients is the concrete thing you would be rebuilding.
Within the self-hosted PHP space, the relevant distinction is the framework generation. The README states this is "rebuilt from the ground up on Laravel 13 and Livewire 4", and that it can import from a "legacy XBackBone instance, with old links transparently redirected". That import path is the migration story for existing users, and the redirect behaviour is what keeps previously shared links alive. If you are already on legacy XBackBone, the import feature is the reason to move rather than a reason to hesitate.
Licence, maintenance and what to verify before you commit
XBackBone is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes. For self-hosting, the practical implications are minimal. If you modify core/ and redistribute it, the licence terms apply to what you distribute. I am not giving legal advice; read LICENSE and, if you plan to redistribute a modified build, get your own reading.
The maintenance cost is the cost of running a Laravel application: a PHP runtime, a database, a queue or scheduler if the app uses one, and periodic dependency updates. The monorepo split reduces the cost of the application upgrade itself to a version constraint, but it does not remove the database from the equation, and the README does not describe a supported rollback for migrations.
Before adopting, verify three things. First, that your PHP version satisfies Laravel 13, since the README names the framework but not the minimum runtime. Second, that the storage backend you plan to use is one of the four listed, and if it is S3-compatible rather than S3 proper, that the compatibility is close enough for whatever the app does with it. Third, that the in-app updater can write to the skeleton's Composer files on your host, because if it cannot, you are back to shell access and the feature that justified the deployment shape is gone.
The security contact is a personal email address, sergio@brighenti.me, with reports handled outside the public issue tracker. That is a normal arrangement for a project of this size, and it is the address to use if you find something before you find a workaround.
Editorial conclusion
Adopt XBackBone if you already run ShareX or ScreenCloud and want the upload target on your own hardware, and if you are comfortable operating a Laravel application with a database and PHP 8. Do not adopt it if you need a static file server with no application layer, or if you cannot take a database backup before each upgrade. Before committing, verify that your PHP version satisfies the Laravel 13 requirement, that the storage backend you intend to use is one of Local, S3, FTP or SFTP, and that the in-app updater has write access to the skeleton's composer files.
Community notes