Failed to launch the browser process!

[tismofied]

just spun up this container . the amazon links work but not other stores. tried bestbuy , walmart amd samclub but I keep getting

priceghost-backend   | Starting scheduled price check...
priceghost-backend   | Found 0 products to check
priceghost-backend   | Scheduled price check complete
priceghost-backend   | [Voting] www.walmart.com requires browser rendering, using Puppeteer...
priceghost-backend   | [Voting] Error scraping https://www.walmart.com/ip/Apple-TV-4K-64GB-3rd-gen-Wi-Fi-MN873LL-A-2022/1529556266?classType=REGULAR&athbdg=L1200&from=/search: Error: Failed to launch the browser process!
priceghost-backend   | chrome_crashpad_handler: --database is required
priceghost-backend   | Try 'chrome_crashpad_handler --help' for more information.
priceghost-backend   | [35:35:0127/171248.399842:ERROR:third_party/crashpad/crashpad/util/linux/socket.cc:120] recvmsg: Connection reset by peer (104)

[clucraft]

just spun up this container . the amazon links work but not other stores. tried bestbuy , walmart amd samclub but I keep getting

priceghost-backend   | Starting scheduled price check...
priceghost-backend   | Found 0 products to check
priceghost-backend   | Scheduled price check complete
priceghost-backend   | [Voting] www.walmart.com requires browser rendering, using Puppeteer...
priceghost-backend   | [Voting] Error scraping https://www.walmart.com/ip/Apple-TV-4K-64GB-3rd-gen-Wi-Fi-MN873LL-A-2022/1529556266?classType=REGULAR&athbdg=L1200&from=/search: Error: Failed to launch the browser process!
priceghost-backend   | chrome_crashpad_handler: --database is required
priceghost-backend   | Try 'chrome_crashpad_handler --help' for more information.
priceghost-backend   | [35:35:0127/171248.399842:ERROR:third_party/crashpad/crashpad/util/linux/socket.cc:120] recvmsg: Connection reset by peer (104)

Did you pull my docker image or how did you set this up?

[tismofied]

Yes your image. this one right here
All I did was create a secret key for jwt and changed ports because uptime-kuma uses port 3001. also changed port 80 for front end

[clucraft]

Yes your image. this one right here All I did was create a secret key for jwt and changed ports because uptime-kuma uses port 3001. also changed port 80 for front end

What platform and architecture?

[tismofied]

 -------------
   ,g$$P""       """Y$$.".     OS: Debian GNU/Linux 13 (trixie) x86_64
  ,$$P'              `$$$.        Host: 10SKS03J00 (ThinkCentre M920s)
',$$P       ,ggs.     `$$b:    Kernel: Linux 6.17.4-1-pve
`d$$'     ,$P"'   .    $$$     Uptime: 3 days, 19 hours
 $$P      d$'     ,    $$P     Packages: 484 (dpkg)
 $$:      $$.   -    ,d$$'     Shell: bash 5.2.37
 $$;      Y$b._   _,d$P'     Terminal: /dev/pts/3
 Y$$.    `.`"Y$$$$P"'       CPU: Intel(R) Core(TM) i7-8700 (3) @ 4.60 GHz
 `$$b      "-.__               GPU: Intel Device 3E92 (VGA compatible) @ 1.20 GHz [Integrated]
  `Y$$b                         Memory: 4.76 GiB / 14.97 GiB (32%)
   `Y$$.                        Swap: 507.96 MiB / 512.00 MiB (99%)
     `$$b.                      Disk (/): 43.68 GiB / 97.87 GiB (45%) - ext4
       `Y$$b.                  Local IP (eth0): 192.168.10.163/24
         `"Y$b._               Locale: en_US.UTF-8

docker version
Client: Docker Engine - Community
 Version:           29.1.5
 API version:       1.52
 Go version:        go1.25.6
 Git commit:        0e6fee6
 Built:             Fri Jan 16 12:48:42 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.1.5
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       3b01d64
  Built:            Fri Jan 16 12:48:42 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[clucraft]

 -------------
   ,g$$P""       """Y$$.".     OS: Debian GNU/Linux 13 (trixie) x86_64
  ,$$P'              `$$$.        Host: 10SKS03J00 (ThinkCentre M920s)
