Argos CI vs Loki for Storybook Screenshot Comparisons

Short answer: Choose Argos CI if you want CI to capture Storybook stories and upload screenshots to a hosted service for review. Choose Loki if you want to generate reference images, keep them with the project, and own the comparison, diff, approval, and storage workflow. Both compare new story screenshots against accepted baselines. The documentation reviewed does not establish that either is more accurate, faster, or less flaky.

This guide is for frontend engineers and design-system teams deciding how to catch visual changes in pull requests. The key choice is where baselines live and how reviewers approve changes; after that, check version compatibility, target platforms, screenshot volume, CI behavior, and operating cost.

How the workflows differ

Decision	Argos CI	Loki
Capture and comparison	Its Storybook integration captures stories in a real browser during CI and uploads screenshots to Argos for review.	Creates reference images, compares new captures, generates diffs, and provides an approval step.
Baseline ownership	A hosted service workflow. Check Argos documentation for current baseline behavior and account controls.	Reference images are kept in the project repository; Git LFS is an option.
Review and upkeep	Review the uploaded screenshots through the service workflow; the account and service are part of the process.	Your team owns reference updates, image storage, diff review, approval, and the CI wiring.
Platform targets	The reviewed Storybook integration documentation establishes browser-based capture, but not a comparable multi-platform matrix.	The README lists Chrome in Docker, Chrome in AWS Lambda, local Chrome, iOS simulator, and Android emulator. Confirm the precise target and current compatibility for your project.
Compatibility	The current addon documentation lists Storybook 8 through 11. It describes Vitest integration for Storybook 9 or later with Vitest 4 or 5, and Test Runner integration for Storybook 8 or later. Verify versions before setup.	The project setup and README document its workflow and targets; the reviewed pages do not establish a complete current compatibility matrix.
Cost model	Published service quotas and prices apply; usage depends on screenshot volume and plan terms.	The tool is open source, but CI runtime, repository storage, and engineering maintenance still have costs. The reviewed sources do not quantify them.

These are workflow differences, not a controlled head-to-head test. Storybook describes visual tests as snapshots compared with a known-good baseline. In either workflow, a visual difference flags a change for review; it does not decide whether that change is a bug or an intended design update.

Argos CI: hosted capture and review

Argos documents a Storybook integration that captures stories automatically in a real browser during CI and uploads the screenshots for visual review. Its addon page recommends the Vitest addon for newer Storybook configurations and also documents a Storybook Test Runner route.

Compatibility checks before adding it

• Match your Storybook major version to the current Argos addon instructions.
• For the Vitest integration, check both the Storybook and Vitest versions; the reviewed page lists Storybook 9 or later and Vitest 4 or 5.
• For the Test Runner integration, the reviewed page lists Storybook 8 or later.
• Confirm the project’s Node, browser, package manager, and CI environment against the current installation instructions. Do not assume a listed Storybook version guarantees compatibility with every surrounding dependency.

When this workflow fits

Argos is a plausible fit if you want CI to produce screenshots for a hosted review workflow, and its documented integration matches your stack. It moves screenshot review into a service workflow, but also makes service availability, account settings, and plan limits part of the operating model. Confirm how your organization wants to handle access, retention, and baseline controls in the current documentation.

Loki: repository-managed references

Loki’s documented workflow has the team create reference images, keep them with the project, run comparisons, inspect generated diffs, and approve intended changes. Its getting-started instructions use loki init to add detected defaults. They then use loki update to create references, loki test to compare captures, and loki approve to accept intended changes. The guide recommends checking reference images into Git and identifies Git LFS as an option.

CI workflow

Loki’s CI guide documents building Storybook and running Loki against the static output. Its example uses --requireReference so a missing baseline fails the run. That makes baseline creation and updates explicit repository workflow responsibilities.

1. Initialize Loki using the project’s current getting-started instructions and review the generated configuration.
2. Make Storybook available in the form expected by your chosen target, including building static output for the documented CI approach.
3. Generate initial references with loki update, inspect the images, and commit accepted references. Consider Git LFS if binary image files make the repository cumbersome.
4. Run loki test --requireReference in CI so missing references are visible failures rather than silently created baselines.
5. For an intentional visual change, inspect the diff, run the documented approval step, and commit the reviewed reference update.

The project README lists Chrome in Docker, Chrome in AWS Lambda, local Chrome, iOS simulator, and Android emulator targets. Treat that as the project’s documented target list, not a promise that every target works with every current Storybook, operating system, and browser release. Validate your exact combination. The Loki getting-started page displays an update date of August 27, 2024; that date alone does not establish whether the project is maintained or abandoned, so check current releases and issues before adopting it.

When this workflow fits

Loki is a plausible fit if you want reference files in your repository and are ready to own their storage, updates, review, and CI integration. This can make baseline changes part of ordinary version control review. It also means the team must plan for binary file growth, concurrent updates, and keeping the capture environment reproducible.

How to choose for your project

1. Start with baseline ownership. Decide whether your team prefers a hosted screenshot review service or reference images controlled in the repository.
2. Check exact stack support. Verify Storybook, Node, browser, and runner versions against current project documentation. Argos publishes specific Storybook integration versions; Loki’s reviewed materials do not provide a complete compatibility matrix.
3. List required targets. If you need a mobile simulator or a specific browser environment, verify that target’s current setup directly. Loki documents simulator targets; the reviewed Argos integration page does not provide a comparable matrix.
4. Decide how baselines are approved. Write down who can approve changes, how missing baselines are handled, and whether updates must be committed with product changes.
5. Estimate volume and total operating cost. Count stories multiplied by viewports and CI runs. Include service charges where relevant, CI minutes, artifact or repository storage, and the engineering time needed to maintain the workflow.
6. Trial stability in your own CI. Use representative stories and repeat runs. Control fonts, animations, asynchronous content, time zones, and environment differences. The reviewed sources provide no controlled flakiness comparison, so a project-specific trial is the useful evidence.

