How to Run Playwright on Google Cloud Compute Engine

To run Playwright on Google Cloud Compute Engine, create a Linux VM, connect to it, install your project’s runtime and locked dependencies, install the browser and Linux libraries required by the project’s Playwright version, then run tests headlessly. Playwright tests run headlessly by default, so routine runs do not need a desktop. Begin with one worker, measure CPU, memory, runtime, and failures, then adjust the VM and concurrency for your workload.

This guide uses a Node.js project with npm and Chromium for its runnable example. Adapt the runtime, package manager, browser selection, and commands to your repository. Google Cloud supports creating instances in the console or with gcloud; machine types, pricing, and availability depend on region and configuration. Google Cloud’s instance creation guide covers both approaches.

1. Choose a VM and access method

Choose a Linux image supported by your organization and project, a region and zone that meet your latency, availability, and pricing needs, and a machine type based on measured workload. There is no universal Playwright machine size: resource use changes with the number of tests, workers, simultaneous browser processes, browser engines, and the pages under test.

Google describes E2 as a cost-optimized general-purpose family. E2 shared-core machine types time-share physical CPU, so they are not an automatic fit for parallel browser testing. N4 includes standard, high-CPU, and high-memory shapes with different memory per vCPU. These are machine-family specifications, not Playwright performance results. Compare available options in your chosen zone and check current pricing before committing. See Google Cloud’s general-purpose machine-family documentation.

Decision	What to consider
CPU	How many workers and browsers run at the same time, and whether CPU contention affects test duration or failures.
Memory	Total VM memory and the combined needs of simultaneous browser processes and the rest of the test job.
Run pattern	Whether the VM stays up continuously or is started for individual jobs; include disk and other configured resources when reviewing cost.
Region and zone	Where the VM and test targets need to be, and which machine types are currently available there.

For a first run, keep Playwright at one worker and record resource use and completion time. Increase workers only when measurements show the VM has headroom and the suite remains stable. If it does not, reduce concurrency or choose a VM with more suitable CPU or memory and measure again.

Create an instance with gcloud

The following is a command template, not a guaranteed machine or image recommendation. Replace the project, zone, machine type, and image with values available and appropriate for your account. Google Cloud documents gcloud compute instances create for custom configurations.

gcloud compute instances create playwright-vm \
  --project=YOUR_PROJECT_ID \
  --zone=YOUR_ZONE \
  --machine-type=YOUR_MACHINE_TYPE \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=30GB

Alternatively, create the instance in the Google Cloud console and select its OS image, machine type, disk, region, zone, and access settings there. Follow your organization’s access policy. Avoid opening remote access broadly to the internet; use the access method approved for your environment.

2. Connect and prepare the project

Use the connection method configured for your instance. With gcloud, a typical SSH command is:

gcloud compute ssh playwright-vm --project=YOUR_PROJECT_ID --zone=YOUR_ZONE

On the VM, install a Node.js version supported by the project and its Playwright version, using your organization’s approved installation method. Then get the project source onto the VM, for example by cloning the repository, and enter its directory:

git clone YOUR_REPOSITORY_URL
cd YOUR_PROJECT_DIRECTORY

For an npm project with a committed package-lock.json, install exactly the lockfile’s dependency versions:

npm ci

Use the equivalent lockfile-preserving install for your actual package manager. If you are creating a minimal project instead of using an existing one, initialize it and install Playwright Test:

npm init -y
npm install --save-dev @playwright/test
npx playwright install --with-deps chromium

For an existing project, do not install an arbitrary latest Playwright version in place of the version in its manifest and lockfile. Install the project dependencies first, then install the browser build required by that installed version.

3. Install the matching browser and Linux dependencies

For the Node.js Chromium example, run:

npx playwright install --with-deps chromium

The --with-deps option installs the selected browser and the Linux system dependencies Playwright requires. If you need another engine, name it explicitly, such as firefox or webkit, or install all supported browser builds with npx playwright install --with-deps. Install only what the suite uses if disk and setup time matter.

Playwright’s browser guide states that “Each version of Playwright needs specific versions of browser binaries to operate.” Keep the package version and browser binaries aligned: after changing or upgrading Playwright, rerun the appropriate browser installation command. See the Playwright browser installation guide.

4. Configure and run a headless test

A minimal test file, tests/example.spec.js:

const { test, expect } = require('@playwright/test');

test('page has a title', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveTitle(/Example Domain/);
});

