Engineering service
Chromium & Firefox Version Porting & Maintenance
Building a browser is only the beginning. Keeping it current is the real long-term engineering challenge. We rebase your patch series onto each Chromium or Firefox release, resolve the conflicts and internal API changes, fix the build, and ship, so your fork stays secure instead of falling behind.
- 15+ years of experience
- 300+ projects delivered
- Clients worldwide
- NDA available
Overview
What this is, and when it is the right call
A browser fork stays maintainable when your changes live as a small, reviewable patch series that is rebased onto each upstream release. Chromium ships new major versions on a regular schedule, with security fixes released in between, so a fork that stops rebasing starts accumulating risk.
The further behind a fork is, the more upstream change each patch has to survive, and the more known security fixes remain unapplied. We do this work for Chromium and Firefox forks, either as a one-off catch-up or as an ongoing release-by-release service.
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 that want upstream rebases attempted automatically on every release, with conflicts reported.
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 we engineer: Chromium & Firefox Version Porting & Maintenance
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 Backport Verification
Confirm each upstream security fix is present in your fork and was not silently 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 real 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 Actually Confirm
Backport verification checks that a fix landed in your code, not just that the version number moved past it.
A Cadence That Matches Your Risk Tolerance
Chase every upstream release or track an LTS branch — the porting workflow adapts to the choice instead of forcing it.
Our approach
How an engagement 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 few cases where this approach may not be the best choice for you.
- 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, so this is not needed.
Tech stack
Technologies we use
The engines, APIs and tools behind our chromium & firefox version porting & maintenance work.
Chromium
Gecko (Firefox)GitGNNinjaClang/LLVM
Rustdepot_toolsFAQ
Questions engineers ask before starting
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.
Our services
Related services
Explore more services that work alongside this one.
Talk to a Browser Engineer
Trust Us to Maintain Your Browser After Launch
Tell us your fork, patch workflow and target platforms. We will take over or share upstream migration on a cadence that fits your risk.
