Cloudron Forum

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:

• Is this an intentional change in PeerTube 8.2?
• Is this a bug in the Cloudron PeerTube package?
• Or is this a bug in PeerTube 8.2 itself?

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?

Thank you very much for the quick update.

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!

@nebulon said:

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.

@murgero said:

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.

The issue was resolved by manually setting the monospace font in Firefox (about:config).

Previously, a different font was being used. After forcing "Noto Sans Mono", everything works correctly.

I'm not sure why it changed on its own.

Sorry for the confusion — it looks like this is not a Cloudron issue.

I tested the web terminal in Vivaldi and the font looks normal there.

So it seems to be related to Firefox on my system rather than Cloudron itself.

I am using Firefox on Arch Linux.

The default monospace font on my system is Noto Sans Mono.

Output of fc-match monospace:
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"

I also have several other monospace fonts installed (Meslo Nerd Font Mono, FiraCode Nerd Font Mono, DejaVu Sans Mono, Liberation Mono, etc.), but the default monospace resolves to Noto Sans Mono.

Before updating Cloudron to version 9.1.3 the font in the web terminal was fine and easy for me to read.

After the update it changed to a different monospace font which is harder for me to read. I will also try testing it in another browser.

After updating Cloudron to version 9.1.3, I noticed that the font in the web terminal inside applications has changed.

Is there any way to change the font or configure a different one?

Unfortunately, the new font is quite hard for me to read. The previous one worked much better for me.

Small update from my side.

I contacted Spamhaus through their ticket system and after communicating with them it seems everything is now resolved and the IP has been removed from the blacklist. Emails are working normally again.

Sorry for the false alarm and thank you for your help and responses. I did notice that occasionally I still see the error that was present in the previous version, so I will keep

After further investigation it seems that this is not a Cloudron bug, but an actual listing of the server IP on a blacklist.

I checked the mail server logs on the Cloudron host in:

/home/yellowtent/platformdata/logs/mail/app.log
/home/yellowtent/platformdata/logs/mail/app.log.1

I do not see any signs of a compromised server or bulk spam activity. The logs mainly contain normal system notifications and failed SMTP authentication attempts from random internet bots.

At the moment I do not see any evidence that the server is compromised or that it is sending spam.

Is it possible that I am looking in the wrong place? Are there any other Cloudron logs related to outgoing mail or postfix that I should check?

Both today – sometimes it’s just one, sometimes both.​​​​​​​​​​​​​​​​