Chromium browser architecture,the way engineers actually need it.
Chromium browser architecture means understanding what's actually inside a 35-million-line browser engine — the GN build system, the Mojo IPC layer connecting browser processes, Blink's rendering pipeline, and the sandboxing model that keeps it secure. This is what forking Chromium or Brave actually touches, and what it takes to keep that fork alive past the first upstream merge.
- GN build system
- Mojo IPC
- Blink rendering
- Upstream rebase
Why Entalogics for Chromium
Four things Chromium
browser development
project actually needs.
Thirty-five million lines of code. Most teams that fork Chromium can't keep that fork rebased past two upstream releases before it collapses under merge conflicts. The hard part was never the first modification — it's the merge strategy that keeps the fork alive a year later.
Strip what you don't need before you add anything.
A default Chromium build ships sync, translate, and a dozen services most custom browsers never touch. We strip unused components at the GN flag level first — smaller binary, less memory, faster cold start — before a single custom feature goes in.
Not every customization needs a source fork.
CEF for embedding a browser inside a desktop app. WebView2 for Windows-native embedding. The Extensions API for surface-level changes. A full Chromium or Brave fork only when the problem genuinely lives at the engine level — we pick the lightest layer that solves it.
An unrebased fork is a fork that's already dying.
Every patch we write is isolated and documented against a specific upstream milestone. When Chrome ships a security fix, a fork built this way absorbs it in days. A fork built as one giant diff absorbs nothing — it just falls further behind until someone declares it unmaintainable.
Chromium's C++ has its own rules, and fighting them is how forks break.
Mojo IPC for inter-process communication, `base::` types where Chromium expects them, `raw_ptr` and `base::SafeRef` for memory safety. Code that follows Chromium's internal conventions survives the next upstream merge. Code that doesn't gets rewritten every milestone.
When Chromium, when not
Chromium is a platform.
Not a quick modification.
Forking Chromium is the easy part. Maintaining that fork against an engine that ships a new milestone every four weeks is where almost every team underestimates the real cost. We'll tell you honestly on the first call whether a source fork is worth that commitment.
FORK CHROMIUM OR BRAVE WHEN
- The browser itself is the product — kiosk browsers, enterprise browsers, vertical-specific browsers, crypto-native browsers
- Engine-level security controls are required — no dev tools, no URL bar, policy-enforced restrictions extensions can't reach
- A crypto wallet, custom rendering pipeline, or protocol handling needs to live inside the browser itself, not bolted on as an extension
- Embedded browser hardware — industrial, medical, or automotive — where a full Chrome install isn't an option
USE CEF OR WEBVIEW2 WHEN
- You need a browser component embedded inside an existing desktop application
- Standard web rendering is enough and the pages themselves don't need to render differently
- The customization you need already lives inside CEF or WebView2's API surface
WE SAY NO WHEN
- "Fork Chromium to change the default search engine" — that's an extension, and you don't need a fork for it
- "We need a custom browser in three weeks" — a Chromium build alone takes longer than that
- "Fork it and we'll maintain it in-house" — most teams won't, and upstream doesn't wait
Under the hood
The subsystems
Chromium work actually touches.
Six layers of the engine, and what changes at each one when you fork or embed Chromium.
- S01
The build system: what gets compiled, and what gets stripped.
The build system: what gets compiled, and what gets stripped.GN flags control which components ship in the binary — sync, translate, safe browsing, the extension system. Stripping unused components here, before any custom feature goes in, is what keeps binary size and attack surface under control.
GNNINJADEPOT_TOOLSBUILD FLAGS - S02
Inter-process communication: how browser, renderer, and GPU processes talk.
Inter-process communication: how browser, renderer, and GPU processes talk.Chromium's multi-process architecture isolates tabs, plugins, and the browser shell from each other. Mojo IPC is the interface layer connecting them — new browser services get wired through it the same way Chrome's own services are, so they survive the next upstream merge instead of snapping on it.
MOJOIPCMULTI-PROCESSSANDBOX - S03
Blink: the engine that turns HTML and CSS into pixels.
Blink: the engine that turns HTML and CSS into pixels.Custom rendering behavior, modified layout logic, or engine-level display changes live inside Blink, not in a content script. This is the layer that separates a genuine fork from a themed extension.
BLINKRENDERINGLAYOUTV8 - S04
The sandbox model that keeps a compromised tab from becoming a compromised system.
The sandbox model that keeps a compromised tab from becoming a compromised system.Site isolation, process-per-origin sandboxing, and Chromium's permission model are what make a browser safe to fork in the first place — and what a custom enterprise policy engine has to work inside, not around.
SANDBOXSITE ISOLATIONPERMISSIONSCVE PATCHING - S05
Where API-level embedding ends and a source fork begins.
Where API-level embedding ends and a source fork begins.CEF and WebView2 expose a browser component without engine-level access. The Extensions API reaches further but still stops at the surface. Knowing exactly where each one's ceiling is keeps a project from forking Chromium when it never needed to.
CEFWEBVIEW2EXTENSIONS APIEMBEDDING - S06
How a fork survives Chromium shipping a new milestone every four weeks.
How a fork survives Chromium shipping a new milestone every four weeks.Isolated, documented patches rebased against a specific upstream commit — not one giant diff — is the difference between a fork that absorbs a security fix in days and one that's unmaintainable within two releases.
GIT REBASEPATCH SETSCIMILESTONE SYNC
The playbook
Chromium development
patterns we ship on repeat.
Patterns from maintained production forks — not one-off builds that quietly rot after launch.
P01
Isolated patch sets.
Every modification is its own documented patch against a specific upstream commit. Rebasing on a new milestone stays clean instead of turning into a monolithic diff nobody can merge.
P02
GN flag stripping first.
Sync, translate, safe browsing, the extension system — disabled at the build system level before they add binary size and attack surface nobody asked for.
P03
Enterprise policy engine over custom preferences.
Chrome's own policy infrastructure handles URL allowlists, download restrictions, proxy configuration, and authentication enforcement — policy, not a settings file that breaks on update.
P04
Mojo IPC for anything new.
New browser services wired through the same IPC layer Chrome's own services use. No bolted-on communication path that snaps on the next upstream merge.
P05
CI against every upstream milestone.
Automated builds and tests trigger the moment a new Chromium milestone ships. Merge conflicts get caught in CI, not three months later when a security patch is already overdue.
P06
Security patches within 72 hours.
Upstream fixes land in the fork within three days of Chromium's stable release. The fork never drifts more than one milestone behind while CVEs pile up.
Signature case
A privacy browser,
rebuilt from a stale fork to upstream-current.
An enterprise privacy browser forked from Chromium 108 — 14 milestones behind upstream, 340+ merge conflicts blocking the rebase, integrated VPN that broke on every update, and three known Chromium CVEs unfixed. Rebased to Chromium 128, restructured all patches as isolated changesets, and established a milestone-per-sprint merge workflow in 10 weeks. CVEs resolved. VPN integration stable. Fork maintainable going forward.
Before
Chromium 108 · 14 milestones behind · 340+ conflicts · 3 unpatched CVEs · VPN broken on update
After
Chromium 128 · current milestone · isolated patches · 0 CVEs · VPN stable across updates
- Milestones behind14 → 0
- Unpatched CVEs3 → 0
- To fully rebased10wk
- Merge workflowrepeatable
How it evolves
How a Chromium fork
moves from stale to upstream-current.
The technical lifecycle of a rebase, milestone by milestone. The current product keeps shipping on the existing fork while the new one catches up.
- W01
Audit + RFC
Fork delta analysis, patch inventory, build system audit, upstream gap assessment. A ranked plan with real numbers, not a list of vague concerns.
- W02–03
Foundation + first rebase
Build system configured, GN flags stripped, first milestone rebase completed, CI running against upstream. A real build on your target platforms.
- W04–08
Milestone by milestone
Patches rebased, features integrated, tests passing on each release. Your product keeps shipping on the current fork the entire time.
- W09+
Release + handoff
Production build on current upstream milestone. Merge workflow documented. Runbook handed over, or we stay on for Chromium fork maintenance.
Stack
Tools we
Tools we reach
reach for for first.
Our default Chromium development stack — picked for real fork maintenance.
Questions we get on almost
every Chromium call.
Fork vs CEF, upstream sync, timelines, cost — in roughly the order people ask.Founder-direct
Tell us whatyou're building.
Thirty minutes with the founder — a senior Chromium engineer, the relevant playbook, and a candid read on whether a source fork is worth it, or CEF, WebView2, or an extension solves it for a fraction of the cost.