What Private, Offline Image Processing Should Actually Mean

Image tools often describe themselves as private because inference runs on a server they control. That is incomplete. A useful privacy model covers the whole trip: how the input is stored, who can request it, whether the processor can call outside services, what lands in logs, and how the result is returned.

#The path an uploaded image takes

1. Upload: the browser sends the selected image over HTTPS.
2. Private object storage: the raw file is written under an account- and job-specific key.
3. Queue: a database row records the work without putting the image bytes in the database.
4. Isolated processing: a worker downloads the input, runs the processor in a no-network container, and produces an output file.
5. Private delivery: the output returns to object storage and is downloaded through an authenticated application response with private, no-store browser caching.

#Why a no-network processing container matters

A processor needs access to its model files and the specific input and output directory. It does not need open internet access while reconstructing an image. Running the processing command in a container with networking disabled narrows what that code can reach if a dependency behaves unexpectedly.

This is narrower than saying the entire service is offline. The remote host still needs controlled network access to claim jobs, download the input from private storage, and upload the result. The important boundary is that the remote CPU image-processing container itself cannot send the file to another API or fetch code while the job runs.

#Queue isolation limits cross-account access

Each job belongs to one signed-in account. A worker claims a single queued row under a database lock, processes the object keys attached to that row, and records the output against the same job. Downloads are authorized through the application rather than making the storage bucket public.

A robust queue also expects failure. If a worker disappears while holding a job, a lease timeout can return that row to the queue instead of leaving it stuck forever. Health checks can retire unresponsive workers without granting them broader access to other production systems.

#Questions worth asking any image processor

#Current storage retention is not automatic

Raw uploads and processed outputs are currently stored in the private R2 bucket without an automatic deletion schedule in the application. Downloads require the matching signed-in account, but authentication is not a substitute for deletion. Do not upload an image if your requirements demand automatic erasure after a fixed period.

#What you should still avoid uploading

Infrastructure controls reduce exposure; they do not make every image appropriate for a third-party service. Avoid uploading identity documents, private medical material, unreleased client work, intimate images, or files covered by a contract that forbids external processing unless you have independently reviewed the service for that use.