How to document self-hosted Stable Diffusion work for client delivery

Self-hosted Stable Diffusion is the opposite of a hosted tool in every way that matters for documentation. There is no vendor archive, no account history, and no retention policy: what exists is what your setup wrote to disk. The most widely used interface, the AUTOMATIC1111 Stable Diffusion web UI, does a lot of that writing by default. It saves the parameters used to generate an image with the image itself, in PNG chunks for PNG files and in EXIF for JPEG files, and an image can later be dragged into the PNG Info tab to restore those parameters straight back into the interface. When you save through the UI, the generation parameters are also appended to a CSV file next to the saved images.

That is a strong baseline, and it is also easy to break without noticing. The parameter embedding can be disabled in settings, so an inherited or shared installation may not be writing anything. The metadata lives in the file, so a format conversion or an upload pipeline can strip it on the way to the client. And the parameter block names your model without containing it: the checkpoint, LoRA, and VAE files are yours to archive, and if one is deleted or overwritten, the recorded name points at nothing. The web UI's documentation adds a caution worth internalizing: changing the resolution changes the image entirely, even when the seed and every other parameter are kept.

There is also a confidentiality edge to this tool that hosted services do not have. Because the prompt rides inside the file by default, a delivered original can carry internal working language, client names, or reference notes straight to whoever inspects it. Documenting self-hosted work is therefore a two-way discipline: keep the metadata and the model files for your record, and decide deliberately what the client-facing copy should contain.

What self-hosted Stable Diffusion stores on its side

• The AUTOMATIC1111 web UI saves the parameters used to generate an image with the image itself, in PNG chunks for PNG files and in EXIF for JPEG files, and this behavior can be disabled in the settings. Source
• An image made with the web UI can be dragged into the PNG Info tab to restore its generation parameters and copy them back into the interface. Source
• When a generated image is saved through the interface, the generation parameters are appended to a CSV file in the same directory as the saved images. Source
• The web UI documents that changing the resolution changes the image entirely, even when the seed and all other parameters are kept, so resolution is part of the record rather than a detail. Source

What gets lost without your own record

• Nothing here is vendor-kept. If the output folders, the CSV logs, or the model files are lost to a disk failure or a cleanup, no support ticket can bring them back.
• The parameter embedding can be disabled in settings, so on any machine you did not configure yourself the record may simply not be there, and the images give no warning.
• File metadata does not survive casual handling. Format conversions and upload pipelines strip PNG chunks and EXIF data, leaving a delivered copy with no trace of its parameters.
• The parameter block names the checkpoint and networks that were loaded, but the files themselves live on your disk, and a deleted or overwritten checkpoint turns the recorded name into a dead reference.
• The record is per-machine. Renders spread across two workstations or a rented GPU box produce separate logs that nothing merges, and none of them records briefs, clients, or approvals.

The documentation checklist for self-hosted Stable Diffusion

1. Confirm in the settings that saving parameters to images is enabled, and re-check after updates and on every machine that renders client work.
2. Archive the PNG originals as the record copies, and treat any JPEG or re-export as a presentation copy without a reliable record.
3. Archive the exact checkpoint, LoRA, and VAE files each final used, or at least their hashes and download sources, because the parameter block references them by name only.
4. Back up the CSV parameter log together with the output folders, since it is the one place the interface accumulates generation history.
5. Record the web UI version or commit you rendered with, because samplers and defaults shift between releases and affect reproducibility.
6. Before delivery, decide whether the client copy should keep its embedded prompt and parameters, and strip or keep the metadata deliberately rather than by accident.

Self-hosting puts you in the best possible evidence position if the habit holds: original files with embedded parameters, a CSV log, and the actual model weights are more than any hosted tool will ever hand you. It also means every gap is yours. A missing checkpoint, a disabled setting, or an unlogged machine cannot be blamed on a vendor, which is exactly the argument for checking the pipeline once and then letting the defaults work.

For EU-facing work, the transparency duties of Article 50 of the EU AI Act apply to self-hosted generation just as they do to hosted tools, and nothing in the stack discloses anything for you. A per-delivery record that ties the approved file to its parameters, its model files, and its sign-off date, and that can show none of it has changed since, is what turns a folder of renders into something you can stand behind.

Frequently asked questions