Temporary files consume a real budget
A Cloud Run in-memory volume provides a directory for files shared by containers within one instance. It does not provide durable storage or a shared directory across service instances. When the instance ends, its temporary data disappears. Use a persistent service for output that must survive instance replacement.
The important capacity rule is that a size limit does not allocate additional memory. Data written into the volume consumes the writing container's memory budget. Application heap, libraries, request buffers, and temporary files therefore compete for the same allocation. With multiple containers, a generous shared-volume limit can still permit one writer to exceed its own smaller memory limit.
Prepare a staging revision, representative payloads, container memory metrics, and a known cleanup policy. Identify every directory the application writes, including libraries that use default temporary locations. Record concurrency and maximum upload size. Check whether the service already uses the built-in writable filesystem rather than an explicitly limited memory volume.
Establish a bounded scratch design
- Inspect
gcloud run services describe converter --project=PROJECT_ID --region=REGION --format=export. Map each volume mount to its writing and reading containers. Record each container's memory limit and the explicit volume size limit, if any. Do not assume a shared mount combines all container memory into one unrestricted pool. - Estimate peak scratch usage from representative requests. Include compressed input, expanded working files, intermediate output, and overlapping requests. Measure actual peaks in staging because file expansion and library buffers are often larger than the original upload.
- Configure a reviewed volume limit below the space that would exhaust the writer after its normal process memory is accounted for. Add application handling for failed writes, cleanup on success and failure, and request admission that rejects work exceeding the supported size. A predictable error response is preferable to losing unrelated requests on a terminated instance.
- Persist completed output before returning a durable-success response. Use unique per-request working paths and remove only that request's files. A sidecar reading the same directory must tolerate incomplete files or use an explicit ready marker after the writer finishes.
Illustrative scenario
A fictional preview service accepts several documents concurrently. Each document expands into images before a sidecar assembles a preview. The shared volume has ample nominal space, but the conversion container reaches its own memory limit first. The fix combines a smaller scratch limit, fewer overlapping conversions, and explicit cleanup. Increasing the sidecar's memory would not repair the writer's accounting problem.
| Symptom | Evidence to collect | Correction |
|---|---|---|
| Instance terminates during conversion | Writer memory and scratch growth | Reduce overlap or increase its justified budget |
| Writes fail at a repeatable size | Configured volume limit | Handle the failure and reject oversized work |
| One request reads another's files | Working-path construction | Isolate paths by request identifier |
| Output vanishes after a restart | Persistence acknowledgment | Store output durably before success |
Verify failure behavior
Test an ordinary payload, the largest supported payload, concurrent requests, and a deliberately oversized input. Confirm that rejected work returns a controlled response, files are removed, and unrelated requests survive. Restart a staging instance and verify that durable outputs remain available while temporary paths are treated as disposable. Inspect logs for accidental document contents or filenames containing sensitive data.
Operating procedure
Monitor container memory, conversion failures, rejected payload sizes, and cleanup errors. Review the capacity model when concurrency, supported formats, or conversion libraries change. Keep a documented maximum accepted input and test expansion behavior for new formats. Treat scratch usage as application capacity, with an owner and an acceptance test, rather than an invisible filesystem detail.
Explore Clouvenix managed infrastructure for implementation and operational handover.