Can't reach Web-UI anymore

[LukasStipar]

Overnight I suddenly can't reach MediaCMS anymore. Yesterday it was working fine, I think it may have auto-updated overnight. I get a 502 Bad Gateway (nginx/1.22.1) error and the logs for the web container say the following:

web-1 | 2026/06/03 15:03:25 [error] 55#55: *27 connect() failed (111: Connection refused) while connecting to upstream, client: 172.22.0.1, server: , request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://127.0.0.1:9000", host: "media.lukasstipar.com", referrer: "https://media.lukasstipar.com/"

The only other thing that seems weird in the logs is this:

web-1 | Checking for script in deploy/docker/prestart.sh celery_worker-1 | 2026-06-03 15:01:21,191 INFO Included extra file "/etc/supervisor/conf.d/supervisord-celery_long.conf" during parsing web-1 | Running script deploy/docker/prestart.sh celery_worker-1 | 2026-06-03 15:01:21,191 INFO Included extra file "/etc/supervisor/conf.d/supervisord-celery_short.conf" during parsing celery_worker-1 | 2026-06-03 15:01:21,191 INFO Included extra file "/etc/supervisor/conf.d/supervisord-debian.conf" during parsing celery_worker-1 | 2026-06-03 15:01:21,193 INFO RPC interface 'supervisor' initialized celery_worker-1 | 2026-06-03 15:01:21,193 CRIT Server 'unix_http_server' running without any HTTP authentication checking celery_worker-1 | 2026-06-03 15:01:21,193 INFO supervisord started with pid 1 celery_worker-1 | 2026-06-03 15:01:22,194 INFO spawned: 'celery_short' with pid 53 celery_beat-1 | __ - ... __ - _ celery_worker-1 | 2026-06-03 15:01:22,195 INFO spawned: 'celery_long' with pid 54

Any Idea what might be the problem? I can neither reach it via the Domain (through a cloudflare tunnel that definitely works) nor the local IP address. Help would be greatly appreciated since I run the video content of my website on this instance.. :/

Thanks in advance! :)

[ZIOOIZ8]

Yes, I've the same Problem.

[ZIOOIZ8]

My Log:

Checking for script in deploy/docker/prestart.sh
Running script deploy/docker/prestart.sh
Enabling uwsgi app server
Enabling nginx as uwsgi app proxy and media server
Starting server using supervisord...
/usr/lib/python3/dist-packages/supervisor/options.py:474: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
self.warnings.warn(
2026-06-04 15:25:15,734 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
2026-06-04 15:25:15,734 INFO Included extra file "/etc/supervisor/conf.d/supervisord-debian.conf" during parsing
2026-06-04 15:25:15,734 INFO Included extra file "/etc/supervisor/conf.d/supervisord-nginx.conf" during parsing
2026-06-04 15:25:15,734 INFO Included extra file "/etc/supervisor/conf.d/supervisord-uwsgi.conf" during parsing
2026-06-04 15:25:15,736 INFO RPC interface 'supervisor' initialized
2026-06-04 15:25:15,736 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2026-06-04 15:25:15,736 INFO supervisord started with pid 1
2026-06-04 15:25:16,737 INFO spawnerr: can't find command '/home/mediacms.io/bin/uwsgi'
2026-06-04 15:25:16,738 INFO spawned: 'nginx' with pid 93
2026/06/04 15:25:17 [error] 94#94: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.160.1, server: , request: "GET / HTTP/1.1", upstream: "uwsgi://127.0.0.1:9000", host: "media.mydomain.tld"
2026-06-04 15:25:17,006 INFO success: nginx entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
192.168.160.1 - - [04/Jun/2026:15:25:17 +0000] "GET / HTTP/1.1" 502 157 "-" "Uptime-Kuma/1.23.17"
2026-06-04 15:25:18,008 INFO spawnerr: can't find command '/home/mediacms.io/bin/uwsgi'
2026-06-04 15:25:20,009 INFO spawnerr: can't find command '/home/mediacms.io/bin/uwsgi'
2026-06-04 15:25:23,012 INFO spawnerr: can't find command '/home/mediacms.io/bin/uwsgi'
2026-06-04 15:25:23,012 INFO gave up: uwsgi entered FATAL state, too many start retries too quickly

It seems, it's a problem with "uwsgi".

[ZIOOIZ8]

KI investigation:

That pretty much confirms the suspicion.
The following is missing from /home/mediacms.io/bin/:
uwsgi
but the supervisor is trying to start:
/home/mediacms.io/bin/uwsgi
and therefore fails with:
spawnerr: can't find command '/home/mediacms.io/bin/uwsgi'
It is also interesting to note what is there instead:
gunicorn
To me, that looks like a faulty build or an incomplete image conversion.
Previously, the startup script expected:
uWSGI
However, the current image now only contains
gunicorn
available.

It might help; it does indeed look like a build error.

[LukasStipar]

Is there any way to revert to a previous build? I was only able to find release tags from multiple months ago..

[mrrcollins]

I used mediacms/mediacms:full with the same results, no uswgi to run.

[mikaelmhansen]

I experienced the same.
I brought the service backup by changing the mediacms container image used in the docker-compose file from mediacms/mediacms:latest to mediacms/mediacms:7

Looks like a bug in the new image, or a change not gone well.

[LukasStipar]

I just tried to revert to mediacms:7 and now the service is up again but the console spits out a new admin password and all my videos aren't showing in the web-ui. They are still in their place in the appdata folder and the database also didn't re-initialize or anything, it just reported the usual "seems to contain a database - skipping initialization..."

[mgogoulos]

Only Docker installation is supported since version 8, uwsgi (python application server) was replaced in favor of gunicorn. The steps to update on the Docker installation would be

1. docker pull mediacms/mediacms:latest
2. docker pull mediacms/mediacms:full # if you are using the full image, with Whisper TTS
3. git stash # if you have made local changes, otherwise not needed
4. git pull # to get the latest code
5. git stash pop
6. docker-compose down
7. docker-compose up -d

You cannot use version 8 with the non Docker setup, or at least you cannot do it without spending some time (you have to change uwsgi loading into gunicorn, install dependencies etc, all of these are not included)

And as far as the need to pull new image, and update the code too, this is going to be decoupled soon (only docker-compose.yaml will be enough, without the need to the code base)

Hope this helps