No. All four have defaults baked into cmd/server/main.go. Safe to skip for the launch.
ASYNC_WORKERS=2- goroutines per pod pulling jobs off the queueASYNC_STANDARD_CAP=4- max in-flight PDFs a non-VIP carrier can have at onceASYNC_VIP_CAP=12- same, but for VIP carriersBATCH_WORKERS=8- workers for the sync batch endpoint (legacy, not used by the UI)
ASYNC_WORKERS is the real throughput knob. 2 workers per pod = 2 PDFs at a time per pod. Need more throughput? Either raise this or add more pods via KEDA.
ASYNC_STANDARD_CAP is about fairness. Stops one carrier from clogging the queue for everyone else. If a carrier uploads 20 files, the first 4 start processing, the rest wait in line. Default of 4 is tight - might bump to 8 once we see real usage.
ASYNC_VIP_CAP - same idea, higher ceiling for VIP carriers. Default of 12 is fine.
BATCH_WORKERS - doesn't matter for end users. The gateway upload flow uses the async endpoint, not this one. Ignore it.
Staging currently has STANDARD_CAP=12 and VIP_CAP=8. That's backwards - VIP should be higher than standard. Either intentional for testing or a copy-paste bug from when the caps were first added. Worth confirming before copying to production.
Leave all four at defaults for v1.0 launch. Tune later when we have actual load to measure against.