PhotoSuite, a near-clone of Photopea, shows why self-hosted software needs provenance
The selfh.st newsletter of 9 October 2026 recounts the controversy around PhotoSuite and PhotoCraft, two purported self-hosted Photopea clones with a contested code history. Before adopting a community fork, verify its provenance, commit history and license.
9 October 2026. Ethan Sholly’s Self-Host Weekly newsletter leads its editorial with a controversy rattling the self-hosting community. A suite. Two open-source alternatives to Adobe — PhotoSuite, then PhotoCraft — appear back to back. An accusation. The developer of Photopea sees copies and reports the repository to GitHub. Why it matters: in self-hosting, trust is earned through code provenance, and this episode shows how fragile that trust can be.
Two projects that look a little too alike
PhotoSuite is described by selfh.st as a near-clone of Photopea, the browser image editor that became a community reference point. The release does not pass quietly: Ivan Kutskir, the creator of Photopea, is among the first to raise the alarm. He reports the project to GitHub, after which the repository is temporarily closed and scrubbed of the accusation.
The timeline then gets tangled. PhotoCraft ships in turn. The PhotoSuite repository reopens, crediting PhotoCraft as the app’s “foundation.” Except the new claim is immediately scrutinised: the timestamps in PhotoSuite’s repository predate PhotoCraft’s existence. The stated lineage does not hold, and the real order of events becomes hard to reconstruct — even for readers following the Reddit and Hacker News threads devoted to the affair.
Sholly’s recommendation is blunt: “steer clear of the new alternatives until they can prove they’re more than just vibe coded derivatives of somebody else’s hard work.” The term is loaded: it points at code generated hastily, often by AI, without the rigour of a genuinely maintained project.
Photopea, a recurring target for the community
This is not Photopea’s first run-in with the self-hosting crowd. A few years earlier, the Noted.lol editor publicly scoffed at the pricing of Photopea’s self-hosted edition. The creator, as selfh.st notes, “just can’t catch a break.” That backstory matters: it explains why a clone provokes so much emotion, and why the legitimacy of a fork is such a live question.
Photopea holds a particular place in the ecosystem. It is a beloved tool, built for the most part by a single person, with a business model resting partly on advertising and paid options. For the self-hosting community — people seeking an Adobe alternative they can run at home — Photopea is both a technical benchmark and an economic sore point. A clone arriving unannounced therefore touches both code ownership and a community’s sensitivities.
That is precisely the soil where dubious derivatives flourish: strong demand, a tense business model, and a real technical barrier to rebuilding the tool. The clone promises to solve all three at once, by reusing what has already been built.
What provenance reveals, and what it does not
The PhotoSuite–PhotoCraft affair illustrates a point of method for anyone installing self-hosted software: provenance is not a legal nicety, it is an operational security criterion. A fork whose history cannot be reconstructed is a fork whose quality and intent cannot be assessed. Three questions are enough to start: where did the code come from, who maintains it, and under what license.
An incoherent commit history — timestamps that do not line up, a “foundation” credit pointing to a younger project — is an immediate red flag. It does not prove malice, but it signals that the project was not run like a real, maintained codebase. And for a service you are about to expose on a NAS or VPS and hand your files to, the minimum requirement is understanding what you are running.
The license completes the picture. A clone reusing Photopea code — or anyone else’s — must respect the original’s license. If the lineage is murky, license compliance is murky too, and the end user inherits a legal risk on top of a technical one. Self-hosting rests on the confidence that you can read the code; when that reading becomes impossible, trust loses its foundation.
Vibe coding, the fuel for low-cost clones
The vibe-coded label selfh.st uses deserves a closer look. It describes a practice that has become routine: generating an entire application by dictating intent to a model, without reading or understanding the code it produces. The result can be impressive in a demo and fragile in production — exactly the profile of the clones that appear within days around a popular tool like Photopea.
For the self-hosting community, the risk is double. First, a security risk: code generated without review can ship dubious dependencies, backdoors, or flaws nobody has ever audited. Second, a longevity risk: a project born from a single generator run often has no durable maintainer and no roadmap, and vanishes as soon as the hype fades. Installing such software on your NAS means betting its stability on a repository whose author and future you do not know.
The PhotoSuite–PhotoCraft controversy is instructive precisely because it shows how even lineage — who copied whom — becomes impossible to establish when the history is manufactured after the fact. The contradictory timestamps are not an archival detail; they are provenance signals that do not lie. When they fail to line up, the whole chain of trust breaks.
The reflex to adopt before installing a fork
The episode is not an argument for retreating to big vendors. The self-hosting community ships remarkable projects every week, often more transparent than plenty of proprietary software. It is an argument for a verification reflex, the same one you would apply to a critical software dependency.
Before adopting a fork or clone: read the commit history and check its coherence, identify the maintainer or maintainers and their track record, confirm the license and its compatibility with the upstream source, and wait for the project to prove itself rather than installing the first release. That delay is not timidity: in self-hosting, stability and security always beat novelty.
None of this requires an audit before every install. A few minutes spent reading the commit graph, the issue tracker and the license file will surface most derivative projects immediately — the contradictory timestamps that tripped up PhotoSuite are visible to anyone who looks. The discipline is less technical expertise than the willingness to look at all, and to let a project earn a place on your hardware before it gets one.
The PhotoSuite–PhotoCraft controversy has at least one virtue: it reminds us that the “open source” label guarantees nothing by itself. A public repository can be a sincere project, a slapdash derivative or a disguised copy. The difference is not visible in the storefront; it is visible in the history.
Verdict
If you are looking for a self-hosted alternative to Photopea, stick with the original project or with forks whose lineage is documented and whose license is clear, and let PhotoSuite and PhotoCraft prove themselves before installing either — their commit history does not, today, resolve the doubt. If you maintain a directory or list of self-hosted software, require verifiable provenance before referencing a project: your readers’ trust is your only capital. And whatever you install at home, apply the same reflex as for a critical dependency: read the history, identify the maintainers, confirm the license, and only then deploy.