Build a zero-retention image step into your publishing pipeline

Make image compression a release step, not a privacy assumption

A publishing pipeline can make images lighter without keeping another remote copy of unpublished product assets. The useful distinction is where each copy lives. PiPic says images sent for compression are deleted from its servers immediately after processing. That is a remote processing policy, not a guarantee that every copy in a release workflow disappears.

For a team preparing a product launch, the practical pattern is to run PiPic’s open-source CLI on approved image files, write results to a separate output directory, inspect them, and publish only the checked output. The CLI is published as @pipic/cli on npm. PiPic says it can replace files in place or write to a fresh directory, and that scripts and CI can run unattended after a one-time sign-in.

This approach suits teams that want a zero-retention publishing pipeline at the remote processor, while keeping control of originals and generated files in their own build environment. It does not make the workflow local-only: images are uploaded to PiPic for compression. Confirm that this transfer fits your organization’s handling rules before sending unpublished assets.

Set up the pipeline around a clean boundary

1. Select eligible inputs. Start with the image files intended for the release, not every image in the repository. PiPic supports JPG, PNG, WebP and AVIF, with files up to 8 MB each. Filtering to changed, publishable paths also avoids spending a monthly CLI allowance on untouched media. A changed-path workflow for monorepo assets is useful background when the publishing job covers a large repository.

2. Install the CLI and authenticate deliberately. Add the open-source @pipic/cli package to the project’s tooling, then follow its documentation for setup and invocation. PiPic says users sign in once so scripts and CI can run unattended. Keep the authentication material in your existing CI secret-management process; do not put it in source files or print it in job logs.

3. Write to a fresh output location. For a release build, a separate destination gives reviewers a clear comparison and preserves the source assets if compression fails or needs a second look. PiPic’s CLI also supports atomic in-place replacement, but that choice makes source preservation the pipeline’s responsibility. Avoid overwriting the only copy before the job has validated its results.

4. Check the result before publishing. Make the compression step fail the release when the CLI reports an error, and check that expected output files exist and can be opened. Review representative images at their intended display size. PiPic says it keeps dimensions unchanged and tunes compression for near-invisible loss, but that is not a substitute for checking a product screenshot, a subtle gradient or a small type treatment in your own context.

5. Publish only the checked output. Point the deployment step at the output directory after validation. Keep the original inputs outside the public artifact unless your release process needs them there. Also review build caches, uploaded job artifacts and retained logs: deleting an image from PiPic’s servers does not delete copies your own pipeline may have stored.

Understand what “zero retention” covers

PiPic says the CLI sends only the image requested for compression, sends no telemetry, and deletes the uploaded image immediately after compression. Those facts make the CLI a focused option for a cli image pipeline privacy requirement: minimize what is sent, then remove the remote processing copy promptly. They do not establish that an asset never left your network, nor do they control your CI provider’s workspace, cache or artifact retention.

That boundary matters for confidential launch material. If policy prohibits uploading an asset to an external processor at all, immediate deletion does not change that restriction. If policy allows processing with prompt remote deletion, document the approved file classes and ensure the script cannot sweep in unrelated assets. Treat this as a secure image payload cleanup measure at one point in the workflow, not a blanket security certification.

Keep quotas and fallbacks explicit

The CLI tier includes 100 free images per month, with a Pro plan for 5,000 images per month. These are monthly CLI limits, not the browser tool’s batch limit. Filter inputs before the compression step, monitor usage against the tier your team relies on, and decide what a quota or service failure should do. For a release pipeline, stopping publication is safer than silently shipping an unprocessed set when compressed output is a requirement.

For a static-site build, separating compression from the generator can make that boundary easier to inspect. The earlier guide to moving image compression out of a static-site build covers the trade-off of keeping image work outside the bundler path. The essential rule is the same: preserve inputs, validate outputs, and state plainly which systems retain a copy.

A dependable automated asset compression script is less about a single command than its boundaries. Choose the files, send only those files, write results where they can be checked, and clean up your own temporary artifacts according to your retention policy. PiPic handles deletion on its servers; the release team still owns the rest of the pipeline.