Uploads fail, or updates misbehave

This page covers file uploads that fail and the common ways updates behave unexpectedly. It is for whoever runs the server. For errors shown while installing an update, see When an update fails.

Large uploads fail

The admin panel says File too large. Maximum size is NMB. or the upload simply fails with an error page. There are four limits in the site itself, and others outside it.

Variable	Default	Applies to	If a file is bigger
UPLOAD_MAX_IMAGE_MB	10	Posters and pictures put into settings	"File too large. Maximum size is 10MB."
UPLOAD_MAX_GALLERY_MB	100	Gallery photos and videos	"File too large. Maximum size is 100MB."
UPLOAD_MAX_FILE_MB	50	Member files	"File too large. Maximum size is 50MB."
UPLOAD_MAX_TRACK_MB	50	Rehearsal tracks	"File too large. Maximum size is 50MB."

Raise a limit in the site's settings (the environment variable) and restart. Then check the limits outside the site, which are tighter in some set-ups:

• Your reverse proxy. nginx refuses request bodies over 1 MB unless you set client_max_body_size, and answers with a "413 Request Entity Too Large" page. Set it above your largest limit, for example client_max_body_size 110m;. Caddy has no limit by default.
• Cloudflare Workers. A request body is limited to 100 MB, so keep UPLOAD_MAX_GALLERY_MB under that (the product's own notes suggest under about 90). Cloudflare's network in front of a Worker has plan limits of its own.
• A slow connection or a short proxy timeout can end a large upload before it finishes. Raise the proxy's timeout, or upload smaller files.

Some files are refused by type, with a message that says so:

• Rehearsal tracks must be MP3, M4A, AAC or OGG. A WAV file is refused with "That file type is not supported. Upload an MP3 or M4A (WAV files are too large; convert them first)."
• Pictures in settings must be JPEG, PNG, GIF, WebP or SVG.
• Gallery files: JPEG, PNG, GIF, WebP, MP4, WebM or MOV.
• Member files: PDF, Word, Excel, PowerPoint, audio, images or text.

S3 errors

With S3-compatible storage the log shows lines such as Upload error: Error: S3 PUT failed: 403 .... The number is the storage service's answer, followed by the first part of its message.

Error	Likely cause
S3 PUT failed: 403	The key or secret is wrong, the key may not write to that bucket, or the region is wrong. For Amazon S3 set S3_REGION to the bucket's real region. The default is auto, which suits Cloudflare R2 and not Amazon.
S3 PUT failed: 404	The bucket name is wrong or does not exist, or the endpoint or the path style is wrong. S3_PUBLIC_BUCKET and S3_PRIVATE_BUCKET must both exist.
S3 GET failed: / S3 HEAD failed:	The same causes, when reading a file.
A connection error	S3_ENDPOINT is wrong or not reachable from the server.

S3_FORCE_PATH_STYLE defaults to true whenever S3_ENDPOINT is set (the form most self-hosted stores like MinIO need), and to false without an endpoint (Amazon). Providers that want the bucket in the host name need S3_FORCE_PATH_STYLE=false. See S3-compatible storage.

"Update now" is missing

On the Updates page you see the manual steps instead of the button, and the dashboard says How to update. The site is not in self mode. The causes:

Cause	How to tell	Fix
The server was not started by the launcher	It runs with npm run start:direct or node server/entry/node.js. The log has UPDATE_MODE=self needs the server to be started by the launcher if you set UPDATE_MODE=self.	Start it with npm start (node server/launcher.js), or the Docker image.
UPDATE_MODE=notify is set	npm run config:check shows notify. (Not reliable alone: see How updates work.)	Remove the setting, or set self, and restart.
It is a Cloudflare Worker	The Updates page steps include npx wrangler deploy.	A Worker cannot replace its own code. Use Update by hand.
There is no licence key	The page says the site is not checking for updates.	Set LICENSE_KEY: Your licence key.

The page shows nothing about updates at all, and says "Updates for this site are looked after by whoever hosts it", when UPDATE_MODE=off.

Update errors and the "went back" message

Everything shown in red on the Updates page, including "Version X was installed but ... so the site went back to the version it was on", is explained, with what to do, on When an update fails.

"Registered to another website"

The check was refused with "This licence key is registered to another website." Either the site's SITE_URL is a different website from the one the key was issued for, or the key was already seen on one. See How a key is tied to its website. To move the key, write to support@choirmastercms.com.

An update was lost after recreating a container

You updated with Update now, then removed and recreated the container (docker compose down and then up), and the site is back on the old version.

A downloaded release lives in /app/data/releases. If /app/data is not a named volume, a container made again after docker compose down starts with a new empty data folder. The SQLite stack has the named volume. The PostgreSQL and MinIO stack does not. Add a volume for /app/data as shown in Update a Docker site, or update by building a new image.

Your database and files are not affected: they are in PostgreSQL and MinIO.

The footer link will not switch off on a Standard licence

The Show "Powered by Choir Master CMS" box under Site Settings > Footer has no effect. The site treats you as the Community edition until a completed update check has told it otherwise. Check that:

1. LICENSE_KEY is set to your Standard licence's key, and UPDATE_MODE is not off.
2. The server can reach the release server (UPDATE_URL).
3. On the Updates page, press Check now. A red "The last check for updates did not work" banner means no check has completed: fix that first (When an update fails).
4. If the Updates page shows a successful check, but the licence is still treated as Community, the licence on record is Community. Write to support@choirmastercms.com.

Once a check has completed, the edition is remembered and survives later failed checks. See Community and Standard editions.