A
Quick update: Hetzner replaced the server
(new motherboard, CPU, RAM — drives stayed).
About 30 minutes of downtime and everything came
back up perfectly — Cloudron started all containers
automatically, no issues at all.
Now monitoring stability to see if the freezes
are gone. Thanks for the help!
Thanks for this — you just saved us. We've been chasing exactly this problem and couldn't figure out where it was coming from.
Quick update: Hetzner offered to replace the server
but keep my drives (new motherboard, CPU, RAM). The
replacement might have a different CPU (e.g. AMD
instead of Intel) or a different board.
Could this cause any issues with Cloudron? I'm
thinking the network interface name might change
(enp5s0 → something else). Is there anything else
I should watch out for?
@nebulon Thanks for the reply!
I wanted to check here first before opening a hardware ticket with Hetzner, to make sure I wasn't looking in the wrong place and it wasn't a Cloudron issue.
I've already checked journalctl --system --boot=-1 thoroughly. There is no "Reached target Shutdown" — the journal cuts off abruptly mid-operation (normal containerd shim cleanup messages, then nothing — as if someone pulled the power plug). No kernel panic, no oops, /sys/fs/pstore is empty after each freeze.
The Jul 16 crash was confirmed by Hetzner support as a hard freeze: "no video signal, no keystrokes" on KVM. They had to do a physical hardware reset.
So it does look like a hardware issue rather than Cloudron. I'll follow up with Hetzner. Thanks for helping me confirm that!
Hi,
I'm running Cloudron 9.2.0 on a Hetzner dedicated server (Ubuntu 24.04, 64 GB RAM, around 107 containers). The server occasionally hard-reboots on its own and I can't figure out why.
The only thing I see in the log before the crash is a lot of these errors, which pile up for a few minutes and then the server dies:
dockerd: [resolver] failed to query external DNS server ... i/o timeout
question=";191.101.249.180.in-addr.arpa. IN PTR"
It's the same thing over and over, mostly reverse DNS lookups of IP addresses. No kernel panic, no out-of-memory, disks and RAM are fine. The system is healthy right now — the DNS flood only happens in the minutes leading up to a crash.
Any idea what could be causing this and how to stop it?
Troubleshoot output:
Cloudron: 9.2.0
Ubuntu: noble 24.04
Linux: 6.8.0-136-generic
Processor: 13th Gen Intel(R) Core(TM) i9-13900
[OK] Root disk usage is OK (43%)
[OK] Memory usage is OK (41%)
[OK] Clock is NTP-synchronized
[OK] docker is running
[OK] MySQL is running
[OK] DNS is resolving via systemd-resolved
[OK] unbound is running
[OK] nginx is running
[OK] box v9.2.0 is running
======== Summary ========
PASS: 30 WARN: 0 FAIL: 0 SKIP: 1
Thanks!
Cloudron currently doesn't have a single sports or fitness app in the App Store. FitPub could be the first one, and it fits nicely into the self-hosted ecosystem alongside other federated apps already available on Cloudron.
Update: After more testing, I can confirm that normal video
uploads work correctly – the intermediate web video file is
created during HLS transcoding but gets properly deleted
afterwards. Only HLS remains on S3. 
However, videos imported from YouTube still leave the
intermediate web video file on S3 – it never gets cleaned up
after HLS transcoding is complete. 
So the issue seems to be specifically in PeerTube's YouTube
import pipeline, not in the transcoding process itself.
This is likely an upstream PeerTube bug rather than a Cloudron
packaging issue.
I'll open a report on the PeerTube GitHub.
Thanks again for the quick fix of start.sh! 
Thanks for the quick fix – after the update, production.yaml
is no longer being overwritten and web_videos: false persists
across restarts.
However, the issue still remains: even with web_videos set to
false in both production.yaml AND the Admin UI, newly uploaded
and imported videos are still being transcoded in Web videos
format (in addition to HLS).
So the config now holds correctly, but PeerTube seems to ignore
the setting and generates web videos regardless.
@james Sorry, perhaps we're misunderstanding each other.
After upgrading to PeerTube 8.2, newly uploaded videos started generating both HLS versions and Web Video versions. Before the upgrade, only HLS versions were generated.
Web Videos are disabled in the PeerTube Admin UI. The setting is also set to false in local-production.json.
While investigating, I noticed that after every application restart, /app/data/production.yaml contains:
transcoding:
web_videos:
enabled: true
If I manually change this value to false, it is set back to true after a restart.
I'm not concerned about the configuration file being overwritten. I'm trying to determine the actual cause:
As far as I know, there is no other place where Web Videos can be disabled. The option is disabled in the PeerTube Admin UI, and local-production.json is also set to false. Nevertheless, new uploads are still transcoded into both HLS and Web Video formats.
This worked correctly up to PeerTube 8.1, where only HLS files were generated.
@james Yes, that's exactly the issue — .transcoding.web_videos.enabled is being set to true on every restart, overriding the Admin UI setting. Would it be possible to fix start.sh to respect the value stored in the database instead of hardcoding it to true?
After upgrading PeerTube to 8.2 on Cloudron, the Web videos transcoding setting is being ignored.
I have Web videos disabled in Admin UI (only HLS enabled), but newly uploaded videos are still generated in both HLS and Web videos format.
It seems the upgrade to 8.2 overwrote production.yaml and set web_videos: enabled: true. The value reverts back to true after every restart, even if I manually change it to false. The Admin UI setting doesn't seem to take effect either.
Before the 8.2 update this worked correctly — only HLS was generated.
Anyone else experiencing this?
PeerTube v8.1.8 is out and it's a critical security release.
The SQL injection vulnerability fixed in v8.1.6 has been actively exploited since at least May 18, 2026. Attackers used it to generate root tokens and install a malicious plugin (peertube-plugin-google-analytics-js) that loads an external script.
v8.1.8 automatically removes the plugin and invalidates all OAuth tokens.
Release notes:
Please update the Cloudron package as soon as possible.
@murgero Got it, makes sense! No rush at all — really appreciate you working on it. Looking forward to trying it once it’s ready 
The manual fix worked for me. I ran the following in the web terminal (repair mode):
psql $CLOUDRON_POSTGRESQL_URL
ALTER TABLE webhooks ADD COLUMN IF NOT EXISTS project_id bigint NULL;
INSERT INTO migration (id) VALUES ('20260224215050');
\q
After restarting the app, migrations ran successfully and Vikunja 2.2.0 is up and running.
Thanks for the help!
gosu cloudron:cloudron /usr/bin/vikunja migrate
Thank you for your response. I tried your suggestion. After updating to 1.22.0, the app keeps crashing on startup with the same error. Here are the full logs:
Mar 23 18:37:57 ==> Updating OIDC configuration
Mar 23 18:37:57 time=2026-03-23T17:37:57.342Z level=INFO msg="Using config file: /app/data/config.yml"
Mar 23 18:37:57 time=2026-03-23T17:37:57.343Z level=INFO msg="Running migrations…"
Mar 23 18:37:57 time=2026-03-23T17:37:57.360Z level=ERROR msg="Migration failed: migration 20260224215050 failed: pq: column \"project_id\" of relation \"webhooks\" does not exist"
Mar 23 18:37:58 time=2026-03-23T17:37:58.108Z level=INFO msg="Running migrations…"
Mar 23 18:37:58 time=2026-03-23T17:37:58.130Z level=ERROR msg="Migration failed: migration 20260224215050 failed: pq: column \"project_id\" of relation \"webhooks\" does not exist"
Mar 23 18:37:59 ==> Changing ownership
Mar 23 18:37:59 ==> Starting Vikunja
Mar 23 18:37:59 ==> Updating OIDC configuration
Mar 23 18:37:59 time=2026-03-23T17:37:59.320Z level=INFO msg="Running migrations…"
Mar 23 18:37:59 time=2026-03-23T17:37:59.337Z level=ERROR msg="Migration failed: migration 20260224215050 failed: pq: column \"project_id\" of relation \"webhooks\" does not exist"
Mar 23 18:38:01 ==> Changing ownership
Mar 23 18:38:01 ==> Starting Vikunja
Mar 23 18:38:01 ==> Updating OIDC configuration
Mar 23 18:38:01 time=2026-03-23T17:38:01.431Z level=INFO msg="Using config file: /app/data/config.yml"
Mar 23 18:38:01 time=2026-03-23T17:38:01.432Z level=INFO msg="Running migrations…"
Mar 23 18:38:01 time=2026-03-23T17:38:01.463Z level=ERROR msg="Migration failed: migration 20260224215050 failed: pq: column \"project_id\" of relation \"webhooks\" does not exist"
Mar 23 18:38:25 ==> Changing ownership
Mar 23 18:38:25 ==> Starting Vikunja
Mar 23 18:38:25 ==> Updating OIDC configuration
Mar 23 18:38:25 time=2026-03-23T17:38:25.421Z level=INFO msg="Running migrations…"
Mar 23 18:38:25 time=2026-03-23T17:38:25.452Z level=ERROR msg="Migration failed: migration 20260224215050 failed: pq: column \"project_id\" of relation \"webhooks\" does not exist"
I then enabled repair mode and ran the migration manually in the web terminal:
gosu cloudron:cloudron /usr/bin/vikunja migrate
Result:
time=2026-03-23T17:37:06.471Z level=INFO msg="Using config file: /app/data/config.yml"
time=2026-03-23T17:37:06.471Z level=INFO msg="Running migrations…"
time=2026-03-23T17:37:06.490Z level=ERROR msg="Migration failed: migration 20260224215050 failed: pq: column \"project_id\" of relation \"webhooks\" does not exist"
Same error — the migration fails both on startup and when run manually.
Hi,
I tried updating the Vikunja package to version 1.22.0 (Vikunja 2.2.0), but the app fails to start after the update.
The log shows the same error on every startup:
Migration failed: migration 20260224215050 failed: pq: column "project_id" of relation "webhooks" does not exist
The app keeps retrying but never becomes healthy (healthcheck EHOSTUNREACH on port 3456). I had to roll back using the Cloudron backup restore.
I also find it strange that package 1.22.0 was published 19 days ago, but I only received the update notification today. Is that expected behavior or is there an issue with update notifications?
Thank you so much for your help.
I actually already have that packaged! though it needs an update for the latest version
That’s great to hear! I’d definitely be interested once it’s updated to the latest version. I’ve been testing it on another VPS and it works without any issues — it’s a great solution for a single user.
@murgero Hi, would it be possible to package GoToSocial? It would be great to have it available on Cloudron.