Screenery / Compare / Ferndesk
Ferndesk alternative for help center screenshots
Ferndesk is a hosted help center with an AI agent, Fern, that checks articles against your code and your live product. On its Pro plan, Fern logs in to your app and re-takes screenshots when the UI changes. Screenery is not a help center. It publishes the screenshots your own Playwright tests take in CI, at URLs you can embed in any docs tool.
The short answer
- Pick Ferndesk if you need a help center anyway and want an agent to keep its articles and screenshots current. It is best for a small team with no screenshot tests.
- Pick Screenery if your docs already live somewhere else, such as a docs site, a README or a marketing page. It also fits if you want screenshots taken by tests you review, with a visual regression gate before Screenery publishes them.
Side by side
Ferndesk details checked October 2026 on its own site. See Sources.
| Ferndesk | Screenery | |
|---|---|---|
| What it is | A hosted help center with AI answers, an in-app widget and an agent that drafts article fixes. | A registry for screenshots. It does not host articles. |
| How a shot is taken | You tell Fern what you need. It logs in to your app, finds the element and captures it. | Your test calls page.screenshot(), or keeps a toHaveScreenshot() golden, in your CI. |
| Signing in | Fern logs in to your app. The pages we checked do not say which credentials it uses. | Your tests sign in the way they already do. Test credentials stay in your CI. Screenery only receives image files. |
| When it re-captures | When the UI changes. Scheduled audits also look for stale articles. | On every CI run that pushes. A push on the default branch moves @latest. |
| Annotations | Yes. Fern adds callouts to the right elements. | No. Screenery serves the file your test wrote. Crop or hide elements in the test, with Playwright's clip and mask options. |
| Where images are used | In articles in your Ferndesk help center. Its pages do not say whether the images can be embedded elsewhere. | Anywhere an image URL works: a README, a docs site, a help center, a marketing page. |
| Visual regression gate | Not offered, as far as its pages show. | Optional. The push compares each image with a committed baseline, and a change fails the job before Screenery publishes anything. |
| Price | Pro $149 a month or $1,490 a year. $75 a month in the first year for companies under $1M ARR with fewer than 10 people. Enterprise from $399 a month. 7-day free trial. | Not published yet. |
What Ferndesk does well
- A whole help center. Hosting, a custom domain, AI answers, an in-app widget, translations and analytics, in one product.
- Articles and screenshots together. Fern checks articles against your GitHub code and your live product, drafts fixes, and re-takes screenshots. Nobody has to notice that a page went stale.
- No code. You describe the screenshot you want. There is no test to write.
- Annotated images. Fern adds callouts for you.
- Cheap for small teams. The early-stage rate brings Pro to $75 a month for the first year.
- Easy to move in. It imports from Intercom, Zendesk, Help Scout, GitBook and others.
Where Screenery is different
It works with the docs you already have
Ferndesk keeps screenshots current inside Ferndesk. Screenery gives each screenshot a stable URL that follows your default branch, so it works in whatever you already publish with. Paste it once. The next push on the default branch changes the image behind it.

See Screenshot URLs.
Tests, not an agent
A Playwright test takes the same steps every run, and waits for the screen with an assertion you wrote. The test lives in your repository, so a change to the screen and a change to its screenshot go through the same review.
test('billing settings', async ({ page }) => {
await page.goto('/settings/billing');
await expect(page.getByRole('heading', { name: 'Billing' })).toBeVisible();
await page.screenshot({ path: 'test-results/settings/billing.png' });
});
permissions:
id-token: write
pull-requests: write
steps:
- uses: screenery/push@v1
with:
project: acme/dashboard
path: test-results
No vendor login to your app
Screenery never opens your product. Your CI runs the tests, often against a build it started itself with seeded data, and sends Screenery the image files. On GitHub Actions the push signs in with GitHub's OIDC token, so there is no Screenery secret in CI either. See Credentials.
A gate and pull-request previews
Point the push at a committed baseline, and a visual regression fails the job before anything reaches @latest. A pull request pushes to its own @pr-N channel, and the job can comment with what changed. See Visual testing and Pull-request comments.
Which to pick
Ferndesk is the better pick when:
- you need a help center, not just fresh images for one you already have;
- you want an agent to keep the article text current as well as the screenshots;
- nobody on the team writes Playwright tests;
- you are a small company that qualifies for the early-stage rate.
Screenery is the better pick when:
- your docs live in a docs site, a README or a help center you are keeping;
- the same screenshot appears in several places, such as the docs and the marketing site;
- you already run Playwright in CI, or are willing to write a few screenshot tests;
- you would rather not give a vendor a login to your app;
- you want a visual regression gate that runs before Screenery publishes an image.
Screenery does not host articles, write text, or annotate images. If you want all of that in one product, Ferndesk is built for it.
Sources
We checked the Ferndesk facts on this page in October 2026, on these pages:
- ferndesk.com, the home page.
- ferndesk.com/pricing: plans, the early-stage rate, and "Screenshots re-taken when the UI changes" on Pro.
- Automated screenshots for docs: how Fern captures and annotates.
- The Ferndesk changelog says Fern logs in to your app, and that the feature launched as an experimental beta.
The docs describe how Screenery behaves. Start with Getting started or Playwright goldens.