I’m pulling my hair out trying to manage cookies across multiple headless browser instances. Our automation setup has to maintain multiple user sessions for testing, and keeping the authentication cookies in sync is driving me crazy.
We have several automated workflows that need to transfer cookies between different parts of our testing pipeline - one workflow logs in, another needs to use those credentials to access restricted areas, and so on.
Right now I’m using a hacky solution with file storage to pass cookies between browsers, but it breaks constantly, especially when we need to run tests in parallel. The cookies often expire or get overwritten, and then everything falls apart.
Has anyone figured out an elegant way to handle cookie synchronization between headless browsers? I need something visual that doesn’t require writing complex synchronization code every time we change our testing flow.
I dealt with this exact problem when building our checkout process tests. Cookie management across headless browsers is a real pain.
After wasting weeks on custom solutions, I found that Latenode’s visual builder solves this perfectly. I created a workflow that handles cookie extraction, storage and injection with just a few connected nodes.
The key feature is that it has a headless browser node that can extract cookies and another that can inject them. Between these, I use their storage nodes to maintain the session data across different test runs. The visual builder makes it super easy to design the flow without any code.
What’s really powerful is that when cookie formats change, I don’t have to rewrite code - I just adjust the visual workflow. When we added 2FA to our site, I updated the workflow in minutes instead of rewriting scripts.
Give it a try - it’s saved me countless hours of debugging cookie issues: https://latenode.com
I solved this by creating a centralized cookie repository using Redis. The setup is pretty straightforward:
Each browser instance writes its cookies to Redis after login/important actions
Before starting a new test, browsers pull the relevant cookie set from Redis
We use a simple naming convention: {testType}:{userRole}:{timestamp} as the key
The timestamp part is crucial - it lets us keep multiple cookie sets valid simultaneously for different test phases. We also built a simple expiration policy that mirrors the actual cookie TTLs.
The whole thing is maybe 200 lines of code and has been super reliable for our team of 12 testers running thousands of tests daily.
We tackled this by implementing a session management service that sits between our test execution framework and the browser instances. It’s essentially a REST API with endpoints for storing and retrieving cookie data.
When a test logs in successfully, it calls the service to store the cookies with metadata (user type, environment, etc.). Later tests can request cookies matching specific criteria. The service handles serialization, deserialization, and expiration management.
We also added a simple UI that shows active sessions and their status, which helps with debugging. The whole thing runs in a Docker container and persists data to a MongoDB instance.
This approach decouples the cookie management from the actual test code, making both easier to maintain. It’s been especially helpful when running tests across different CI/CD pipelines that need to share authentication states.
I implemented a cross-browser cookie synchronization system using a combination of WebDriver CDP (Chrome DevTools Protocol) and a simple state management server.
The architecture has three components:
A lightweight Express server that stores session state with appropriate indexing
Browser extension methods that abstract the cookie extraction and injection
A test framework plugin that handles the communication
The key insight was using CDP’s Network.setCookies and Network.getCookies commands rather than the more limited WebDriver cookie interfaces. This gives us complete control over cookie properties including SameSite, Secure flags, and HttpOnly cookies.
We’ve been running this system for over a year with 50+ daily builds, each containing hundreds of tests across multiple browser versions, with very few issues.