Adding to the note above about the DROP NOT NULL change — might not be it, but we ran into a similar error on two Cloudron instances. 8.3 requires a manual migration script that has to be run after the upgrade; it's in the IMPORTANT NOTES of the v8.3.0 release. DROP NOT NULL only silences the error, the script also moves the infohashes into the new table and fills videoSearch.

Take a backup first, it does DROP COLUMN. With PeerTube running, in the container:

cd /app/code/server
gosu cloudron:cloudron env HOME=/home/cloudron NODE_ENV=production node dist/scripts/migrations/peertube-8.3.js

Expected output:

Filling videoSearch table with existing videos...
videoSearch table filled.

Migrating video infohashes...
Video infohashes migrated.

Check, should return 0 rows:

SELECT column_name FROM information_schema.columns
WHERE table_name IN ('videoStreamingPlaylist','videoFile')
  AND column_name IN ('p2pMediaLoaderInfohashes','infoHash');

Then restart the app and re-encode the affected videos. But you may have done this already.

PeerTube handles private video files differently from public ones. Access to private files goes through PeerTube's authentication checks, so a CDN or reverse proxy in front of those requests can complicate things.

I'd try isolating that part before changing the Range handling.

In Firefox's Network tab, compare a working Unlisted video with the same video set to Private. For the failing HLS requests, check the actual response status, the Range request header (if present), and the Content-Range, Content-Length and Cache-Control response headers.

A 206 Partial Content response should describe the requested byte range. But NS_BINDING_ABORTED alone doesn't establish a Range bug — Firefox can also cancel requests when the player retries or changes its playback strategy.

The most useful test might be to temporarily bypass Bunny for an authenticated private-video request, without making the video publicly accessible. If playback works through the Cloudron origin but fails through Bunny, that would narrow the issue down considerably.

Bunny supports Range requests, but its cache and origin-fetch behaviour may differ depending on Cache Slicing settings. I'd also make sure protected HLS paths aren't being cached and served across different users without proper authorization.

The other two problems seem worth tracking separately. In particular, I'd avoid treating the manual PostgreSQL DROP NOT NULL change as a permanent migration fix without checking the schema history and taking a backup.

Could you confirm whether Bunny is proxying the PeerTube application domain itself, or only the video storage/CDN URLs?