',$$P       ,ggs.     `$$b:    Kernel: Linux 6.17.4-1-pve
`d$$'     ,$P"'   .    $$$     Uptime: 3 days, 19 hours
 $$P      d$'     ,    $$P     Packages: 484 (dpkg)
 $$:      $$.   -    ,d$$'     Shell: bash 5.2.37
 $$;      Y$b._   _,d$P'     Terminal: /dev/pts/3
 Y$$.    `.`"Y$$$$P"'       CPU: Intel(R) Core(TM) i7-8700 (3) @ 4.60 GHz
 `$$b      "-.__               GPU: Intel Device 3E92 (VGA compatible) @ 1.20 GHz [Integrated]
  `Y$$b                         Memory: 4.76 GiB / 14.97 GiB (32%)
   `Y$$.                        Swap: 507.96 MiB / 512.00 MiB (99%)
     `$$b.                      Disk (/): 43.68 GiB / 97.87 GiB (45%) - ext4
       `Y$$b.                  Local IP (eth0): 192.168.10.163/24
         `"Y$b._               Locale: en_US.UTF-8

docker version
Client: Docker Engine - Community
 Version:           29.1.5
 API version:       1.52
 Go version:        go1.25.6
 Git commit:        0e6fee6
 Built:             Fri Jan 16 12:48:42 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.1.5
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       3b01d64
  Built:            Fri Jan 16 12:48:42 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Hmm it could be a shared memory issue since Chrome needs it. Or docker security issue. I'm not really sure to be honest. I'm running it on Unraid myself.

[clucraft]

 -------------
   ,g$$P""       """Y$$.".     OS: Debian GNU/Linux 13 (trixie) x86_64
  ,$$P'              `$$$.        Host: 10SKS03J00 (ThinkCentre M920s)
',$$P       ,ggs.     `$$b:    Kernel: Linux 6.17.4-1-pve
`d$$'     ,$P"'   .    $$$     Uptime: 3 days, 19 hours
 $$P      d$'     ,    $$P     Packages: 484 (dpkg)
 $$:      $$.   -    ,d$$'     Shell: bash 5.2.37
 $$;      Y$b._   _,d$P'     Terminal: /dev/pts/3
 Y$$.    `.`"Y$$$$P"'       CPU: Intel(R) Core(TM) i7-8700 (3) @ 4.60 GHz
 `$$b      "-.__               GPU: Intel Device 3E92 (VGA compatible) @ 1.20 GHz [Integrated]
  `Y$$b                         Memory: 4.76 GiB / 14.97 GiB (32%)
   `Y$$.                        Swap: 507.96 MiB / 512.00 MiB (99%)
     `$$b.                      Disk (/): 43.68 GiB / 97.87 GiB (45%) - ext4
       `Y$$b.                  Local IP (eth0): 192.168.10.163/24
         `"Y$b._               Locale: en_US.UTF-8

docker version
Client: Docker Engine - Community
 Version:           29.1.5
 API version:       1.52
 Go version:        go1.25.6
 Git commit:        0e6fee6
 Built:             Fri Jan 16 12:48:42 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.1.5
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       3b01d64
  Built:            Fri Jan 16 12:48:42 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Can you try it again? Docker pull

[boostedgti916]

Same issue for me. On Ubuntu server 24.

[Daellhin]

It seems like the frontend is hardcoded to use a backend on port 3001, so I suspect that changing the backend port to something else then 3001 breaks this.

https://github.com/clucraft/PriceGhost/blob/main/frontend/vite.config.js

[clucraft]

It seems like the frontend is hardcoded to use a backend on port 3001, so I suspect that changing the backend port to something else then 3001 breaks this.

https://github.com/clucraft/PriceGhost/blob/main/frontend/vite.config.js

I'm running it on port 3001 in the docker side, but 3003 is natted to my network.

  PORT: 3001
  NODE_ENV: production
ports:
  - "3003:3001"

[rodrigosiviero]

same here:

Starting scheduled price check...
Connected to PostgreSQL database
Found 0 products to check
Scheduled price check complete
[Voting] JSON-LD found 0 candidates
[Voting] Site-specific found 0 candidates
[Voting] Generic CSS found 0 candidates
[Voting] No candidates in static HTML, trying browser...
[Voting] Browser fallback failed: Error: Failed to launch the browser process!
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help' for more information.
[226:226:0228/213113.405808:ERROR:third_party/crashpad/crashpad/util/linux/socket.cc:120] recvmsg: Connection reset by peer (104)
TROUBLESHOOTING: https://pptr.dev/troubleshooting
    at Interface.onClose (/app/node_modules/@puppeteer/browsers/lib/cjs/launch.js:310:24)
    at Interface.emit (node:events:536:35)
    at Interface.close (node:internal/readline/interface:530:10)
    at Socket.onend (node:internal/readline/interface:256:10)
    at Socket.emit (node:events:536:35)
    at endReadableNT (node:internal/streams/readable:1698:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
[Voting] Consensus: false, Groups: 0, Winner: undefined
[Voting] No candidates found, trying AI extraction...
Connected to PostgreSQL database```

