Chevereto 4.5: what the AGPL edition actually gives you

The problem Chevereto solves is platform ownership, not photo display

Most image hosting starts on somebody else's infrastructure. You upload to a service, you accept its content rules, and you accept that the service can change those rules or close. Chevereto's pitch is that you run the equivalent of that service yourself. The README frames it as building a media-sharing website on your own server with complete autonomy over the hosting environment and policies, which is a statement about governance as much as about software. The repository topics name the same territory: image-host, image-sharing-website, photo-gallery-application, video-hosting.

The audience follows from that. This is for someone who wants a Flickr or Imgur shaped site where other people register, upload, and organise media, and where the operator sets the rules. It is not aimed at a photographer who wants to publish a portfolio. The feature list is full of operator-facing concerns: user accounts with registration, profiles, 2FA and roles; granular content privacy settings; categories, tags and albums; multi-language support across more than 30 languages. A single-author gallery would use a small fraction of that and pay for all of it in setup time.

Multi-tenancy is the architectural claim worth examining

The README lists multi-tenancy as a headline capability: host multiple independent sites from a single installation. That is the most consequential line in the feature list, because it changes what the software is. A normal self-hosted gallery maps one installation to one site. Chevereto's 4.5 branch is presented as mapping one installation to several, which is why the repository also carries the multi-storage topic alongside aws-s3 and s3-compatible.

What the README does not give is the mechanism. It does not explain how tenant isolation is enforced, whether tenants share a database schema or get separate ones, or how storage credentials are scoped per tenant. Those answers live in the admin manual and the editions comparison page, both linked from the README but not reproduced in it. Treat multi-tenancy as a documented capability whose operational details you must read before you rely on it. If you plan to run two unrelated brands from one install, that is the first thing to confirm.

The storage side is clearer at the level of intent. The topics list chunked-uploads, multi-storage, aws-s3 and s3-compatible, which together describe a system designed to push large files to object storage rather than keep everything on the web server's disk. Chunked uploads matter for video, which the project supports alongside images. The README's own requirements list does not mention object storage, so S3 compatibility reads as an option rather than a baseline.

The stack is deliberately ordinary: web server, PHP, MySQL, optional Redis

The requirements section is short and specific. A web server, PHP, MySQL Server (the README parenthesises MariaDB Server as an alternative), and Redis as optional. That is the whole dependency surface as stated. No message broker, no separate search service, no Node runtime in the requirements list.

The optional Redis is worth noting because it tells you where the project expects pressure. Caching is listed under performance in the feature list, next to CDN support and image optimization. Redis being optional means a small deployment can run without it and a busier one adds it. The README does not state what Redis is used for specifically, so the honest reading is that it is a cache layer you can add when the database becomes the bottleneck.

Because the stack is ordinary, the hosting story is ordinary too. The install guides cover Docker, VPS providers (DigitalOcean, Linode and Vultr are named), cPanel and Plesk. The Docker image is described as multi-arch, compatible with x86_64 and arm64, which means an ARM VPS is a supported target rather than an experiment. Beyond the manual guides, the README also points at Installatron, Softaculous and SwiftWave as one-click installers.

Getting it running: download, install path, then update

The README gives two download routes. A direct download from https://chevereto.com/api/download/latest, or the latest 4.x.x.zip from the GitHub Releases page. The current release line shown is 4.5.7, published 2026-08-20, following 4.5.6 and 4.5.5. If you are scripting a deployment, the direct download URL is the stable endpoint; if you want a pinned artefact, take the zip from a specific release tag instead.

From there the README directs you to a guide rather than listing commands. Docker has its own repository at github.com/chevereto/docker, with a pure Docker guide and a Chevereto Docker guide in the v4 docs. There are separate guides for VPS, cPanel and Plesk. The README does not reproduce the docker run invocation or any environment variable names, so I cannot give you the exact container flags from this material. What it does tell you is that the image is multi-arch, so the same reference works on x86_64 and arm64 hosts.

The configuration keys are likewise not in the README. There is no sample .env, no list of database constants, no storage credential names. Everything at that level is in the installation documentation at v4-docs.chevereto.com. If you are evaluating Chevereto for a deployment you have to script, budget time to read the installation page before you can estimate the work, because the repository itself will not tell you.

Updating is a separate documented procedure from installing. The README points at an Updating guide for keeping a V4 system current. Upgrading is a third thing again, covering the move from V3 to V4, with a separate guide and a reference page for V3 users. V2 users are told to follow the V3 upgrading guide but skip directly to V4. Three distinct procedures for three distinct situations is a sign the project has been through enough version churn to need the distinction.

Where Chevereto is the wrong tool