A conservative playwright.config.js for a VM or CI run:

const { defineConfig } = require('@playwright/test');

module.exports = defineConfig({
  testDir: './tests',
  workers: 1,
  use: {
    headless: true,
    browserName: 'chromium',
    trace: 'on-first-retry',
  },
  retries: 1,
});

Run the suite with:

npx playwright test

Playwright Test is headless by default, and explicitly setting headless: true makes the intent clear. The Playwright CI guide recommends workers: 1 in CI as a stability baseline; it also notes that wider parallelization can suit powerful self-hosted systems. Treat one worker as a starting point, then raise it only after observing the workload. Read the Playwright CI guide.

Run a headed browser for debugging

Routine remote test runs do not need a graphical desktop. If you need a headed browser on Linux, install Xvfb using the package manager for the VM image, then run the test under a virtual display:

xvfb-run npx playwright test --headed

Use this for debugging situations that require a visible browser window. For ordinary unattended test runs, headless mode avoids that extra display setup.

5. Keep runs repeatable

• Commit the dependency lockfile and use its frozen install command, such as npm ci.
• Keep the Playwright package version stable for each run, and reinstall the matching browser after changing that version.
• Start with one worker; change concurrency based on observed resource use and failure rate.
• Keep test configuration and required environment variables explicit so local and VM runs use the same inputs.
• Capture Playwright traces on retry when useful for diagnosing intermittent failures; protect traces and other artifacts according to your project’s data handling requirements.
• For recurring jobs, use the organization’s CI or job orchestration approach to start, run, collect results from, and stop or retain the VM according to the workload.

Or skip the browser setup

If the task is to capture a page rather than run browser automation tests, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Its clean-shot flow accepts cookie or consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers. The MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

See the ScreenshotNeo API documentation for request options. One thousand screenshots a month are free with no card; paid plans start at $5 for 3,000. Sign up for free and get 1,000 screenshots a month with no card.

Troubleshooting

Symptom	Likely cause	What to do
Browser executable is missing	The browser build for the installed Playwright version has not been installed, or the package version changed after installation.	From the project directory, run npx playwright install chromium (or the browser your project uses). After upgrading Playwright, reinstall its browser build.
Browser fails to launch with missing shared libraries	Linux system dependencies are absent or incomplete.	Run npx playwright install --with-deps chromium on a supported Linux image. Review the browser guide if installation fails for that image.
Headed launch reports no display	A remote Linux VM has no graphical display server.	Run headless, or install and invoke Xvfb with xvfb-run npx playwright test --headed.
Tests pass locally but fail on the VM	The runtime, dependency versions, browser build, environment variables, network access, or test inputs differ.	Use the repository lockfile, the same Playwright version, and the browser install command for that version. Compare environment and network assumptions.
Tests become unstable as workers increase	Concurrent browser processes may be competing for CPU or memory.	Return to one worker, observe resource use and results, then increase workers gradually or resize the VM based on measurements.
Browser launch hangs or exits unexpectedly	Launch configuration, missing dependencies, or resource pressure may be involved.	Check version alignment and dependencies first. Enable browser launch diagnostics with DEBUG=pw:browser, then inspect the resulting logs.

Performance, reliability, and cost

Concurrency is the main tuning control to approach carefully: more workers can run more browser work at once, but they also increase simultaneous resource demand. There is no dossier-supported benchmark or universal minimum VM size for Playwright. Record duration, CPU, memory, and failure rate for your own suite before choosing a larger machine or adding workers.

For reliability, pin dependencies, keep browser binaries aligned with Playwright, and use the same setup steps in repeat runs. A successful VM creation does not guarantee every machine type is available in every zone; check current zone availability. Cost depends on the selected resources, region, and how long the instance and its configured resources are used. Consult current Google Cloud pricing for your configuration rather than relying on a generic estimate.

FAQ

Does a Compute Engine VM need a desktop to run Playwright?

No. Playwright tests run headlessly by default. A headed Linux run needs a display such as Xvfb.

Should I install every browser engine?

Only install engines the project’s tests require. Install the matching browser build again when the Playwright version changes.

Can I run this guide with Python?

The provisioning and Linux setup apply, but the runnable project commands here use Node.js and npm. Follow the Python Playwright project’s own dependency and browser installation instructions when its language binding is in use.

What VM size should I start with?

The research does not establish a universal size. Choose an available type based on expected workers and browser processes, then measure your suite’s CPU, memory, runtime, and failures.