A Lightroom Publish Service That Syncs an Online Client Gallery

Install the plugin and Lightroom Classic gains two separate things. One is a ClientGallery destination in the Export dialog. The other is a ClientGallery entry in the Publish Services panel, at the bottom left of the Library module, under Folders and Collections.

Inside that entry you create published collections. Each published collection is one client gallery. Drag photos into it and they do not upload yet. They sit in a group Lightroom labels New Photos to Publish. Click Publish and they go up.

From that moment the collection is a two-state thing. Lightroom holds a record of what it sent, keeps watching the photos in the collection, and continuously sorts them into three buckets: already published, new and not yet sent, and published but changed since. That third bucket is the one that matters. Lightroom calls it Modified Photos to Re-Publish.

Clicking Publish pushes exactly the New and the Modified. Not the whole collection. If you re-edited four frames out of 340, four frames render and four frames upload. This is the entire reason to use a Publish Service rather than exporting: Lightroom does the bookkeeping of what changed, so you never have to remember it, and you never re-render a gallery to fix one photo.

The practical consequence is smaller than it sounds and more useful than it sounds. The gallery has an identity. It is a named object in your left panel, it exists at one address, and that address survives every subsequent publish.

So the link you emailed the client on Monday is still the correct link on Friday, after you have re-graded eleven photos, added the ones you found on the second card, and pulled two frames the client did not like. You do not send a second link. You do not write "ignore the old gallery, here is the new one." The client refreshes the page they already have open and the gallery is current.

That also means the gallery is where your catalog says it is. Open Lightroom, look at the left panel, and the published collections are your live client galleries. There is no second inventory to reconcile, no folder of exported JPEGs on a drive that may or may not match what is online.

This is the part worth reading twice, because two of the rows below are destructive and Lightroom will not ask you to confirm in the way you might expect.

Read the last row plainly. Deleting the published collection is not a local tidy-up. It deletes the gallery your client is looking at. If you want the collection out of your left panel but the gallery to stay online, that is not what the Publish Service does. It is a sync, and a sync propagates removals.

Removing a single photo behaves the same way, and it is genuinely the feature you want. A client says the third frame of the ceremony is unusable. You pull it out of the collection and it is gone from the gallery. You did not have to open a browser.

The rule that surprises people is the metadata one, so here is the reasoning. Develop edits change the pixels. A crop, an exposure shift, a different profile, a spot removal: the JPEG your client sees is now wrong, so the photo is marked Modified and the next Publish replaces it. That is correct behaviour.

Keywords, captions, titles, star ratings and colour labels do not change the pixels. The image in the gallery is still exactly the image you intended to show. If metadata triggered a re-push, a routine keywording session on a delivered wedding would mark every one of 600 photos as Modified, and your next Publish would re-render and re-upload the entire gallery to deliver a change the client cannot see. That is an hour of machine time and bandwidth for nothing.

So the plugin declares that no metadata field triggers a re-publish. If you deliberately want a photo re-sent without touching its develop settings, right-click it in the published collection and choose Mark to Re-Publish. The manual override is there; it is just not the default, because for almost every real session the default is right.

One footnote on what actually gets rendered. Render settings are fixed rather than offered: sRGB JPEG, no output sharpening, and location metadata stripped so a home address does not travel inside a delivered file. There is no quality slider to get wrong, and no way to accidentally publish a gallery in a colour space that will look grey in a browser.

Four constraints are worth knowing before you build your workflow around this, not after.

The flat structure is the one people notice first. If you organise your catalog into deep nested sets by year and client, the Publish Service will not mirror that shape. Folders inside a gallery exist on the web side as sub-galleries, but the Publish Service itself is one level deep.

On the free account limit: a free account holds one gallery, and 5 GB. The paid plan is 10 $/month or 100 $/year, with unlimited galleries, photos and clients under fair use. Fair use in figures is 1,000 photos per gallery and 250 GB of proofs per paid account, which is hundreds of thousands of photos, because uploaded photos are browser-compressed proof JPEGs of about 0.6 MB each, hosted for as long as the account exists. Full-resolution delivery is separate: you upload a full-resolution ZIP per gallery, it stays live for 3 days per handoff, and you can re-upload it any time, with 100 GB of standing ZIPs per account.

Six steps, and after the first shoot it takes about a minute of your attention per round.

1. Paste the studio key once. In the Publishing Manager for the ClientGallery service. A Check button validates the key before anything uploads, so a typo surfaces immediately rather than 300 photos in.
2. Create the published collection and name it for the client. The name is the gallery name. "Tremblay, sélection" beats "Gallery 3." Pick a light or dark theme for the client and set a password if the shoot needs one.
3. Drag in the cull and click Publish. Lightroom renders and uploads. When it finishes, the gallery is live.
4. Send the link once. Right-click the collection and choose View gallery on ClientGallery to get it. This is the only link you will ever send for this job.
5. Re-edit as notes come in. Every photo you touch in Develop drops into Modified Photos to Re-Publish on its own. You do not track anything.
6. Click Publish again. Only the changed and the new go up. The link is unchanged. Repeat for as many rounds as the job needs.

