Securely Pass Multiple Credentials from n8n to Browserless

INTRODUCTION

While working on a market intelligence SaaS platform, our team was tasked with building a scalable data aggregation engine. The architecture relied heavily on self-hosted automation, utilizing n8n for orchestration and Browserless for executing headless Puppeteer scripts. Both services were running in isolated Docker containers to ensure clean separation of concerns and maintain scalable infrastructure.

During the integration phase, we encountered a significant security and architectural roadblock: we needed to pass two distinct sets of credentials from n8n to Browserless. The first was an API token to authenticate the HTTP request to the Browserless instance itself. The second was a set of credentials required by the Puppeteer script to log into the target external websites. Because of how the n8n HTTP node processes payloads and how Browserless handles execution contexts, combining these requirements without exposing secrets became a complex puzzle.

Leaving credentials in plain text or hardcoding them into the script was out of the question for a production-grade system. This challenge forced us to rethink how we map and inject secure data across containerized services. We are sharing this deep dive into our diagnostic and resolution process so other engineering teams can avoid the same operational bottlenecks when building secure, headless automation workflows.

PROBLEM CONTEXT

In our Dockerized environment, the automation workflow depended on an n8n HTTP Request node sending a POST request to the Browserless container. To successfully execute the job, the payload had to deliver the Puppeteer JavaScript logic and the dynamic parameters required for the scrape.

The business use case demanded that our automation dynamically log into various third-party portals based on the client configuration. This meant the target website credentials changed per execution. From an architectural standpoint, the flow looked like this:

• n8n triggers the workflow and determines the target portal.
• n8n retrieves the securely stored credentials for that portal.
• n8n formulates a request to Browserless.
• Browserless authenticates the request, spins up a headless browser, and executes the script using the injected external portal credentials.

WHAT WENT WRONG

As we mapped out the data payload, several interconnected limitations surfaced, threatening the security and viability of the implementation:

• Single Credential Limitation: The n8n HTTP Request node natively accepts only one credential configuration via its UI. We used this to pass the Browserless authentication token, leaving no native way to attach the target website credentials.
• Security Risks in Scripts: Injecting the target site credentials directly into the JavaScript string as variables was a massive security flaw. The script payload could easily be logged or exposed in trace monitors, leaking plain-text passwords.
• Header Inaccessibility: We attempted to pass the target credentials via custom HTTP headers. However, the JavaScript execution environment inside Browserless operates in a sandboxed context; it cannot natively retrieve custom request headers passed to the trigger endpoint.
• Context Overwrite Issue: The Browserless API body strictly accepts only code and context fields. The context field is meant for passing dynamic variables. When we attempted to map n8n credentials directly into the context using n8n expressions, the entire context object was overwritten by the credential object. This meant we could pass the credentials, but all other necessary runtime variables (like target URLs, search strings, or client IDs) were completely wiped out.

We were stuck in a loop: we could not use headers, we refused to hardcode secrets, and passing them via the required context object erased our operational variables.

HOW WE APPROACHED THE SOLUTION

Our primary directive was clear: maintain a strict zero-hardcoding policy while ensuring all dynamic variables reached the Puppeteer script intact. We realized that relying solely on the HTTP Request node to handle both structural payload creation and secret injection was the root cause of the limitation.

To solve this, we needed to decouple the credential retrieval from the HTTP dispatch. We evaluated n8n’s internal programmatic capabilities and decided to leverage an intermediary Code Node. By using the Code Node, we could interact securely with n8n’s credential vault via its internal API, retrieve the necessary target site secrets in memory, and manually construct a unified data object.

This approach offered a robust tradeoff: it added one extra node to the workflow but provided absolute control over the JSON structure. We could combine the dynamic workflow variables and the secure website credentials into a single, comprehensive context object before the payload ever reached the HTTP node. The Browserless token would then remain the sole credential managed directly by the HTTP node’s native authentication settings.

FINAL IMPLEMENTATION

