n8n is an orchestration layer. It handles scheduling, data transformation, HTTP calls, database operations, and integrations with hundreds of services. What it does not do natively is drive a browser. For any step in an automation workflow that requires a real authenticated browser, posting to a platform with no API, navigating a multi-step UI, maintaining a live session across runs you need to reach outside n8n. The n8n playwright automation question that follows is which approach to use and why the answer matters for production pipelines.
Two approaches exist. One is fast to set up and appropriate for testing. The other is what EchoCast actually runs on. Understanding both and why the choice was made clarifies the architecture.
Option 1: Execute Command Node
n8n’s Execute Command node runs a shell command on the host machine and captures the output. If you have a Playwright script that accepts arguments, n8n can invoke it directly by passing a shell command string. The script reads its payload from process.argv, executes the browser workflow, and exits with a status code. Zero means success. Non-zero means failure. n8n captures stdout and stderr and passes them downstream.
This approach works. It is the right way to validate that n8n can talk to your Playwright scripts before building anything more complex. The debugging loop is fast and runs the exact same command in a terminal and you are replicating what n8n does. The n8n playwright automation is confirmed working with minimal infrastructure.
The structural limits become clear quickly. The Execute Command node is synchronous and stateless from n8n’s perspective. The workflow halts and waits for the script to exit. There is no persistent process. Error reporting is limited to stdout content and exit codes. Managing persistent browser contexts is the mechanism that keeps auth sessions alive across runs and is awkward from scripts that spin up and exit on each call. For a one-off test or an infrequent task, this is acceptable. For a daily pipeline running across five platforms with per-platform session state, it is the wrong tool.
Option 2: Express Wrapper as a Persistent Server
EchoCast runs on echocast-server, a lightweight Express application managed by PM2 that runs persistently alongside n8n on the same machine. n8n calls it via an HTTP Request node as a standard POST with a JSON payload containing the post title, body content, and canonical URL. The server receives the request, resolves which Playwright script to invoke for the target platform, triggers it, and returns a structured JSON response. n8n parses the response and routes to success or error handling.
The PM2 process table shows both n8n and echocast-server as peers, both online, both managed by the same process supervisor, both surviving machine restarts without manual intervention. This is the key structural difference from the Execute Command approach. The server is always running. It does not spin up and exit on each call. It maintains state between requests, handles logging internally, and can manage the auth directory references that persistent contexts require.
The server’s route structure is minimal. One POST route per platform. Each route calls the corresponding Playwright function. Each Playwright function uses launchPersistentContext with the appropriate auth directory for that platform. The response contract is consistent: a success flag, a message, and any relevant metadata about what was posted. n8n does not need to know anything about Playwright internals. echocast-server does not need to know anything about how n8n structures its workflows.
Why This Architecture Was Chosen
The Express server approach was chosen over Execute Command for three reasons that all trace back to the same principle: production automation needs a persistent, observable, independently manageable execution environment.
First, persistent browser context management is significantly cleaner from a running server than from on-demand scripts. The auth directories, the pre-run session checks, the expiry detection, all of this is easier to reason about when the execution environment does not tear itself down after every call.
Second, error handling is more capable. An Express server can log to a structured file, return typed error codes that n8n can act on, and handle partial failures without the n8n workflow needing to parse raw stderr output. The notification path when a session expires n8n receives a specific error code and routes to an alert that requires the server to return structured data, not an exit code.
Third, the HTTP interface is the natural integration point for n8n. n8n speaks HTTP. Every API it integrates with speaks HTTP. Building a small HTTP server around the Playwright execution layer puts it in the same category as any other service n8n calls, which makes the workflow logic cleaner and the mental model simpler.
The full session management mechanism, how auth contexts are stored, checked, and renewed is in Persistent Browser Sessions for Content Automation. The broader pipeline this integration feeds is in n8n + Playwright Content Syndication.
