Large uploads work behind a proxy, and a failed upload says why

Put Anthias behind a reverse proxy or a tunnel and large videos used to fail to upload, even though everything else worked. Anthias puts no limit on how big an upload can be, but the proxy usually does: Cloudflare's Free and Pro plans, for example, cap a request at 100 MB, which a few minutes of video clears easily. From Anthias 2026.09.0, Add asset > Upload file sends a file larger than 16 MiB in 16 MiB pieces, one after another, and the device puts them back together. Each piece clears the proxy on its own. Smaller files upload in one request, as before.

A piece that fails on a dropped connection or a server error is sent again, up to 2 more times, so one hiccup doesn't throw away an upload you've been waiting on. A file Anthias won't accept, such as an unsupported type, is refused on the first piece rather than after the whole file has gone up. An upload you abandon halfway is cleaned up once it has sat for an hour without a new piece.

Changing the piece size

If your proxy's limit is lower than 16 MiB, ask for smaller pieces. Add upload_chunk_size_mb under [main] in ~/.anthias/anthias.conf, which survives upgrades, and restart Anthias. On balena, set the ANTHIAS_UPLOAD_CHUNK_SIZE_MB device variable in the dashboard instead. If both are set, anthias.conf wins.

The value is in MiB (1 MiB is 1,048,576 bytes), from 1 to 24. A value outside that range is moved to the nearest limit, a decimal is rounded down, so 8.5 becomes 8, and anything that isn't a number is ignored in favor of the default of 16. Each request carries a little more than the piece itself, so leave some room under your proxy's limit.

A failed upload says why

Before, almost every upload failure showed the same generic message, asking you to check the file and try again. Now the message points at the cause:

• A file the server or a proxy refuses as too large says it exceeds the upload size limit of the server or a proxy in front of it, so you know to look at the proxy rather than the file.
• If a proxy refuses even a single piece, the message tells you to lower the upload chunk size.
• A connection that drops mid-transfer says so, and suggests a smaller file too, because some browsers report a proxy's size refusal as a dropped connection.
• If the last piece went up and no reply came back, the message says the upload may have finished and to check the asset list before uploading again, since a second attempt would make a duplicate.
• A page that has gone stale asks you to reload it and try again.
• A server error points you to the device logs.

For developers

Uploads through the API, POST /api/v1/file_asset and POST /api/v2/file_asset, are written to disk as they arrive instead of being read into memory first. The content endpoints in API v1 and v2 (assets/<id>/content) stream their response too, where they used to hold several copies of the file in memory. In the project's testing on a Raspberry Pi 3 B+, fetching a 150 MB asset through the content endpoint ran the server out of memory, and the API stayed down for about 40 seconds while it restarted. After the change, the same request added about 12 MB to the server's memory.

The content endpoints return the same JSON as before, with the file as base64 in content. For file assets the response is now always application/json, so the browsable API page no longer renders them.