Practical recommendation: Start with Argos when hosted review and its documented integration line up with your stack. Start with Loki when repository-owned baselines are a firm requirement and you can own their storage and CI lifecycle. This is workflow-based guidance, not a claim that one tool wins on image accuracy or reliability.

Cost, performance, and reliability considerations

Published Argos pricing

Argos’s pricing page, accessed October 3, 2026, lists Hobby at $0 for up to 5,000 screenshots and Pro starting at $100 per month with 35,000 screenshots included. The page also lists overage rates, including a Storybook-specific rate. These are vendor-listed terms that may change, not an independent total-cost calculation. Check the live Argos pricing page before budgeting or purchasing.

Estimate your volume as stories × viewports × relevant CI runs, then account for reruns and branches according to the service’s current counting rules. A screenshot quota alone does not tell you which option will cost less overall.

Performance and stability

The reviewed sources do not provide a controlled Argos-versus-Loki measurement of capture speed, comparison accuracy, or flakiness. Both approaches depend on browser rendering and the state of the story. A meaningful evaluation should use the same representative components, viewport sizes, fonts, browser versions, and CI environment, then observe repeated runs.

• Disable or finish animations and transitions before capture.
• Wait for the component’s meaningful ready state instead of relying on an arbitrary short delay.
• Use stable fonts and assets, and avoid content that changes between runs such as timestamps or randomized data.
• Keep viewport dimensions, device scale, browser, and operating system consistent between baseline creation and CI comparisons.
• Make network-dependent stories deterministic with controlled fixtures or stable test data where possible.
• Review diffs at the same scale and distinguish rendering noise from product changes before updating accepted baselines.

Reliability and ownership

Argos adds a service and account dependency to the review workflow; Loki puts more of the process in your repository and CI configuration. Neither fact alone proves a reliability advantage. For either tool, document how to recover from failed captures, who can approve references, and how to reproduce a mismatch locally.

Troubleshooting visual comparison runs

Symptom	Likely cause	What to check
Argos does not capture the expected stories	Addon, Storybook, or runner configuration does not match the project’s versions or setup.	Compare the installed Storybook and runner versions with the current Argos addon documentation. Confirm the intended integration is enabled in CI.
Argos screenshots are not available for review	The CI capture or upload path did not complete, or account/project configuration is missing.	Inspect the job output and current integration setup; verify the project and credentials/configuration expected by Argos.
Loki reports a missing reference	No accepted baseline exists for that story or capture configuration.	Review the story and target, generate a reference deliberately with the documented update workflow, inspect it, and commit it. Keep --requireReference in CI when missing baselines should fail.
Many unexpected pixel differences appear	Browser, fonts, viewport, assets, animation, or dynamic content differ from the baseline environment.	Compare runtime versions and capture settings, wait for stable rendering, freeze variable content, and reproduce under the baseline environment before approving changes.
Only some stories fail or render blank	A story may depend on unavailable data, a failed asset, or setup that differs in CI.	Run the story independently in the same browser/environment, inspect console and network errors, and make its data and readiness conditions deterministic.
Repository grows quickly with Loki references	Reference images are binary files accumulated in version history.	Review image dimensions and baseline scope; assess Git LFS as Loki’s guide suggests, and define a policy for obsolete references.
Mobile simulator target is unavailable in CI	The chosen runner may not have the required simulator or operating-system support.	Verify the exact target prerequisites and current platform support; test the intended runner before committing to that workflow.

ScreenshotNeo as an alternative to try first

Argos CI and Loki are designed for Storybook visual regression workflows with baselines, comparisons, and review. ScreenshotNeo is a website screenshot API and MCP server for developers. It can help when your requirement is to capture a URL or provide screenshot tools to an AI agent; it is not a replacement for an accepted-baseline comparison workflow.

One GET request returns a PNG, JPEG, WebP, or PDF. The API also supports full-page capture, element selection, viewport and device settings, custom CSS and JavaScript, waiting conditions, request blocking, and other capture controls. See the ScreenshotNeo API documentation for the available options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

For example, capture a public Storybook URL by replacing the target URL with your deployed story or preview URL. ScreenshotNeo accepts and removes known consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses report the page verdict and billing state in headers.

It also provides an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is available on every plan. For hosted website screenshots outside your baseline comparison flow, sign up for 1,000 free screenshots a month with no card.

FAQ

Do Argos CI and Loki both compare Storybook stories against baselines?

Yes. Both workflows capture story screenshots and compare them with accepted references, though ownership and review differ.

Does the documentation prove one is more accurate?

No. The reviewed sources do not include a controlled comparison of accuracy, speed, or flakiness.

Is Loki free to operate?

The project is open source, but your CI, storage, and maintenance still consume resources. The reviewed sources do not quantify those costs.

Does a 2024 Loki guide date mean it is abandoned?

No. A page’s displayed update date is not enough to establish project status. Check current releases and issue activity.

Can ScreenshotNeo approve visual changes against a Storybook baseline?

ScreenshotNeo’s described role is website screenshot capture and MCP access; the provided product facts do not describe a baseline comparison and approval workflow.

Primary sources

• Argos pricing and Argos Storybook integration.
• Loki project README, getting started, and CI guide.
• Storybook visual testing documentation.