The clearest failure case is scope mismatch. If what you want is a folder of images rendered as a browsable site, Chevereto is a database-backed application with user accounts, roles, 2FA and a multi-tenant layer. You would be installing a platform to avoid installing a gallery. The feature list is not padding; it is the product, and none of it is optional in the sense of being switched off at install time.

The second case is operational capacity. The requirements are minimal by the standards of PHP applications, but they are not zero. You need a web server, PHP, and MySQL or MariaDB, and you need to keep them patched. The README's claim that Chevereto runs anywhere with minimal requirements is accurate as far as it goes, and it still assumes you can administer a LAMP-shaped stack. Someone who has never managed a MySQL server will find the Docker path easier than the cPanel path, but neither removes the database.

The third case is licensing. This is not a limitation of the software so much as a boundary on what you may do with it, and it is covered below.

One more practical caveat: the README does not state supported PHP or MySQL versions. It links to stack pages for the web server, PHP, MySQL and Redis instead. Before you provision anything, read those pages, because the repository will not tell you whether your distribution's PHP package is new enough.

The AGPLv3 and commercial split, and what it means for a fork

Chevereto ships under two licences: AGPLv3 for the open source edition, and a commercial proprietary licence. The README states the split plainly and links to an editions comparison page. The AGPLv3 text quoted in the README is the standard grant: redistribute and modify under the same licence, with no warranty.

The practical consequence of AGPLv3 for a hosted service is the network clause. If you run a modified Chevereto as a public service, the licence obliges you to offer the corresponding source to users of that service. For an operator running the software unmodified, this is mostly a formality. For someone who wants to build a proprietary product on top of Chevereto, or to keep modifications private, the AGPL edition is the wrong starting point and the commercial licence is the intended route. The README also notes that contributions to the repository fall under AGPLv3.

I am not giving legal advice here, and the README does not spell out which features sit behind which edition. It links to a comparison page for that. If your plans involve reselling, white-labelling, or keeping changes closed, read that page and, where the answer determines your business model, get proper advice. The licensing question is not a footnote to the technical evaluation, it is a gating decision.

How Chevereto differs from a static site generator gallery

The obvious alternative for a self-hosted image site is a static gallery generator: a tool that reads a directory of files and emits HTML you serve from a CDN or a plain web server. The difference in approach is fundamental. A static generator has no database, no user accounts, no upload endpoint, and no runtime. It cannot accept a file from a visitor. Its output is a build artefact.

Chevereto is the opposite shape. It accepts uploads from users, stores them (optionally in S3-compatible object storage, with chunked uploads for large files), records them in MySQL, and serves them through PHP with an optional Redis cache. That is what makes multi-user registration, roles, 2FA, privacy settings and albums possible at all. You cannot bolt those onto a static build without adding the application layer back.

The trade is operational. A static gallery has almost no attack surface and costs nothing to host at low traffic. Chevereto has a login system, a database, and a file upload path, all of which need patching and monitoring. Choose the static route if your content is authored by you and published rarely. Choose Chevereto if the point is that other people upload, and you need accounts, storage backends and per-user privacy to make that work.

Maintenance cost and what to verify first

Maintenance here is the maintenance of a web application plus a database plus, if you enable it, Redis and object storage. The release cadence visible in the supplied material is regular: 4.5.5 in July 2026, 4.5.6 and 4.5.7 in August 2026. Each of those is a version you would be expected to apply through the Updating guide. The README does not describe an automatic updater or a supported rollback path, so plan for the update as a manual operation with a database backup beforehand.

The multi-tenant capability raises the maintenance ceiling if you use it. One installation serving several sites means one maintenance window covers all of them, and one failed update affects all of them. That concentration is the point of multi-tenancy and also its risk. If the sites have different uptime expectations, a single installation is the wrong topology regardless of what the software supports.

What to verify, in order. First, the editions comparison page, because the licence and feature split determines whether the AGPL repository is even the right artefact for you. Second, the stack pages for PHP, MySQL and the web server, because the README gives no version numbers and your distribution's packages may not match. Third, the Docker or VPS guide for your chosen path, so you know what the update procedure actually involves. Fourth, if you intend to run more than one site, the admin manual's treatment of multi-tenancy, since the repository states the capability but not the isolation model. Until those four are answered, the install is not planned, it is guessed.

Editorial conclusion

Adopt Chevereto if you are standing up a multi-user media site on your own hardware and you accept a PHP, MySQL and optional Redis stack as the price of admission. Do not adopt it if you only need a read-only gallery for a handful of photos, or if you cannot operate a database and web server yourself. Before committing, verify three things in this order: which licence tier covers the features you need, whether your PHP and MySQL versions satisfy the stack documentation, and how your chosen install path handles updates, because the repository separates updating from upgrading and the two are not the same operation.

Official sources

1. chevereto/chevereto on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases