Production Browser Automation & Integration Platform

A production platform combining API integrations with persistent, recoverable browser automation for business-critical external workflows.

Automation · Integration platformBack-End & Automation Technical LeadConfidential production environment

Context

External business systems offered different ways to integrate. APIs were used where they could support the workflow; other cases required authenticated browser interaction, persistent session state, security prompts, and occasional human intervention.

What had to be solved

The engineering problem was not simply launching Chrome processes. It was operating API and browser-based workflows over long periods while keeping authentication, process state, failures, recovery, and operational support manageable.

System boundaries

  • Authenticated workflows could include passwords, multi-step login states, 2FA, PIN or security prompts, and human intervention.
  • Service restarts could not automatically destroy valid running browser sessions.
  • Multiple concurrent sessions required isolated profiles, explicit ownership, proxy allocation where needed, and per-session remote-debugging endpoints.

Back-End & Automation Technical Lead

  • Led the technical evolution of the back-end and browser-automation architecture while remaining hands-on with critical implementation.
  • Owned integration design, browser-lifecycle decisions, reliability patterns, technical reviews, and production-readiness validation.
  • Designed the separation between platform-specific workflow logic and the dedicated service responsible for browser ownership, state, and lifecycle.

System model

Platform architectureEach business workflow used an API when the available interface was sufficient. Browser automation handled workflows that still required authenticated interaction, while process state and reliability controls remained explicit across both paths.
Business workflow
Automation / orchestration
API integrationBrowser automation
Process / session state
Reliability / observability
Browser subsystemThe browser-management service owns browser metadata and lifecycle, while platform-specific automation connects to the session it needs without owning the Chrome process itself.
Automation workflow
Browser-management service
Profile · Lifecycle · Optional proxy
Persistent Chrome session
Remote debugging · CDP control
Authenticated external system

Where the complexity lived

  • Maintaining authentication continuity across cookies, local storage, open tabs, and other session state held inside isolated profiles and long-running Chrome processes.
  • Maintaining explicit ownership for multiple isolated sessions, including profile paths, allocated proxies where required, debugging ports, and expiry metadata.
  • Supporting remote session viewing and inspection when workflows required operational support or human intervention.
  • Reattaching automation to an existing long-running browser through its remote-debugging endpoint after the management service restarted.
  • Distinguishing stale session metadata or processes from valid running sessions during cleanup and recovery.

How the solution was structured

  • Separated workflow orchestration, platform-specific automation, and browser lifecycle responsibilities. Puppeteer or Playwright could be used where a workflow required them without making either library the browser-management boundary.
  • Used per-session remote-debugging endpoints and Chrome DevTools Protocol control to reconnect automation to existing sessions without coupling each task to the lifetime of a browser process.
  • Persisted browser and session metadata separately from process lifetime so the management service could recover operational knowledge after restart and make explicit cleanup decisions.

Architecture evolution

01

Workflow Automation

Platform-specific automation and operational workflows.

02

Structured Back-End Integration

Services, API orchestration, and explicit process/session state.

03

Browser Infrastructure

Persistent sessions, isolated profiles, proxies, and remote debugging/control.

04

Dedicated Browser Management

Browser lifecycle and ownership separated from automation logic.

05

Agentic Exploration

A Browser Use proof of concept tested attaching a task-oriented agent to an existing CDP session. It was exploratory and was not deployed as production functionality.

Production behavior

  • Retries, timeouts, validation, safe reruns, and recoverable failure paths.
  • Persisted browser/session metadata and structured logs kept operational state available for recovery, inspection, and support.
  • Stale browser cleanup without treating every service restart as authority to terminate valid sessions.

What the work established

  • A platform that could use APIs or controlled browser sessions according to each external workflow's integration capabilities, with explicit browser ownership, persisted session knowledge, recovery behavior, and support for remote inspection.

Technologies and systems

Node.jsNestJSTypeScriptMySQLPrismaPuppeteerPlaywrightChrome DevTools ProtocolREST APIsWebhooks

Third-party platform names, employer-sensitive workflows, credentials, account data, and proprietary implementation details are intentionally omitted.