We implemented a three-step pipeline to handle the payload securely. Here is the technical breakdown of the resolution.

Step 1: Constructing the Unified Payload Securely

Prior to the HTTP node, we inserted a Code Node. Inside this node, we utilized the n8n method designed to fetch credentials securely during execution. We extracted the required target credentials and merged them with our standard runtime variables into a new object called mergedContext.

// n8n Code Node Implementation
// Securely fetch target website credentials from n8n vault
const targetCreds = await this.getCredentials('targetSiteApiCredentials');
// Combine standard workflow variables with secure credentials
const scriptContext = {
  targetUrl: $input.item.json.targetUrl,
  searchQuery: $input.item.json.searchQuery,
  portalUsername: targetCreds.username,
  portalPassword: targetCreds.password
};
// Return the properly structured object for the next node
return {
  json: {
    mergedContext: scriptContext
  }
};

Step 2: Configuring the HTTP Request Node

With the unified payload constructed, the HTTP Request node became much simpler and cleaner. We configured the node to handle only the communication with Browserless.

• Authentication: We mapped the Browserless API token using the node’s native standard Generic Credential configuration (passed securely as a Query Parameter or Header depending on the specific Browserless configuration).
• Body Configuration: We defined the JSON body manually, mapping the script logic to the code field, and pulling our perfectly structured object into the context field.

{
  "code": "module.exports = async ({ page, context }) => { n await page.goto(context.targetUrl);n await page.type('#username', context.portalUsername);n await page.type('#password', context.portalPassword);n await page.click('#login-btn');n // Continue scrape logic...n};",
  "context": "={{ $json.mergedContext }}"
}

Step 3: Validation and Security Considerations

By mapping the object entirely through the expression ={{ $json.mergedContext }}, we bypassed the n8n UI bug that previously overwrote the context object. The Puppeteer script received both the search parameters and the credentials cleanly via the internal context argument. Because this happened strictly over internal Docker networking and the secrets were never stored in static strings, we maintained compliance with our security policies.

LESSONS FOR ENGINEERING TEAMS

Solving this architectural quirk reinforced several best practices for complex orchestration environments. When you hire software developer teams to build enterprise automations, these are the standards they should enforce:

• Abstract Authentication from Execution: Never rely on a single execution node to handle complex, multi-layered authentication. Process secrets upstream in isolated, programmatic steps before formatting the final external request.
• Master Payload Architecture: Understanding how your orchestration tool parses JSON expressions is critical. Overwriting behaviors are common in low-code UI layers; bypassing them via programmatic data construction is often the safest route.
• Protect Inter-Container Communication: Even when services like n8n and Browserless share a Docker network, payload structures must be sanitized. Never assume that an internal network eliminates the need for secure secret handling.
• Leverage Internal APIs for Secrets: Tools like n8n provide internal APIs (like credential fetching in Code Nodes) for a reason. Utilizing these prevents secret leakage in workflow exports or UI trace logs. Organizations that hire nodejs developers for backend automation should ensure their teams are highly proficient in programmatic secret management.
• Design for Extensibility: By structuring a unified context object, adding new parameters or secondary credentials in the future requires modifying only the intermediary Code Node, rather than refactoring the entire HTTP request or Browserless script. This modularity is a hallmark of teams that hire automation engineers for custom workflows.

WRAP UP

Passing multiple credentials across isolated container boundaries requires a careful balance between security and functional payload design. By leveraging upstream programmatic data merging, we bypassed the inherent limitations of standard HTTP nodes and context overwriting. This ensured our headless automation remained highly dynamic, entirely secure, and ready for enterprise scale. If your enterprise is navigating similar architectural complexities and needs resilient technical solutions, contact us.

Social Hashtags

#n8n #Puppeteer #Browserless #WebAutomation #DevOps #AutomationEngineering #WebScraping #LowCode #WorkflowAutomation #Docker #SoftwareArchitecture #HeadlessBrowser #DataAutomation #CloudAutomation #NodeJS