The habit that makes this work is the one in step 4: never re-send a link. If a client has one address for their photos and it is always current, the entire class of "which gallery is the real one" email disappears. The full multi-round version of this loop is in updating a client gallery after re-editing in Lightroom.

Pixieset ships a Lightroom Classic plugin that is also a Publish Service, and on one point it does something ours does not. Its Sync Gallery Structure option pulls down from the server, bringing the Collection and Set names from an existing Pixieset account into Lightroom. If you have built galleries in the browser, that structure can appear in your catalog. Ours has no equivalent; our sync runs from the catalog outward. Give Pixieset that one.

What that sync does not do, Pixieset states in bold on the same page: "Your photos from Pixieset will not be imported into Lightroom." The documentation adds that Sync Now handles gallery structure only, and that photos uploaded or removed are not synced. The return trip is names, not content.

Client picks come back by a different route again. Pixieset's documented mechanism is the Lightroom Copy List: a list of filenames you paste into the Library filter set to Any Searchable Field and Contains. It works, it is free, and for a photographer with tidy filenames and no virtual copies it is a serviceable two-minute job. Pixieset also documents its two failure modes itself: a search for IMG_1 can pull up IMG_101, and virtual copies are silently missed. The plugin-to-plugin comparison is laid out in Pixieset vs clientgallery.io on the Lightroom plugin.

Publishing is only half of a two-way plugin. From the Library menu, Plug-in Extras, Import ClientGallery Picks pulls the client's choices back into the catalog: likes become 3 stars, loves become 5 stars and Picks flags, the client's colour labels become Lightroom colour labels, and everything found is gathered into a collection named after the gallery.

The full mechanism, including what happens when filenames do not match, is in getting client picks back into Lightroom.

Two honest limits, and the second one applies to more photographers than the first.

It is a Lightroom Classic feature. Publish Services do not exist in the cloud version of Lightroom, and they do not exist in Capture One or Photo Mechanic. There is no plugin we could write that would change that; the hook is in Classic and nowhere else. If Classic is not your catalog, none of this page applies to you, and you should be reading about uploading a folder of exported JPEGs instead.

Low volume does not repay the setup. If you deliver one or two galleries a year, a Publish Service is overhead. You maintain a service configuration, you keep published collections in your panel forever, and you carry the risk of the two destructive rows in the table above, all to automate a task you perform twice. Use the Export dialog. Select the photos, choose ClientGallery, name the gallery, done. It is genuinely the simpler tool at that volume, and the Export walkthrough covers it end to end. The Publish Service starts paying for itself somewhere around the point where you re-edit galleries after sending them, which for most working photographers is every job.

One more, on scope. clientgallery.io hosts JPEG proofs. It does not warehouse RAW files or master video, and that is what keeps the price flat. A studio that needs RAW or video living inside the delivery gallery needs a different platform, not this plugin.

• clientgallery.io Lightroom Classic plugin, version 3.2.0, source read 4 September 2026 (Publish Service behaviour, incremental publish, metadata does not trigger republish, flat collections with no nested sets, removal and rename and delete propagation, the free-account and 1,000-photo messages, forced sRGB JPEG with no output sharpening and location metadata removed, studio key Check button, Import ClientGallery Picks): https://clientgallery.io/lightroom
• clientgallery.io plan and fair use (10 $/month or 100 $/year, free account 1 gallery and 5 GB, 1,000 photos per gallery, 250 GB of proofs per paid account, full-resolution ZIP live 3 days per handoff with 100 GB standing), checked 4 September 2026: https://clientgallery.io/
• Pixieset, How do I install the Lightroom Plugin (Publish Service, Sync Gallery Structure pulls Collection and Set names from Pixieset to Lightroom, "Your photos from Pixieset will not be imported into Lightroom", Sync Now syncs structure only), fetched 4 September 2026, https://help.pixieset.com/hc/en-us/articles/115003009832-How-do-I-install-the-Lightroom-Plugin
• Pixieset, How do I upload from Lightroom (Lightroom Classic only), fetched 4 September 2026, https://help.pixieset.com/hc/en-us/articles/115003504512-How-do-I-upload-from-Lightroom
• Pixieset, Viewing Client Favorites in Lightroom (the Lightroom Copy List, the Any Searchable Field and Contains steps, the IMG_1 and IMG_101 over-selection warning, the virtual copies warning), fetched 4 September 2026, https://help.pixieset.com/hc/en-us/articles/115003505192-Viewing-Client-Favorites-in-Lightroom