[tonyfruzza]

I've opened PR #37 which addresses this by adding support for a remote browser via the Chrome DevTools Protocol (CDP). Instead of spawning a local Chromium process inside the container (which fails in Docker without special privileges/seccomp profiles), the scraper connects to an external browser using puppeteer.connect().

To use it today, run any Chrome/Chromium with remote debugging enabled and point the backend at it:

# Example: run chromium on the Docker host
chromium --headless --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --no-sandbox

Then set the REMOTE_BROWSER_URL env var on your backend container:

environment:
  - REMOTE_BROWSER_URL=http://<host-ip>:9222

The scraper falls back to local Puppeteer launch if the remote browser isn't reachable, so there's no breaking change for setups where Puppeteer works today. Walmart, Target, Costco, and Best Buy have all been tested and extract correctly via the remote browser path.

[tonyfruzza]

Update: I've closed the PR for now after reconsidering the scope of the change.

While the remote CDP approach works well in practice, it's a non-trivial architectural shift:

• It introduces a hard external dependency on a separately-managed browser service, which changes the deployment model from a self-contained Docker Compose setup to one requiring an additional sidecar or networked container
• It requires the backend to handle two fundamentally different browser acquisition paths (remote connect vs. local launch), adding branching logic throughout the scraper
• The REMOTE_BROWSER_URL default points to a Kubernetes-specific service name, which is meaningless in a standard Docker Compose deployment and would need documentation and a sensible default for both environments
• Users would need to manage the lifecycle of the remote browser independently (crashes, restarts, security exposure of the debugging port on 0.0.0.0)

A less invasive path that might be worth exploring upstream: running Chromium as a sidecar in the same Docker Compose service, with the backend connecting to localhost:9222. This keeps the deployment self-contained while still avoiding the puppeteer.launch() privilege issues. The Browserless and zenika/alpine-chrome projects both offer ready-made images for this pattern.

For anyone hitting this today, the workaround in my previous comment still applies if you're comfortable running a separate browser container.

[twripley]

Claude fixed this issue for me.

--disable-crash-reporter isn't a real Chromium flag. The actual switch is --disable-breakpad (that's the literal name Chromium uses internally for its crash-reporting flag — I checked it against Chromium's source). Unrecognized flags like --disable-crash-reporter are just silently ignored by Chromium, so that "fix" is effectively a no-op — which is exactly consistent with you still hitting the identical chrome_crashpad_handler: --database is required crash even on the patched build.

Why it's happening at all: Crashpad needs a writable directory to create its crash database (usually derived from $HOME/$XDG_CONFIG_HOME/$XDG_CACHE_HOME). In the container, that path is either unset or unwritable for the user running Chromium, so the crash handler itself fails to start — and Puppeteer treats that as a fatal launch failure.

So the fix is to give the backend an XDG config and cache home dir:

services:
  backend:
    environment:
      - HOME=/tmp
      - XDG_CONFIG_HOME=/tmp/.chromium
      - XDG_CACHE_HOME=/tmp/.chromium

Once I added those and recreated the backend I was able to get prices again.