8 months building LinkedIn automation with Puppeteer instead of an API — here's what I learned
Everyone said don't build LinkedIn automation. "LinkedIn will ban you." "The API is closed." "Chrome extensions break every month."
I did it anyway. Here's what 8 months of Puppeteer + Node in the cloud taught me.
The stack (surprisingly boring):
- Node.js + puppeteer-extra + stealth plugin
- Supabase for auth + queues
- Everything runs headless on my own servers, no user browser required
- n8n orchestrates content generation before it hits the LinkedIn flows
I chose server-side browser automation on purpose. Browser extensions (Waalaxy, Dux-Soup, LinkedFusion) all run in the user's Chrome — which means when LinkedIn ships a DOM change on a Thursday, thousands of users wake up to a broken tool on Friday. Running Puppeteer on my own infra means I fix it once, everyone gets the update instantly.
The hard part wasn't the automation. It was the pacing.
Randomized delays, weekday-only sending windows, per-account daily caps that respect LinkedIn's real (undocumented) limits, and a queue that spreads actions across the day like a human actually clicking. Not a single sub-10-second gap. Not a single 3 AM send.
Result: users cut outreach from ~11h45m/week down to ~27min/week (mostly review + approve), and I haven't had an account suspension since I tightened the pacing model in month 4. Not zero risk — nobody who tells you "zero risk" is being honest — but low enough that the €9.99/mo entry tier makes economic sense for the user.
Stuff nobody warns you about:
- Sessions rot. Cookies expire in weird ways. Half my early bug reports were "it stopped working" that turned out to be silent auth failures.
- Selectors are a war. LinkedIn A/B tests the DOM constantly. I now run three selector strategies per action with fallback.
- Cloud costs sneak up. Each active user needs a persistent browser context. Not cheap at scale.
- DACH wants German UI + English support. Serving both cost me two weeks I didn't budget.
If I could restart: I'd ship the pacing engine first, then the UI. I built the pretty dashboard before I fully trusted the automation underneath, and it delayed real feedback by a month.
Built solo out of Leipzig. inboundy.app if anyone wants to see the current state — landing page still needs work, but the engine underneath is where the time went.
Question for the community: anyone else running browser-automation SaaS in the cloud? How are you handling persistent sessions at scale? I'm using isolated user-data dirs per account but the disk footprint is getting real.
