How to Build a URL-to-Screenshot Service in 2026

From Puppeteer Script to Production Service

Most teams start with a simple Puppeteer script: launch a browser, navigate to a URL, take a screenshot, close the browser. It works great in development. Then you hit production and everything falls apart — browsers crash under load, memory climbs until the server OOMs, cold starts take 8 seconds, and your Node.js process blocks while waiting for Chromium. This guide shows you how to graduate from that script to a robust, queue-backed screenshot microservice.

Why a Naive Puppeteer Script Breaks in Production

The fundamental problem is that launching a Chromium instance for every request is expensive. Each instance uses about 150-200 MB of RAM. At 10 concurrent requests, that's 2 GB of memory gone before your application even starts doing real work. Chromium also crashes randomly — especially on pages with heavy JavaScript, WebGL, or media content. Without a watchdog, a single crash takes your service down.

Network variability is the other killer. Pages that load in 200ms on your laptop take 5 seconds on a cloud VM in a different region. If your HTTP handler waits synchronously for the screenshot, your API gateway will start timing out connections before Chromium finishes rendering.

Architecture: Browser Pool + Job Queue

A production-grade screenshot service has three layers. First, an HTTP API layer that accepts requests and enqueues jobs — it never touches a browser directly. Second, a job queue (Redis-backed BullMQ works well) that holds pending screenshot tasks. Third, a worker pool that maintains a fixed number of Playwright/Puppeteer browser contexts and processes jobs one at a time per worker, reusing browser instances across requests.

// worker/browser-pool.ts
import { chromium, Browser, BrowserContext } from 'playwright';

const POOL_SIZE = 3; // browsers to maintain
const pool: Browser[] = [];

export async function initPool() {
  for (let i = 0; i < POOL_SIZE; i++) {
    pool.push(await chromium.launch({
      args: ['--no-sandbox', '--disable-setuid-sandbox',
             '--disable-dev-shm-usage', '--disable-gpu'],
    }));
  }
}

export async function withContext(
  fn: (ctx: BrowserContext) => Promise<Buffer>
): Promise<Buffer> {
  const browser = pool[Math.floor(Math.random() * pool.length)];
  const ctx = await browser.newContext({ viewport: { width: 1280, height: 800 } });
  try {
    return await fn(ctx);
  } finally {
    await ctx.close(); // contexts are cheap, browsers are not
  }
}

BullMQ Queue Setup

// queue/screenshot-queue.ts
import { Queue, Worker } from 'bullmq';
import { withContext } from '../worker/browser-pool';

export const screenshotQueue = new Queue('screenshots', {
  connection: { host: 'localhost', port: 6379 },
  defaultJobOptions: {
    attempts: 3,
    backoff: { type: 'exponential', delay: 2000 },
    removeOnComplete: 100,
    removeOnFail: 50,
  },
});

export const screenshotWorker = new Worker('screenshots', async (job) => {
  const { url, options } = job.data;
  return await withContext(async (ctx) => {
    const page = await ctx.newPage();
    await page.goto(url, { waitUntil: 'networkidle', timeout: 30000 });
    if (options.delay) await page.waitForTimeout(options.delay);
    const buf = await page.screenshot({ fullPage: options.fullPage ?? false });
    return buf.toString('base64');
  });
}, { connection: { host: 'localhost', port: 6379 }, concurrency: POOL_SIZE });

HTTP API Layer

// api/routes/screenshot.ts (Fastify)
fastify.post('/screenshot', async (req, reply) => {
  const { url, ...options } = req.body as any;

  const job = await screenshotQueue.add('capture', { url, options });

  // Return job ID immediately — don't block
  return reply.code(202).send({ jobId: job.id, status: 'queued' });
});

fastify.get('/screenshot/:jobId', async (req, reply) => {
  const job = await screenshotQueue.getJob(req.params.jobId);
  if (!job) return reply.code(404).send({ error: 'Job not found' });

  const state = await job.getState();
  if (state === 'completed') {
    return { status: 'done', data: job.returnvalue };
  }
  return { status: state, progress: job.progress };
});

Browser Crash Recovery

Browsers crash. Your pool needs a watchdog that detects disconnected instances and replaces them. Listen for the disconnected event on each browser instance and immediately launch a replacement. Combined with BullMQ's built-in retry logic (exponential backoff, configurable attempts), most transient failures recover automatically without customer impact.

async function launchWithWatchdog(index: number) {
  const browser = await chromium.launch({ args: CHROME_ARGS });
  pool[index] = browser;
  browser.on('disconnected', () => {
    console.warn(`Browser ${index} crashed — restarting`);
    launchWithWatchdog(index); // restart immediately
  });
}

Why Use SnapAPI Instead

Building and operating the above infrastructure takes weeks, not hours. You need to manage Chromium updates, handle stealth/anti-bot detection for protected pages, provision storage for captured images, implement rate limiting per customer, monitor memory leaks, and keep the browser pool healthy 24/7. That's a part-time DevOps job for a screenshot feature.

SnapAPI handles all of this for you. A single API call returns a hosted screenshot URL in 2-4 seconds. The Free plan gives you 200 captures a month to evaluate — no infrastructure to provision, no Chromium version to pin, no OOM crashes to debug at 3 AM. When your volume grows, scale with a plan upgrade rather than adding servers.

That said, the architecture patterns above are genuinely useful to understand — they explain exactly why SnapAPI is architected the way it is internally. If you ever need to build custom capture logic that goes beyond what an API can offer, this is the foundation to build on.