I Built Chromium in the Cloud in 2 Hours for $2 — What If Google Made This a One-Click Setup?

How It Started

I was using Chrome one day and noticed something that looked like a UI bug in the bookmarks side panel, a small visual inconsistency after moving a bookmark. As a developer, my first instinct was to look at the source and see if I could fix it.

I found the relevant code, understood the likely cause, and thought: "This is probably a one-line fix." Then I looked at what it takes to actually build and test a Chromium change.

100+ GB of disk space. Hours of build time. Dozens of dependencies. On my machine, that wasn't realistic.

I could have stopped there. Most people do. But then I thought: what if I ran the build in the cloud? And more importantly, what if someone turned that into a reusable image so that no contributor ever has to go through the full setup again?

Even if the bug turned out to be harder to reproduce than I expected, the idea felt worth proving. So I did.

A Great Codebase With a Heavy Front Door

Even though I mentioned the effort needed to contribute to Chromium informally above, I want to make it more concrete.

To be clear, Chromium is one of the most well-documented open-source projects out there. The build instructions are thorough, the code review process is solid, and the community is welcoming. None of that is the problem.

The problem is purely mechanical. Here's what the official docs require just to get started:

• 
  35–40 GB source checkout (fetch chromium)


• 
  100+ GB total disk space (source + build output + dependencies)


• 
  16+ GB RAM recommended (build will thrash or fail with less)


• 
  Full build: 2–8 hours depending on hardware (on a laptop, expect the upper end)


• 
  Dozens of system packages to install, some with version-specific requirements

For a full-time Chromium engineer, this is a one-time cost that pays for itself. But for students, open-source enthusiasts, or anyone who just wants to fix one small thing and move on, this is usually where the journey ends.

I wanted to see if a Google Cloud image could make this a non-issue.

The Idea: What If the Build Was Already Done?

Google Cloud has a feature called Custom Images. Essentially, a snapshot of a fully configured VM that you can launch new machines from. Think AWS AMI if you're familiar with that world.

What if someone built Chromium once, saved it as an image, and every future contributor could just launch a VM with everything ready?

I decided to test this end-to-end. Not as a thought experiment. Actually do it, measure everything, and see if it's practical.

The Experiment

Step 1: One Script, Walk Away

I wrote a startup script that does everything automatically:

• Creates a user


• Installs all dependencies


• Clones depot_tools


• Fetches the Chromium source


• Runs a full build

I launched a Spot VM (cheaper, ~60-70% discount) on Google Cloud and walked away.

gcloud compute instances create chromium-builder \

  --machine-type=n2-standard-32 \

  --provisioning-model=SPOT \

  --boot-disk-size=200GB \

  --boot-disk-type=pd-ssd \

  --metadata-from-file=startup-script=startup-script.sh

Step 2: Check Back Later

I checked the build progress periodically:

Step 3: Make a Change, Rebuild

Here's where it gets interesting. I made a small change to a UI component to see how fast it would rebuild.

Thanks to Chromium's incremental build system, the rebuild took just 11 seconds.

The full build took 2 hours, but every change after that rebuilds in seconds. And that's exactly the experience a contributor would get when starting from a pre-built image.

Step 4: Save the Image

gcloud compute instances stop chromium-builder

gcloud compute images create chromium-workstation-v1 \

  --source-disk=chromium-builder \

  --family=chromium-contributor-workstation

Now, anyone can launch a VM from this image and start coding within minutes.

Step 5: Clean Up

gcloud compute instances delete chromium-builder

VM gone. Only the image remains (~$3-5/month storage). Zero ongoing compute cost.

The Numbers

What I Measured

How It Scales (Hopefully)

For the one-time image build, go big. For contributor sessions with incremental builds, smaller machines work just fine.

What If This Were Official?

Imagine if the Chromium project published an official Google Cloud image. The contributing guide could include something like:

gcloud compute instances create my-chromium-dev \

  --image-family=chromium-contributor-workstation \

  --image-project=chromium-contributor-images \

  --machine-type=n2-standard-8

One command. VM boots in 2 minutes. Source and build are ready. Start coding.

Why this makes sense:

• Nothing changes about how code gets reviewed or merged. The image only changes how contributors set up their environment.


• No security concern. The image would contain only public source code and open-source tools. No credentials, no internal code, nothing proprietary.


• It doesn't slow down any existing Chromium workflows. Image builds can run in parallel or as a low-priority job.


• Every contributor who launches a VM becomes a Google Cloud user organically.


• Since Chromium and Google Cloud are not far apart, hosting a few contributor images might be simpler to arrange than it would be for most open-source projects.

Implementation:

1. Add image creation to an existing build bot


2. Publish to a public project


3. Add a one-liner to the contributing guide

The technology already exists. This is just connecting the pieces.

If you've tried contributing to Chromium and hit the same setup wall, or if you have thoughts on how this could work better, I'd love to hear from you.

All measurements from a real session on June 26, 2026. Machine: GCP Compute Engine n2-standard-32 Spot VM, europe-west1-b.