How to Run Happo Screenshot Tests on a Low-Cost CI Setup in India

To run Happo screenshot tests on a low-cost CI setup in India, first use the integration your project already has—such as Storybook, Cypress or Playwright—then estimate Happo snapshot use and GitHub Actions runner use separately. Start with Chrome and the CI triggers your team needs. Check Happo’s current integration instructions before choosing package commands, configuration or secret names, since these vary by integration and can change. There is no evidence here to support a universal claim that one CI provider or runner is cheapest in India.

This guide gives you a decision process for keeping visual checks useful while making the two cost drivers visible: Happo’s snapshot quota and the compute used to build and test your UI. It covers GitHub Actions because its repository visibility and runner rules are documented clearly; the same budgeting distinction applies when evaluating other providers.

1. Start with your existing test integration

Happo supports integrations including Storybook, Cypress and Playwright. Pick the path closest to how your team already renders components or pages. That avoids adding a second browser harness just to take comparison screenshots. Happo’s product information describes a CI flow that compares screenshots against a baseline; consult its product information and the current setup documentation for the supported integration and exact setup steps.

1. Identify what CI already builds. Is the tested UI a Storybook, an app served during Cypress tests, a Playwright test target, or something else?
2. Find the matching Happo integration guide. Follow its current instructions for package installation, configuration, commands, credentials, required permissions and baseline setup. These exact details are not established by the sources used for this article, so do not copy secret names or YAML from an unrelated integration.
3. Choose a small initial scope. Start with the component variants that matter most and Chrome if that meets your initial need. Add browsers or more variants when you have a reason and quota for them.
4. Decide which CI events need checks. A pull request check gives reviewers feedback before merge. Add other run triggers only when their feedback justifies the extra snapshots and runner time.

The Happo repository says the older happo.io package was merged into the happo package. Because package names and integration setup can change, check the Happo repository and current integration guide rather than assuming an old tutorial’s install command is still right.

2. Estimate Happo snapshot use before adding browsers

Happo defines a snapshot as one screenshot of a component variant in one browser. Its monthly estimate is:

monthly snapshots = component variants × browsers × Happo runs per month

For example, 40 component variants, one browser and 20 Happo runs per month would use an estimated 800 snapshots. With three browsers and the same variants and run count, that estimate becomes 2,400. This is a planning calculation based on Happo’s definition, not a measured result.

Planning input	What to count	Cost-control choice
Component variants	Each visual state or component variant included in a run	Begin with the states where visual regressions matter most; expand deliberately.
Browsers	Each browser used for each variant	Happo’s listed free plan is Chrome-only. Add browser coverage when cross-browser differences matter.
Runs per month	How often CI invokes Happo	Choose triggers based on review needs and the number of changes, not by reflexively running every possible event.

Happo’s pricing page lists a free plan with 5,000 snapshots per month in Chrome, with no time limit and no credit card. Paid plans add quota and browser options. Check Happo’s current pricing and plan details before publishing a budget or expanding browser coverage, because quotas and prices can change.

3. Budget the CI runner separately

Happo snapshots and CI compute are separate costs. A build may consume runner time even when Happo’s snapshot allowance is ample. Conversely, a fast build can still create substantial snapshot usage if it captures many variants, browsers or runs.

GitHub Actions: check visibility and included allowance

GitHub’s Actions billing rules depend on repository visibility and the account plan. Under GitHub’s stated rules, hosted-runner usage for public repositories and self-hosted runner use are free; hosted-runner use in private repositories draws on account allowances and may be billed after those allowances are used. See GitHub Actions billing and check the current allowance for the account that owns the repository.

Do not treat a self-hosted runner as cost-free infrastructure: GitHub’s runner usage charge and the machine’s cost are different things. With a self-hosted runner, your team provides and operates its own cloud or on-premises virtual machine. Add VM charges, maintenance and the effort of keeping the runner available to the budget. The reviewed sources do not establish India-specific VM prices or a cheapest provider.

When to consider ubuntu-slim

GitHub documents ubuntu-slim as a lower-cost option for lightweight jobs. It has a 15-minute job timeout and restrictions on work that needs elevated privileges; GitHub does not describe it as suitable for typical heavyweight CI/CD builds. A screenshot workflow still has to install dependencies, build or serve the UI, and run the relevant integration. Consider it only if your actual job fits its runtime and privilege limits. See the GitHub-hosted runner reference for current specifications.

If the job does not fit, compare an appropriate standard hosted runner with a self-hosted machine. Include the plan’s remaining hosted-runner allowance, expected job runtime and frequency, any cloud VM cost, and the work of operating that machine. Do not choose based on the runner’s headline price alone.

4. Put the setup together without assuming stale YAML

The exact workflow depends on your framework and Happo integration, and the available sources do not establish a current universal GitHub Actions YAML, command, secret name or permission list. Use these steps to construct the workflow from the current integration guide:

