Running Playwright + Headless Chrome on Old Hardware Is Less “Automation” and More “Systems Archaeology”

There is a very specific type of developer optimism that makes you look at a dying 2015 HP laptop and think:

“Yeah, this should absolutely run production browser automation.”

This machine had:

• 6 GB RAM
• a mechanical hard drive
• integrated Radeon graphics
• Linux
• Chrome
• trust issues

I had already memorized Alt + PrintScreen + REISUB because eventually this machine was going to require spiritual intervention.

Naturally, I turned it into a self-hosted automation server running Playwright workers for PostPunk.

Because apparently I enjoy creating problems recreationally.

The Basic Fantasy

The fantasy sounds reasonable enough.

Take an old laptop.
Install Linux.
Run some worker processes.
Use Playwright for browser automation.
Queue content posts automatically.
Stop manually posting to platforms one miserable click at a time.

Honestly?

That last part mattered the most.

I’m stubborn, cheap, and deeply allergic to manually posting content platform-by-platform forever.

Which is basically the entire psychological profile required to build self-hosted automation systems.

At some point this stopped being:

“a fun Linux experiment”

and became:

“the engine for how I actually want to work.”

That meant the machine suddenly mattered.

And unfortunately, so did Chrome.

Everything Was Fine Until Chromium Entered The Story

The Linux side was mostly solid.

Workers behaved.
Scheduling behaved.
Queue processing behaved.
Notifications behaved.

Then Chromium showed up and started acting like the laptop was trying to process emotional trauma in real time.

At first the failures looked random:

• selectors timing out
• uploads silently failing
• clicks not landing
• pages freezing
• workers hanging forever
• random skipped inputs
• inconsistent rendering

The worst part?

The automation usually worked while I was watching it.

Pinterest posted correctly.
Facebook posted correctly.
Dev.to posted correctly.

So naturally I thought:

“Cool. Stable.”

That was a lie.

The Moment I Realized This Wasn’t Just A Script Problem

One night around 3 AM, while manually logging back into one of the platforms, Chromium itself started pixelating.

The screen partially froze.
The UI glitched out.
The machine made that horrible little Linux system ringing noise like everything inside the laptop had briefly entered a panic attack.

I stopped moving the mouse.
Waited a few seconds.
The machine recovered.

Firefox mostly behaved normally.

Chrome behaved like the unstable roommate Linux was too polite to evict.

That was the moment I realized:
this was no longer just a Playwright problem.

Something deeper was happening.

Old Hardware Changes Failure Modes

A lot of browser automation advice accidentally assumes healthy hardware.

People say:

“Playwright works great.”

And I believe them.

But there is usually an invisible footnote:

“on hardware that is not actively fighting for its life.”

Old hardware changes the nature of failures.

On modern systems:

• bad waits
• selectors
• auth issues
• flaky timing

On old systems:

• GPU weirdness
• rendering instability
• browser freezes
• memory pressure
• disk latency
• thermal throttling
• random Chrome existential crises

At some point the machine stopped feeling “slow” and started feeling medically concerning.

The fans would suddenly kick on like the laptop had just seen a tax audit.

Opening Chrome on this thing felt less like launching software and more like asking an elderly wizard for one final favor.

Headless Chrome Is Not Lightweight. It Is Just Invisible

People hear “headless browser” and imagine some tiny efficient automation process.

No.

Headless Chromium still wants:

• RAM
• CPU
• rendering resources
• shared memory
• dependencies
• graphics support
• enough system stability to not implode under load

And when resources get tight, the browser does not always fail cleanly.

Sometimes it just becomes weird.

Which is worse.

The browser would get 95% through a workflow and then suddenly remember it was running on archaeology.

That’s the dangerous middle ground:
not broken enough to diagnose instantly,
not stable enough to trust.

Headed And Headless Chromium Are Basically Different Species

This ended up being the biggest lesson.

The workflows behaved differently depending on whether I could physically see the browser.

That sounds fake until you experience it yourself.

In headed mode:

• rendering slowed things down
• animations had time to finish
• uploads stabilized
• UI transitions completed
• the environment accidentally synchronized itself

Headless mode removed all that padding.

Suddenly the automation was running at full machine speed against a browser environment held together with aging hardware and optimism.

That’s when the race conditions showed up.

This:

await page.click('[data-testid="publish-button"]');

turns out to mean absolutely nothing if:

• React is still hydrating
• uploads are incomplete
• event listeners are not attached yet
• the UI exists visually but not functionally

Watching successful automation manually proves almost nothing.

Production workers do not care about your vibes.

Linux Browser Automation Slowly Becomes Folklore

At some point my debugging strategy stopped being engineering and became ritualistic behavior.

I started:

• reinstalling packages I barely understood
• randomly deleting Chrome-related components
• tweaking launch flags endlessly
• waiting before clicks
• comparing screenshots
• listening for fan noise
• praying to God a little bit

At one point I removed enough Chrome/X11-related stuff that the machine started pixelating outside the browser too.

That was probably the strongest:

“hardware may actually be dying”
moment.

Ironically, reinstalling the things I broke actually improved stability afterward.

Which is the most Linux outcome possible.

GPU Weirdness Is Real

Firefox mostly behaved fine on this machine.

Chrome specifically was chaos.

Even normal Chrome windows were basically a 50/50 gamble:

• maybe fine
• maybe flickering
• maybe partially freezing
• maybe pixelating
• maybe emotionally collapsing halfway through rendering

I still do not fully understand why.

Maybe Chromium was hitting rendering paths the machine hated.
Maybe Linux and Chrome were fighting deep in the graphics stack.
Maybe the laptop itself was just old and tired.

At some point debugging old Linux hardware stops being science and becomes folklore.

What Actually Helped

Not one thing.
Several things.

Moving more flows to headless mode helped because visible Chrome rendering was apparently making the machine more unstable.

Proper waits helped a lot.

I learned very quickly that:

• waits matter more than confidence
• “loaded” does not mean “ready”
• visible UI does not mean interactable UI

Some flags that genuinely helped:

const browser = await chromium.launch({
  headless: true,
  args: [
    '--disable-gpu',
    '--disable-dev-shm-usage',
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-background-timer-throttling',
    '--disable-renderer-backgrounding'
  ]
});

And yes:

npx playwright install-deps

ended up mattering far more than I wanted it to.

My Observability Strategy Became “Listen For The Fan”

Before headless mode, I barely paid attention to my Telegram notifications because I could physically see the automation running.

Once everything moved headless, the notifications became the only reliable proof the workers were alive.

At one point my monitoring stack was basically:

• Telegram alerts
• screenshots
• log files
• listening for fan noise

If I heard the fan suddenly spin up, I knew the workers were probably doing something.

Which is not exactly enterprise observability engineering.

Most of this debugging happened around 3 AM while sitting directly in front of the machine like some kind of browser automation goblin trying to convince Chromium not to explode overnight.

Reliability Is A Much Higher Standard Than “It Worked Once”

This was the real lesson.

A successful run does not prove reliability.

It proves:

one run succeeded under one set of conditions.

That’s all.

Reliable automation means:

• unattended
• repeatable
• observable
• stable under load
• stable overnight
• stable when nobody is staring directly at Chromium like a nervous zookeeper

That is a completely different standard.

Eventually the workers became stable enough that I stopped compulsively checking them every few minutes.

Honestly?

That was probably the real milestone.

Not:

“the scripts worked.”

But:

“I no longer felt emotionally required to supervise Chrome personally.”