Engineering service

Custom Firefox browser development

We build Firefox-based browsers and managed Firefox deployments. We use enterprise policies and preferences where they are enough, patch Gecko and the Firefox UI where they are not, and keep the result current with each Firefox or ESR release.

See what's included
  • 11+ years of experience
  • 300+ projects delivered
  • Remote team, clients worldwide
  • NDA on request

Overview

What it is and when it fits

Firefox is built on the Gecko engine and the SpiderMonkey JavaScript engine, with a growing share of components written in Rust. Its source moved from Mercurial (mozilla-central) to Git on GitHub in 2025, and it is built with the mach tool. It is a different codebase from Chromium, with its own extension system and policy model.

Many Firefox customizations need no fork. Enterprise policies, preferences and autoconfig cover a lot of ground. We start there, and move to source patches only for what configuration cannot reach.

Who this is for

  • Organizations that need Firefox configured and locked down across many machines.
  • Teams building a privacy-focused or branded browser on Gecko instead of Chromium.
  • Companies that want to know whether they need a fork at all before committing to one.
  • Products that already ship a Firefox-based build and need help keeping it current.

How it works

Architecture at a glance

Anatomy of a customized Firefox

  1. Your build

    Your name and icons, default settings, search, new tab and onboarding.

  2. Configuration and patches

    Policies and preferences first; source patches only where needed.

  3. Firefox and Gecko

    Gecko engine, SpiderMonkey, the browser UI and Rust components from the release or ESR branch.

  4. Build and release

    • Windows
    • macOS
    • Linux

    mach builds, CI, installers, signing and update delivery.

  • Your productWhat your users see
  • Our engineeringWhat we build and maintain
  • UpstreamThird-party code we build on
  • Platforms and releaseBuild, sign and deliver
Configuration comes first. Source patches are added only where policies and preferences cannot do the job.

What we offer

What we build on Firefox

Firefox build pipeline

mach and mozconfig setup so your team can produce reproducible builds from the Firefox release or ESR branch on Windows, macOS and Linux.

Enterprise policies and autoconfig

Policy files and autoconfig scripts that lock settings, manage certificates and extensions, and control update behavior without touching source code.

Privacy defaults and Mozilla service calls

Telemetry, studies and sponsored content off by default, and a review of every connection the browser makes to Mozilla services.

Networking changes in Necko

Changes to Necko, Firefox's networking layer, for proxy handling, certificate behavior or request routing that policies cannot reach.

Rendering changes in Gecko

Work in Stylo, Firefox's Rust-based CSS engine, and the rest of the Gecko rendering path when behavior has to change, not only styling.

ESR tracking

Builds that follow Firefox's Extended Support Release, for organizations that want to move less often than the four-week release train.

Deliverables

What you get

  • 01

    Customization assessment

    A written breakdown of which of your requirements need a policy, an extension or a source patch.

  • 02

    Policy and preference set

    A tested policies.json and preference configuration for your deployment, including autoconfig where it applies.

  • 03

    Rebranded build

    Your own name and icons in place of Mozilla's trademarks, plus home and new-tab pages, search engines and first-run flow.

  • 04

    Source patches, if required

    A small patch series on a named Firefox version for anything configuration cannot do.

  • 05

    Build and release pipeline

    Reproducible mach builds from the Firefox release or ESR branch, with CI, packaging, signing and update delivery for the platforms you choose.

  • 06

    Upgrade runbook

    Steps for moving your build onto new Firefox releases, or onto the next ESR if that suits your needs.

Compare

Three ways to customize Firefox

These are ordered from lightest to heaviest. Most projects should stop at the first option that meets the requirement.

Three ways to customize Firefox
MethodWhat it can doEffort to maintainUse when
Enterprise policies and preferencesSet defaults, lock settings, control updates, block features, manage extensions and certificatesLowYou want a managed, configured Firefox and stock Firefox binaries are acceptable.
Extension or themeChange page behavior, add UI within extension APIs, restyle the browserLow to mediumYour feature fits the WebExtensions APIs and can be installed into existing Firefox.
Source patches (custom build)Change browser internals, engine behavior, built-in UI and default featuresHighYou need behavior that policies and extensions cannot provide, or you ship your own branded browser.

Why it matters

What this gives you

Configuration before code

Many Firefox requirements are met with policies.json and preferences, so you avoid the ongoing cost of a source patch unless you need one.

An engine independent of Google's roadmap

Gecko is the main browser engine not built on Chromium or WebKit, so your product does not depend on decisions made for Chrome.

Extensions Chrome no longer allows

Firefox still supports Manifest V2 and blocking webRequest, so ad blockers and privacy tools keep capabilities they lost in Chrome.

Longer support windows with ESR

ESR lets managed deployments take security fixes without taking new features every four weeks.

Our approach

How a Firefox project runs

  1. Assess

    We list your requirements and match each one to the lightest method that can meet it.

    You get: A method-by-requirement assessment

  2. Configure

    We build and test the policy and preference set on the Firefox release channel you choose, including ESR if a longer-supported base fits your organization.

    You get: A tested configuration

  3. Patch where needed

    For remaining gaps we write source patches, keeping each one small and documented.

    You get: A patch series on a named version

  4. Build and test

    We set up mach builds and CI, then test your features and core browsing on each platform.

    You get: Reproducible builds and test results

  5. Release and maintain

    We set up signing, packaging and updates, and document how to move to new Firefox versions.

    You get: Signed builds and an upgrade runbook

When this is not the right fit

  • A policy or an extension solves your problem. We will say so first, as it costs far less to maintain.
  • Your product needs Chromium-only features or unchanged Chrome Web Store extensions. Start from Chromium instead.

Tech stack

Technologies we use

The engines, APIs and tools we use for Firefox-based browsers.

FirefoxGeckoSpiderMonkeyRustStylomachNeckopolicies.jsonC++ESR

FAQ

Common questions

Often policies, preferences and autoconfig are enough, especially for managed deployments. A fork makes sense when you need engine or UI changes they cannot make, or you ship a separately branded browser.

Firefox and Gecko

Plan your Firefox-based browser

Tell us what your Firefox-based product has to do. We will tell you where configuration ends, where source changes begin and what it takes to maintain.

Send a project brief