Issue Summary
We're hitting browser launch failures with Puppeteer under moderate PDF generation load on a Railway Metal service (8 GB RAM, 8 vCPUs). Happens sporadically when multiple jobs are triggered close together.

Environment

• Plan: Railway Metal

• Specs: 8 GB RAM, 8 vCPUs

• Use case: PDF generation from HTML via Puppeteer

• Tech stack: Node.js, Express, Puppeteer

• Concurrency control: p-queue with concurrency set to 2

Relevant Code Snippet

// Shared browser instance
let browserInstance;

async function getBrowser() {
  if (!browserInstance) {
    browserInstance = await puppeteer.launch({
      headless: true,
      args: ['--no-sandbox', '--disable-setuid-sandbox'],
      timeout: 60000,
    });
  }
  return browserInstance;
}

// Queue with limited concurrency
const queue = new PQueue({ concurrency: 2 });

export function createDynamicPDF(text) {
  return queue.add(() => generatePDF(text));
}

queue.on('idle', async () => {
  if (browserInstance && queue.size === 0 && queue.pending === 0) {
    await browserInstance.close();
    browserInstance = null;
  }
});

Each incoming request sends HTML, and the server generates and streams back a PDF.

Errors Observed

• Error: Failed to launch the browser process!

• pthread_create: Resource temporarily unavailable

• Failed to connect to the bus: No such file or directory

• read ECONNRESET from WebSocket

What We Suspect

• Thread or file descriptor limit being hit in the Metal environment

• Chromium's internal parallelism possibly triggering container limits, even with conservative concurrency

What We’re Looking For

• Any known resource/thread limits on Railway Metal that may affect Puppeteer/Chromium?

• Any recommended flags or configs to make Puppeteer more stable in a constrained or containerized environment?