How to Use Loki to Take Website Screenshots on a Low-Cost Linux Server in India
Use Loki for Storybook visual regression on Linux: configure Chrome in Docker, create baselines, run comparisons, and weigh a VPS against CI.
Direct answer: Loki (oblador/loki) captures Storybook stories and compares them with saved reference images. On a Linux server, the project recommends Chrome in Docker. Install Loki in your Node project, make Storybook available, create the initial references with yarn loki update, then run yarn loki test after changes and review the results. Loki does not start Storybook for you.
This is not Grafana Loki, and it is not a crawler or general-purpose service for taking scheduled screenshots of arbitrary public websites. If you need screenshots of live URLs instead of Storybook components, see the ScreenshotNeo option below.
1. Check whether Loki fits the job
Use Loki when you want visual regression checks for a Storybook project: it captures stories, compares them with approved reference images, and produces differences for review. It is a fit when a code change should be checked against known component appearances.
Before choosing a server, confirm your project can run Storybook and that its Node, Storybook, Chrome, and Docker versions work together. Loki’s documentation lists Node 16 or later as a prerequisite. Its documentation may lag current package releases, so check compatibility against the version you install.
2. Install Loki and create a baseline
Run these commands from the project directory. The commands use Yarn, as in Loki’s getting-started guide.
yarn add loki --dev
yarn loki init
Start Storybook in a separate process or service. For example, a project may expose a script such as yarn storybook; use the actual script and port configured by your project. Loki expects Storybook to be available and does not launch it automatically.
With Storybook running, create reference screenshots:
yarn loki update
Inspect the generated images. These are the approved appearance against which subsequent runs are compared. Commit the references with the code so teammates and CI use the same baseline. The documentation describes image directories differently across pages and versions; check the paths printed by your installed Loki release rather than relying on a hard-coded path.
3. Run a visual comparison
After changing components or stories, ensure Storybook is available and run:
yarn loki test
Review the captured images and differences before approving a change. A visual difference can indicate a regression, an intentional design update, or a capture environment that has drifted. If the change is intentional, update the reference images and commit them alongside the code.
The CLI documentation lists default paths including ./.loki/reference, ./.loki/current, and ./.loki/difference; the getting-started page describes paths under loki/. This is a documentation/version discrepancy. Use the paths reported by your installed version.
4. Run Chrome in Docker on Linux
Loki documents Chrome in Docker as its recommended platform. Its configuration guide exposes the chrome.docker target. The project also documents local Chrome and AWS Lambda targets, but Docker is the directly relevant documented option for a Linux host.
Run yarn loki init and inspect the generated configuration for the installed version. Confirm it selects the Docker Chrome target, then run the update and test workflow above. Loki documentation lists a Docker image default and a Chrome concurrency default of four; these are version-sensitive configuration details, not a guarantee that a small server can sustain four browsers. Reduce concurrency if the host runs short on CPU or memory, and confirm the Docker daemon and browser dependencies are available to the process running Loki.
Keep the capture environment stable between baseline creation and comparison: use the same dependency lockfile, browser target, Storybook build, viewport configuration, fonts, and relevant environment variables. Differences caused by changed fonts, data, animations, time-dependent content, or browser versions can obscure actual UI changes. Where stories allow it, use deterministic data and avoid transient content.
5. Decide between a VPS, local execution, and CI
The Loki documentation establishes supported execution targets and a static-build CI workflow; it does not identify the cheapest India server, publish a VPS price comparison, or report a minimum resource size or measured speed. Treat the host choice as a workload and maintenance decision.
| Option | What to evaluate |
|---|---|
| Linux VPS with Docker | Current provider price, region, CPU and memory limits, bandwidth, Docker support, maintenance, and whether runs are frequent enough to justify an always-available host. |
| Local Chrome | Compatibility with your development machine and whether local browser differences are acceptable for your team. |
| CI with a built Storybook | CI setup effort, usage terms and current cost, repeatability, and whether you want captures on each change without maintaining a server. |
| AWS Lambda target | Compatibility and current operating terms for your workload; the Loki sources list the target but do not compare its cost with an India VPS. |
For an intermittent workload, compare the cost of maintaining an idle server with the current terms of your CI provider. For a frequent workload, measure your own Storybook suite on the selected host. Neither the available sources nor Loki’s configuration defaults establish a universally low-cost India setup.
6. Use the documented static Storybook CI workflow
Loki’s CI guide documents building a static Storybook and running Loki with --requireReference. This lets CI compare against committed references and fail when expected references are missing. Adapt the commands to the build and output directory used by your Storybook version and project.
# Example workflow shape; substitute your project's actual build script and output directory.
yarn build-storybook
yarn loki test --requireReference
Make sure the built Storybook is served or otherwise made available as required by the installed Loki configuration before running the test command. The documented CI approach avoids needing a permanently running VPS, but the sources do not establish whether CI or a server costs less in India. Check current provider terms and compare them using your actual run frequency.
7. Troubleshoot common failures
| Symptom | Likely cause | What to do |
|---|---|---|
| Loki cannot connect to Storybook | Storybook is not running, is listening on another port, or the configured address is unreachable from the browser container. | Start Storybook separately, verify its host and port, and check that the Docker browser can reach that address. |
| Docker or Chrome fails to launch | Docker is unavailable to the account running the job, the configured image cannot be used, or the host lacks required runtime support. | Check Docker daemon access and the selected image/configuration. Review the installed Loki version’s Docker setup and host requirements. |
| Every story differs from its reference | The capture environment changed, references are absent or from another version, or content is nondeterministic. | Check browser target, viewport, fonts, data, animation, and Storybook build. Regenerate references only after verifying the change is intended. |
| CI reports missing references | The reference images were not committed or CI is reading a different reference path. | Commit the approved baseline and confirm the configured paths against the installed version. Use --requireReference as documented when CI should fail on missing baselines. |
| Run is slow or the host becomes unstable | Concurrency or browser resource use exceeds what the host can sustain. | Lower concurrency and run the suite on the actual host to assess resource needs; the documented default is not a sizing recommendation. |
| Unexpected diffs after dependency updates | Storybook, Loki, Chrome, fonts, or other rendering dependencies changed. | Review version changes and capture environment before accepting new references. Verify compatibility with current package and browser versions. |
8. Cost and reliability considerations
- Do not infer India pricing from the tool documentation. Check the provider’s current price, region, resource caps, bandwidth, and billing terms.
- Include maintenance in the estimate. A VPS needs Docker and project dependencies maintained, disk space monitored, and a stable execution environment.
- Control resource use. Browser concurrency affects CPU and memory demand. Tune it against observed behavior on your server rather than relying on the documented default.
- Keep baselines reviewable. Commit approved references with code and inspect diffs before updating them, so an unintended change does not silently become the expected appearance.
- Make captures repeatable. Pin dependencies and control story data and rendering conditions where possible; environment drift can create noisy comparisons.
Or skip the browser setup
If your goal is screenshots of live web pages rather than Storybook visual regression, ScreenshotNeo is a website screenshot API and MCP server. Its API returns a screenshot or PDF from one GET request. See the API documentation for options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
- Cookie banners are accepted and removed before the shot; known consent platforms, newsletter popups, and chat widgets can also be removed, with each step configurable.
- Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed; response headers report the page verdict and billing status.
- An MCP server provides
take_screenshot,get_page_info, andcapture_pdftools 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 screenshots; every feature is on every plan.
Sign up for 1,000 free screenshots a month with no card.
FAQ
Does Loki take screenshots of any URL?
No. This Loki is designed to capture Storybook stories for visual regression, not crawl arbitrary websites.
Does Loki start Storybook?
No. Start or serve Storybook separately and make it reachable to Loki.
Is there a verified cheapest Linux server in India for Loki?
The cited Loki sources contain no India provider comparison, price, or performance measurements. Compare current provider terms and validate your own workload.
Where are Loki’s images stored?
Documented paths differ between pages and may vary by version. Check the paths reported by the installed package and configure your workflow accordingly.
Sources
- Loki getting started — prerequisites and baseline workflow.
- Loki project documentation — supported platforms and project scope.
- Loki configuration and CLI reference — targets and configuration details.
- Loki CI guide — static Storybook workflow.
- Loki on npm — package release information; verify current compatibility before adoption.