1. Use the repository’s existing supported Node and package-manager setup, if required by the integration instructions.
2. Install dependencies using the lockfile-aware command already used by the project.
3. Build Storybook or start the application if the integration requires a running target.
4. Invoke the Happo command specified by the current guide, with credentials stored using the guide’s required secret name and scope.
5. Run the check on the chosen CI event and inspect the comparison result against the baseline.
6. Review job duration and snapshot use after real CI runs, then adjust runner type, trigger frequency or browser scope.

For an implementation-ready workflow, take the command, configuration file, secret names and permissions directly from the current Happo instructions for your integration. This prevents a common source of avoidable failures: combining valid pieces from different generations or integrations into a workflow that does not match your project.

5. Keep the monthly estimate useful

Use two small estimates and update them when the workflow changes:

Happo snapshots = variants × browsers × runs per month

Hosted runner use = job minutes × runs per month
Self-hosted machine cost = provisioned machine cost + operating effort

The second pair is a budgeting model, not a provider billing formula. Check GitHub’s current billing page for the account-specific rules. For a private repository, compare expected hosted minutes with the plan allowance. For a public repository, hosted-runner usage is free under GitHub’s stated rules, but the team still needs to understand job limits and any separate services it uses. For self-hosting, include machine costs even when GitHub does not charge for runner use.

From India, use the billing currency, taxes and cloud region terms shown by the services you actually use. The researched sources do not establish India-specific rates or tax treatment, so confirm those directly with the provider before committing to a forecast.

6. Troubleshooting

Symptom	Likely cause	What to check
CI cannot find the Happo command or package	An old package name or instructions for a different integration may be in use.	Check the current integration guide and the repository’s package merge notice. Follow the package and command specified for your setup.
The UI is unavailable when capture starts	The app or Storybook has not been built or served in the way the integration expects.	Check the integration’s required target and startup sequence; ensure the CI job waits for the target to be ready before capture.
Authentication fails in CI	The credential is missing, has the wrong scope, or its secret name does not match the current guide.	Compare the workflow’s secret reference with Happo’s current setup instructions and the repository or environment secret configuration.
CI rejects a secret or permission setting	The workflow may use incorrect names or permissions, or a repository policy may restrict access.	Use the current integration documentation and inspect the repository’s Actions settings and workflow permissions.
Snapshot usage grows faster than expected	Variant count, browser count or run frequency increased.	Recalculate with Happo’s formula. Check whether the workflow is running on more CI events than intended and whether all captured variants are needed.
The job times out on ubuntu-slim	The job exceeds its 15-minute limit or does not fit the runner’s supported workload.	Review job duration and privilege needs. Use a suitable standard hosted runner or compare self-hosting if the workload cannot fit.
A private repository incurs Actions charges	Hosted-runner use exceeded the account’s included allowance, or the budget omitted relevant usage.	Review GitHub billing details for the owning account and adjust frequency, runtime or runner strategy based on actual use.
A self-hosted runner does not stay available	The team-owned machine or runner service is not provisioned or maintained for the job’s needs.	Review machine availability, runner operation and maintenance responsibilities alongside the cloud or on-premises cost.

7. Performance, reliability and cost trade-offs

Performance

Measure the actual end-to-end job: dependency installation, UI build or startup, and screenshot checks. The sources do not provide comparable runtime benchmarks, so there is no defensible claim that a particular runner will be fastest or cheapest for your project. If your job is lightweight and completes inside the documented limit, ubuntu-slim may be worth evaluating; otherwise use a runner that meets the workload requirements.

Reliability

A visual check is useful only when the target UI is ready and the selected integration can reach it. Follow Happo’s readiness and setup requirements, make credentials available to the intended CI events, and keep a clear baseline update process for your team. For pull requests from forks or other restricted contexts, verify how your repository makes secrets available; do not assume every event has the same access.

Cost

Control the two main levers independently: reduce unneeded variant, browser or run counts to manage Happo usage; reduce job runtime or select a runner and trigger strategy that fit the repository’s GitHub allowance to manage Actions spend. Self-hosting shifts runner provisioning and operations to your team, so compare the full machine and maintenance cost rather than the GitHub runner charge alone. Recheck current plan details when quotas, prices or repository settings change.

Or skip the browser setup

If your goal is to capture a website page rather than compare Happo component baselines, ScreenshotNeo is a website screenshot API and MCP server. One GET request can return a PNG, JPEG, WebP or PDF. Here is the cURL form:

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

See the ScreenshotNeo API documentation for parameters and setup. ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

FAQ

Is Happo the same thing as ScreenshotNeo?

No. Happo is used here for visual comparisons against a baseline in CI. ScreenshotNeo is a website screenshot API and MCP server; the capture options and billing model described above are its own product features.

Does Happo’s free plan include multiple browsers?

The pricing page lists the free allowance as 5,000 monthly snapshots in Chrome. Check its current plan details for browser coverage on paid plans.

Is ubuntu-slim always the lowest-cost choice for screenshots?

No universal choice is established. It has a 15-minute timeout and workload restrictions, so compare it with the job’s actual build and browser requirements.

Does this guide provide an India-specific CI price comparison?

No. The available sources establish provider rules and product quotas, not regional vendor prices, VM comparisons or India-specific tax treatment. Confirm those details with your selected providers.