This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/document-engine/knowledge-base/chromium-remote-debugging-port.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. Document Engine: Chromium process and remote debugging port

Why Document Engine runs Chromium with a remote debugging port

Markdown version of this page, suitable for AI agents and automation

Document Engine starts a Chromium process with the --remote-debugging-port=9222 flag during normal operation. This behavior is expected. Security and process monitoring tools sometimes report the flag because its name contains “debugging,” but the flag doesn’t indicate a misconfiguration or a debug build.

How Document Engine uses Chromium

Document Engine uses headless Chromium to render HTML as PDF for these operations:

  • Generating PDFs from HTML. For details, refer to the PDF generation guide.
  • Processing HTML parts and new blank pages in the Build API.
  • Converting some formats through an intermediate HTML representation before rendering them as PDF.

Document Engine starts one headless Chromium instance at startup, even when you don’t use these features. Chromium runs a main browser process alongside zygote, renderer, and utility processes. These processes appear as multiple Chromium entries in process lists. Each request to render HTML opens a new page in the same instance.

If Chromium exits, Document Engine restarts it automatically. Chromium process IDs can therefore change while the container runs. Document Engine keeps crash logs from the previous process in /tmp/pspdfkit/chromium/crashed_logs/<pid>.

Why the remote debugging port is enabled

Document Engine controls Chromium through the Chrome DevTools Protocol(opens in a new tab) (CDP). Chromium exposes this protocol only when Document Engine starts it with --remote-debugging-port. Document Engine always passes this flag with port 9222.

Network exposure

Chromium binds the remote debugging port only to the loopback interface (127.0.0.1, or ::1 for IPv6). The Chromium remote debugging server(opens in a new tab) source defines this behavior in CreateLocalHostServerSocket, lines 86–95.

The loopback interface limits access to the network namespace where Document Engine runs. The scope depends on your deployment:

  • Container networking — Processes within the container share access.
  • Kubernetes — All containers in the Pod share access, including sidecar and ephemeral containers.
  • Host networking — All processes on the host share access.

Document Engine doesn’t require external access to port 9222. Don’t publish port 9222 through a port mapping or a Kubernetes Service.

Chromium’s remote debugging endpoint has no authentication mechanism. Any process that connects to the endpoint can control the browser. Binding to loopback restricts access to processes within Document Engine’s network namespace. If you use host networking, treat the host as a shared trust boundary.

If port 9222 accepts connections from outside the container or Pod, a deployment component forwards traffic to the port. For example, a proxy or sidecar could forward this traffic.

Remove the forwarding. If you can’t identify the component that forwards traffic, contact Nutrient Support(opens in a new tab).