Backup uploads generate excessive TUS PATCH requests due to fixed small chunk size

[reniko]

Describe the bug
Not sure if it a bug, but when backing up an Immich PostgreSQL database (~300 MB), the upload from the agent to the server generates an extremely high number of PATCH requests to /tus/files/<id>.

Observed behavior:

• request method: PATCH
• path: /tus/files/<id>
• response: 204 No Content
• protocol: HTTP/2
• sustained for multiple minutes
• measured rate: roughly 9,000–12,500 requests per minute

As the agent automatically uses the public URL of portabase it goes over my proxy (traefik). Normally, I have rate limiting enabled. In that case, the upload is blocked with HTTP 429 Too Many Requests. The backup upload works when request rate limiting is disabled.

Creating the dump itself takes ~30 seconds. Uploading ~7 Minutes within the same machine.

From Traefik access logs, this looks like many very small upload chunks rather than retries. The upload is successful without rate limiting, just very request-heavy.

Questions:

1. Is this request volume expected for a ~300 MB backup upload?
2. Is the upload chunk size configurable in the agent or server?
3. Is there a recommended reverse proxy configuration for /tus/files?
4. Could larger chunks / fewer PATCH requests be supported to make this work better behind common reverse proxies?
5. Could the URL of the porabase server be configurable to avoid the proxy (at least when portabase and agent are running on the same server; same docker compose stack in my case)?

Environment:

• Portabase agent v1.1.6
• reverse proxy: Traefik (via Pangolin)
• database: PostgreSQL / Immich
• backup size: ~300 MB

Example access log entries:

To Reproduce
Steps to reproduce the behavior:

1. Hit "Backup" in a postgres database (immich in my case)

Expected behavior
Much less chunks and much faster upload speed

Screenshots

Desktop (please complete the following information):

• OS: Windows 11
• Browser Chrome
• Version 145

Additional context
Environment:

• Portabase agent v1.1.6
• Portabase v1.4.19
• reverse proxy: Traefik
• database: PostgreSQL / Immich
• backup size: ~300 MB

Example access log entries:
{"ClientAddr":"172.20.0.1:48754","ClientHost":"172.20.0.1","DownstreamContentSize":0,"DownstreamStatus":204,"Duration":3205619,"RequestHost":"portabase.example.com","RequestMethod":"PATCH","RequestPath":"/tus/files/2a9a871a0a51502c316f48fa61785c59","RequestProtocol":"HTTP/2.0","RetryAttempts":0,"RouterName":"95-portabase-router@http","ServiceName":"95-portabase-service@http","StartUTC":"2026-03-06T17:49:54.486255808Z","TLSCipher":"TLS_AES_128_GCM_SHA256","TLSVersion":"1.3","downstream_Content-Type":"","entryPointName":"websecure","level":"info","msg":"","origin_Content-Type":"","request_Content-Type":"application/offset+octet-stream","request_X-Forwarded-Proto":"https","request_X-Real-Ip":"172.20.0.1","time":"2026-03-06T18:49:54+01:00"}

/var/log/traefik# cat access.log | jq -r 'select(.RequestPath|startswith("/tus/files")) ' | sort | uniq -c
5670 2026-03-06T17:45
11149 2026-03-06T17:46
10929 2026-03-06T17:47
12531 2026-03-06T17:48
12254 2026-03-06T17:49
11656 2026-03-06T17:50
12561 2026-03-06T17:51

[RambokDev]

Hi @reniko,

Thanks for all of that. At this time, it was a choice on our side to fix the chunk size. However, as you experienced, this can cause issues for large uploads and may reach the proxy rate limit. In a future version, we will allow users to configure a custom chunk size.

For now, could you allow these requests on your proxy as trusted ones without a rate limit? We will keep you updated once this is done.

Thanks for the feedback; it is very important for us.

[reniko]

Hi @RambokDev ,

Thanks for the feedback. I will find a way with the rate limiter for now.

Maybe in addition to configure the chunk size, could it be an option to change the connection URL used by the agent to connect to portabase? When I run all on the same machine, perhaps it could be from a performance perspective an idea to skip the proxy and directly connect to the portabase endpoint?

[mefistos]

I am in the same boat, I just setup Portabase and it seems like the TUS chunk size is 4kb, which means DB that is 100MB+ is going to take possibly hours to backup. An option to set custom chunk size would be great to speed up the backup, which for me is local both agent and dashboard are on the same host, so its kinda absurd to have 100MB DB backup take this long. I haven't done restore yet but I hope the restore is not the same and restoring 100MB backup wont take this long.

[RambokDev]

Hi @mefistos,
We will review this and get back to you shortly with a solution

[LeSnowTiger]

Custom chunk size would be great; these 4 KB chunks are causing such high load on my Docker host that the CPU is completely bogged down (Synology NAS).

@reniko I also had a problem with my reverse proxy. But I found out that you can decode the agents Edge key. (Base64 Decode). Change the dashboard URL in the string, and encode it to Base64 again. Start the agent with the new key and it will connect to the custom URL.

[RambokDev]

Portabase/agent#54

[RambokDev]

Hi,

The chunk size is now set by default to 1 MB on the agent side. You can increase it, but it is recommended not to exceed 5 MB. This should improve performance by reducing the number of PATCH requests compared to the previous implementation.

Feel free to test it.

The chunk size can be configured via the agent’s .env file using CHUNK_SIZE_MB (default: 1).

[RambokDev]

Feature will be available in agent:1.10.0 once the build is finished.

Hi,

The chunk size is now set by default to 1 MB on the agent side. You can increase it, but it is recommended not to exceed 5 MB. This should improve performance by reducing the number of PATCH requests compared to the previous implementation.

Feel free to test it.

The chunk size can be configured via the agent’s .env file using CHUNK_SIZE_MB (default: 1).