Always Up-to-Date Docs with Public Properties

Here’s a problem I bet you’ve faced: your docs (or some marketing page) look awesome when you ship, then three months later someone opens a GitHub issue pointing out that half the screenshots show the old UI. You know the drill; your team shipped a redesign, updated the flow, or just tweaked a button color, but nobody remembered to capture fresh screenshots for the docs.

I built public properties at Vizzly to solve this exact headache, and honestly, it’s become one of those features that just works so well you forget it’s even there.

The old way: screenshot debt

Before public properties, keeping documentation current was a manual slog. Someone (usually me) would have to remember to:

1. Run through the app and capture new screenshots
2. Download them locally
3. Upload them to some CDN or image service
4. Update all the markdown files with new URLs
5. Cross fingers that I didn’t miss any

And of course, three weeks later I’d ship another update and the cycle would start all over again. It felt like I was constantly playing catch-up with my own docs.

Enter public properties: screenshots that update themselves

Here’s how public properties changed my workflow. Instead of manually managing screenshot files, I just tag my visual test screenshots with properties that identify what they show:

await vizzlyScreenshot('project-dashboard', screenshot, {
  properties: {
    feature: 'dashboard',
    docs: 'getting-started'
  }
});

That docs: 'getting-started' property becomes the magic key. In your project settings, you configure which properties make screenshots publicly accessible. Once configured, any screenshot tagged with docs: 'getting-started' automatically becomes available at a public URL that never changes—even when the screenshot content updates.

Property-based filtering keeps things secure

You might be thinking “wait, doesn’t this expose all my test screenshots to the world?” Nope. Public properties work through configurable filtering. In your project settings, you set up rules that specify which property keys and values should be publicly accessible:

(This is a public property screenshot from the Vizzly test suite, btw)

• docs: 'getting-started' → publicly accessible
• docs: 'api-reference' → publicly accessible
• feature: '*' → any screenshot with a ‘feature’ property is public

Only screenshots with properties matching your configured rules become public. Everything else stays locked down. Plus, the URLs use non-guessable UUIDs, so there’s no way for someone to stumble across screenshots they shouldn’t see.

The workflow that actually works

Now my process looks like this:

1. I update the UI - Normal feature work, no extra steps
2. Tests run in CI - Playwright captures screenshots like always, but with the right properties
3. Build becomes baseline - When a build is approved and marked as baseline, matching screenshots automatically get published to public URLs
4. Docs stay current - Zero manual intervention needed

Here’s the sweet part: my docs now update themselves when builds become the new baseline. The screenshot URLs in my markdown files never change, but the images they point to refresh automatically whenever new baseline builds are created.

How I used it for docs.vizzly.dev

When I built the documentation site, I wanted to include screenshots that would stay current as I shipped updates. Here’s exactly how I set it up:

1. Tagged my test screenshots with descriptive properties:

// In my Playwright tests
await vizzlyScreenshot('project-dashboard', screenshot, {
  properties: {
    docs: 'getting-started',
    feature: 'dashboard'
  }
});

await vizzlyScreenshot('build-detail-overview', screenshot, {
  properties: {
    docs: 'core-concepts',
    feature: 'builds'
  }
});

await vizzlyScreenshot('api-token-setup', screenshot, {
  properties: {
    docs: 'quick-start',
    feature: 'authentication'
  }
});

2. Configured public properties in my project settings:

• docs: 'getting-started' → publicly accessible
• docs: 'core-concepts' → publicly accessible
• docs: 'quick-start' → publicly accessible

3. Embedded them directly in my documentation:

![Project Dashboard](https://images.vizzly.dev/public/b9a80775-57a6-426b-87df-24e722705a32.png)
![Build Detail Overview](https://images.vizzly.dev/public/dfe138ba-38e0-42ac-8c39-70724c1c9ed6.png)
![API Token Setup](https://images.vizzly.dev/public/add61cd3-055d-4821-b69a-6dabf8b4511d.png)

Now when I update the dashboard UI or change the token creation flow, those screenshots in my docs automatically update when the next baseline build is created. Zero manual work, and my docs always show the current state of the app.

Why this beats manual screenshot management

Old way	Public properties
Remember to capture new screenshots after every UI change	Screenshots captured automatically as part of existing test suite
Upload and host images separately	Images hosted and served by Vizzly automatically
Update markdown files with new URLs every time	URLs never change, content updates automatically
Screenshots lag behind actual product by weeks	Docs stay current with every approved baseline

Try it on your next docs update

If you’re tired of playing screenshot catch-up, here’s how to get started:

1. Tag your visual test screenshots with descriptive properties like docs: 'homepage' or tutorial: 'onboarding'
2. Configure public access in your project settings for those specific properties
3. Embed the public URLs in your documentation
4. Watch your docs stay current automatically as your tests run

The non-guessable URLs and property-based filtering mean you can selectively share exactly what you want without accidentally exposing internal screenshots. And since it’s built into your existing visual testing workflow, there’s no new process to remember or maintain.

If you want to try it out, spin up a free workspace at app.vizzly.dev and tag some screenshots with public properties. Your future self—and your documentation readers—will thank you for the time saved.