Engineering service
Chromium and Firefox Fork Maintenance and Version Porting
Chromium now moves to a new major version every two weeks, and Firefox every four. We rebase your patch series onto each release, fix conflicts, internal API changes and build breaks, and confirm every upstream security fix is in your build. For GTX Browser, we carried the fork's patches from Chromium 98 to 114, across sixteen major releases.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
A browser fork stays maintainable when your changes live as a small, reviewable patch series that is rebased onto each upstream release. Since Chrome 153 on 8 September 2026, Chrome and Chromium move to a new major version every two weeks, with security fixes in between. Firefox ships a new major version every four weeks.
For fork owners, the two-week cycle means twice as many rebases, each with less upstream change. A team that cannot keep that pace can track Chrome's Extended Stable channel, which moves to a new milestone every 8 weeks, or Firefox ESR. Either way, the further behind a fork falls, the more change each patch has to survive and the more known security fixes stay unapplied. We do this work as a one-off catch-up or release by release.
Who this is for
- Teams that ship a Chromium or Firefox fork and need it to keep pace with upstream releases.
- Products whose fork has fallen several major versions behind and carries unapplied security fixes.
- Companies that lost the engineer who did the last upgrade and need the process rebuilt.
- Teams deciding whether to follow every two-week Chrome release or track Extended Stable.
How it works
One upstream release, step by step
The technical cycle for a single upstream release. It repeats for every release a fork needs to follow.
Track the upstream release
Watch upstream release channels and read the changes that touch areas your patches modify.
You get: A list of upstream changes that affect your fork
Rebase the patch series
Apply your patches, in order, onto the new upstream tag.
You get: A rebased branch and a list of failing patches
Resolve conflicts
Fix each conflict in the patch that caused it, so the series stays small and readable.
You get: A clean patch series on the new base
Port features and internal APIs
Adapt code that depends on internal APIs, flags or UI that upstream changed or removed.
You get: Your features working on the new version
Build and test on every platform
Build for each target platform and run your tests and a manual check of the changed areas.
You get: Build results and a test report per platform
Security review and release
Confirm upstream security fixes are present and did not collide with your patches, then release.
You get: A release candidate with a change summary
What we offer
What's included
Patch series rebasing
Reapply your patch series onto each new upstream tag and resolve conflicts patch by patch, so the series stays small and reviewable.
Internal API migration
Update the call sites in your patches when Chromium or Gecko renames, moves or removes the internal APIs they depend on.
Patch series documentation
Record what each patch does and why, so a rebase does not depend on one engineer's memory of the codebase.
Build system updates
Update GN arguments, toolchain versions and dependency pins when upstream changes its build requirements.
Security fix verification
Confirm each upstream security fix is present in your fork and was not dropped during a rebase.
Multi-platform build validation
Build for every platform you target and check the areas your patches touch before a release candidate ships.
Deliverables
What you get
- 01
Rebased patch series
Your changes applied on the target upstream version as a reviewable series of patches.
- 02
Working builds
Builds for each platform you target, produced by your build system or ours.
- 03
Fork audit
A written inventory of your patches, build configuration and how far the fork is from upstream.
- 04
Catch-up plan
The order of versions to port through and the risks we expect at each step, when a fork is far behind.
- 05
Upgrade notes
A record of what changed, what broke and how it was fixed, so the next upgrade starts from knowledge.
- 06
Rebase automation
Optional CI that attempts the rebase on each new upstream release and reports conflicts.
Compare
What breaks when you upgrade
These are the areas where fork upgrades usually need the most work, and how we approach each.
| Area | Typical breakage | How we handle it |
|---|---|---|
| Build system | Changed GN arguments, new dependencies and new toolchain requirements. | Update build configuration first, so every later problem is a code problem and not a build problem. |
| Internal APIs | Functions, classes or interfaces your patches call are renamed, moved or removed. | Port each call site to the new API and keep the change inside the original patch. |
| UI code | Refactors of browser UI move or rewrite the code your UI patches modify. | Re-apply the intent of the patch on the new structure instead of forcing the old diff to fit. |
| Features and flags | Features or flags you rely on are moved, renamed or removed upstream. | Find the replacement, or carry a minimal patch that restores the behavior you need. |
| Security fixes | Upstream security fixes touch code that your patches also modify. | Review those areas by hand and confirm the fix is intact after the rebase. |
Why it matters
What this gives you
Smaller, reviewable diffs
Rebasing release by release keeps each conflict small enough for one engineer to review, instead of one annual merge nobody wants to own.
A fork that outlives its original author
Documented patches and rebase notes mean a new engineer can pick up the fork without reverse-engineering years of changes.
Security fixes you can confirm
Verification checks that each fix landed in your code, not only that the version number moved past it.
A cadence that matches your risk tolerance
Follow every two-week Chrome release, track Chrome's Extended Stable milestones every 8 weeks, or follow Firefox ESR. The porting workflow adapts to your choice.
Our approach
How a fork upgrade runs
Audit the fork
We review your patches, your build system and how far you are from upstream.
You get: A written audit of the fork
Plan the path
We decide the catch-up path and the order of versions to port through.
You get: A plan with the risks at each step
Port
We rebase and port the patch series version by version, keeping each step reviewable.
You get: A patch series on the target version
Stabilize
We build on every platform, fix regressions and check the areas your patches touch.
You get: A release candidate you can test
Hand over or continue
You take the process in-house with our notes, or we continue with each new upstream release.
You get: Upgrade notes, or a per-release routine
When this is not the right fit
- A fork with no owner or budget to keep it current long term. Consider whether it should be a fork at all.
- A project that only needs an extension. Extensions do not require porting a browser.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
Chromium
Gecko (Firefox)GitGNSisoClang/LLVM
Rustdepot_toolsmachFAQ
Common questions
Several major versions behind usually means a planned catch-up project, not a routine rebase. The gap decides how much upstream change each patch has to survive, and we size the work after auditing the fork. For GTX Browser, the catch-up ran from Chromium 98 to 114.
Since Chrome 153 (8 September 2026), a new Chromium major version arrives every two weeks instead of every four. Each rebase is smaller, but there are twice as many. You can follow every release, which keeps you closest to upstream, or track Chrome's Extended Stable milestones every 8 weeks and pick up its security updates in between. We help you choose and set up the routine and automation for it.
Ideally yes, because a series makes the work faster and easier to review. If your changes are scattered through the codebase, the first step is extracting them into a clean series.
Partly. We can set up CI that attempts the rebase on each new upstream release and reports conflicts, so people spend time on the conflicts instead of on the mechanics.
Both. A catch-up is a project with milestones, scoped after we audit the fork. Ongoing porting is a retainer: we handle each upstream release as it ships, on the cadence you choose.
Our services
Related services
Start a project
Get your fork back on a supported version
Tell us your fork, how far behind it is and which platforms you ship. We will audit it and propose a catch-up plan or an ongoing release routine.
