feat(docker): add upload/tempfile size limit env vars to standalone e…

[ckbaker10]

Problem it solves

before changing to euro-office I encountered this issue in OpenOffice doc server, so I audited euro office for the same issue since the fix is a requirement for our environment

Approach taken

Extended build/scripts/standalone/entrypoint.sh with two new env-var-driven defaults:

• MAX_FILE_SIZE (default 104857600, i.e. 100MB) → sets services.CoAuthoring.server.limits_tempfile_upload in the generated config, and maxFileSize in the example app's local.json (both via tonumber? // so non-numeric values pass through as strings rather than erroring).
• NGINX_CLIENT_MAX_BODY_SIZE (default 100m) → patches the client_max_body_size directive in ${NGINX_DS_DIR}/includes/ds-common.conf via sed, gated on that file existing.

Scope note: deliberately does not touch FileConverter.converter.maxDownloadBytes or .inputLimits[].zip.uncompressed — PR #237 already introduces FILECONVERTER_MAX_DOWNLOAD_BYTES and FILECONVERTER_INPUT_LIMIT_UNCOMPRESSED for exactly those two settings. This PR was split out of an earlier branch that duplicated them under different env-var names/mechanism; keeping this PR scoped to the settings #237 doesn't cover avoids two competing controls for one config key.

Testing

merged locally
https://github.com/ckbaker10/DocumentServer/blob/test/upload-size-limits-plus-237/build/scripts/standalone/entrypoint.sh
tested with 100m xlsm

Related

Split out of the original feat-file-size branch per review; scoped to not conflict with #237.

Branch: feat/upload-size-limits

[chrip]

Thanks for splitting this out — both asks from #301 are visible here. The ensure_db_schema
half became #304 ✓, and the size-limit half is now scoped so it doesn't touch the two settings
#237 owns (maxDownloadBytes, inputLimits[].zip.uncompressed). I verified that: no key
overlap between the two PRs, so the "two competing controls for one setting" problem is gone.

I checked all three defaults against what the image actually ships, and they're exact no-ops,
which is the right call:

• limits_tempfile_upload 104857600 = server/Common/config/default.json:324
• example maxFileSize 104857600 = production-linux.json:5 (and ds-example.conf does set
  NODE_ENV=production-linux, so that's the effective value, not default.json's 1GB)
• client_max_body_size 100m = ds-common.conf.m4:2

Also verified: maxFileSize is correctly nested under server (app.js:40 does
config.get('server')); ${EO_CONF}/nginx/includes/ds-common.conf is the real installed path
(package.install.m4:5 + Makefile:149) and not the /etc/nginx/includes symlink, so sed -i
won't clobber a link; and NGINX_CLIENT_MAX_BODY_SIZE is an existing name in this repo
(build/scripts/orchestrated/proxy-docker-entrypoint.sh:23 does the same sed), not a new one.

Three things, none of them a bug:

1. The override convention diverges from #237, which was the other half of my #301 ask.
#237 gates each var (if [ -n "${VAR:-}" ]), so an unset var leaves default.json authoritative
and no default is restated in the entrypoint. #305 writes unconditionally and hardcodes the
default, so 104857600 and 100m now live in a second place and can drift from
default.json:324 / ds-common.conf.m4:2. Concrete cost: because local.json is regenerated
every boot, an operator who hand-raised limits_tempfile_upload in local.json gets it silently
reset to 100MB on the next restart unless they also set MAX_FILE_SIZE. Gating it the way #237
does removes both the duplication and that surprise. Since these two PRs land together, I'd
rather they read the same way — and I'm happy to change #237 instead if you prefer this style.

2. It will conflict with #237 textually, even though no setting overlaps: both insert a
jq_set block around the Metrics section and both append --arg lines right after
--arg metricsPrefix. Both say MERGEABLE against main, but not against each other. Trivial to
resolve — just needs someone to do it deliberately rather than discover it. Your
test/upload-size-limits-plus-237 branch suggests you've already done it once; happy to take
whichever lands second.

3. NGINX_CLIENT_MAX_BODY_SIZE is unvalidated and can stop the container booting. A typo
(100mb, foo) is written straight into the directive, nginx then fails to load its config, and
service nginx start is a bare command under set -e. #237 guards its numeric var with a case

• WARN; mirroring that here for at least the nginx one would be consistent. Minor and related:
  the value is interpolated into the RHS of s/// unescaped, so a / or & would corrupt the
  line — theoretical for size values, but a case guard covers both.

Non-blocking notes: the commit subject is truncated mid-word ("standalone e…" with the body
starting "…ntrypoint") — worth fixing on merge so git log reads cleanly. And the linked test
evidence is test/upload-size-limits-plus-237, i.e. #305 + #237, so a 100MB xlsm may still
fail conversion with this PR alone; that's fine, just means the two want merging as a pair.

CI has never run here either — the Build and Push Docker Image run for 28acd734 is stuck at
action_required, same as #304. I'll get those released.

Commit is Conventional, DCO green, Assisted-by present, one file, tight scope.

Assisted-by: ClaudeCode:claude-opus-5

[ckbaker10]

Thank you Chirp for your quick merges, now I can switch back to official images in the future.