Deploying Headless Chrome in production might seem trivial at first: just launch a browser without a GUI, load a URL, and capture a screenshot or PDF. However, the real experience of maintaining such a system at scale reveals challenges that go far beyond the initial fifteen lines of code. At Q2BSTUDIO, where we build custom software for demanding environments, we have learned that managing Chrome's lifecycle is a systemic problem, not a simple API tweak. Below, we explore the most common obstacles and how to overcome them with a robust architecture.
Memory management: the first wallA single headless Chrome process consumes between 150 and 300 MB of RSS, and tends to increase over time due to inherent memory leaks. Chrome was designed to be closed at the end of the day, not to stay active for weeks. In a container with a fixed memory limit, the outcome is inevitable: the kernel kills the process with a SIGKILL at 2 AM, and logs show no stack trace. The solution isn't a magic line of code but lifecycle management: limit the number of renders per instance and recycle it completely. For example, close the browser and launch a new one every N pages so that leaks are reclaimed by process death, not by hope. Also, size concurrency based on available RAM, not CPU: if each render takes 250 MB, eight concurrent renders consume 2 GB before counting the OS.
Zombie processes: the ones that don't dieChrome is not a single process but a tree: main process, zygote, renderers, GPU, and helpers. When the parent node dies abnormally, children become orphaned and are reparented to init, consuming memory and file descriptors. Accumulating thousands of these processes exhausts PIDs or FDs, paralyzing the system. The pragmatic fix is to track the browser's PID and, on abnormal exit, kill the entire process group instead of relying on browser.close(). In containers, using a real init (like tini or dumb-init) ensures automatic reaping of orphans.
Cold starts: the 800ms taxLaunching Chrome from scratch costs about 800 milliseconds before rendering a single pixel. If you launch a new browser per request, you pay that tax every time, and for simple tasks it can double the response time. The temptation is to keep a single instance alive forever, but that leads back to memory issues. The key is to reuse the instance but isolate each render using browser contexts. A context is a clean, cookieless, cacheless session that is cheap to create and destroy. This way, you pay the cold start once per instance lifetime, each request gets its own disposable context, and the instance is recycled after N renders. On clouds like AWS or Azure, this strategy allows scaling without wasting resources.
Fighting pages: hard timeoutsA malicious or malformed URL can cause infinite redirects, a page that never fires the load event, or a WebSocket keeping the network busy forever. Without a strict time limit, a single render can block a browser until someone manually kills it. The golden rule is to set timeouts for both navigation and capture, and if they are exceeded, kill the entire instance and launch a new one. Trying to revive a hung browser is risky: it carries indeterminate state. This policy may seem wasteful, but it is the single most reliability-improving rule in the system.
Concurrency: queue, not loopThe naive approach is to render inline: when a request arrives, take or create a browser, render, and respond. Under load, this is a recipe for disaster: a traffic spike becomes N simultaneous browsers, leading to OOM and failure of all in-flight requests. The solution is to insert a queue between the request and the render. The API accepts the job and returns immediately; a pool of workers consumes jobs at a rate their RAM can handle. A traffic spike translates into queue depth, a metric you can monitor and autoscale on, instead of a memory graph that falls off a cliff. Queue depth is your early-warning capacity signal.
Font stack: the missing linkOn a laptop, fonts are installed; on a minimal Linux container, they are not. The result is empty rectangles or tofu symbols where CJK text or emojis should appear. To achieve faithful rendering, you need a font pipeline: a base set, CJK coverage, an emoji font, and the awareness that Chrome upgrades can silently shift glyph rendering. If you cache the generated images, version them so you can invalidate when the rendering engine changes.
Serverless is not a shortcutThe temptation to delegate everything to Lambda or serverless functions moves the problems, it doesn't remove them. You must package a slimmed-down Chromium to fit size limits, you suffer multi-second cold starts on every scale-up, and you hit memory and timeout constraints. Also, fonts and security remain your responsibility. Serverless can be a legitimate deployment target, but with a different set of sharp edges, not fewer.
SSRF: the hidden dangerWhen the renderer accepts URLs from third parties, the risk of Server-Side Request Forgery appears immediately. A malicious user can send https://169.254.169.254/latest/meta-data/ and the obliging browser will read cloud credentials and return them as an image. The solution is not a simple if statement but a complete module that resolves DNS on its own, checks each IP against private and loopback ranges, pins the validated IP, and rechecks on every redirect. At Q2BSTUDIO, we integrate these cybersecurity measures in all our solutions handling sensitive data.
When to do it yourselfIf you only render a few of your own pages on demand, self-hosting is perfectly viable. The problem arises when volume grows, traffic spikes are unpredictable, or URLs come from users. At that point, maintaining a reliable system requires the same infrastructure we offer through our AI and automation services: queues, worker pools, instance recycling, timeouts, and a solid security layer. Combined with BI and Power BI tools for monitoring performance, you can build a service that not only works but scales without surprises.
The final lesson is that Headless Chrome in production is not a fifteen-line problem; it is a system problem. With the right architecture, AI agents can even orchestrate the worker lifecycle autonomously. But that's another story.
