One Month of Galileo: From a Fork to a Browser Taking Shape

August 2026

A month ago, Galileo was mostly a direction.

We knew what we wanted to explore: whether a small team, working openly and using modern AI-assisted engineering methods, could take an existing browser-engine foundation and move it toward a complete desktop browser at a much faster pace.

Today, Galileo is still early. It is not a finished browser. It is not ready to replace anyone’s daily browser, and there is no public release yet.

But it is no longer just an idea either.

In one month, the project has moved from an engine fork to a growing browser platform with real product surfaces, measurable tests, working media paths, profiles, private browsing, content blocking, extension infrastructure, developer tooling and an increasingly clear path toward a first public pre-alpha.

This is what the first month looked like.

Starting on Servo’s shoulders

Galileo did not start by building a browser engine from zero.

The engine fork began on July 26, 2026, from Servo — the Rust browser engine originally started by Mozilla Research and today carried forward by the open-source community and the Linux Foundation.

That distinction matters.

Servo provides an enormous amount of engineering that Galileo inherits: rendering, layout, web-platform implementation and the architecture required to embed the engine into a browser.

Our work begins on top of that foundation.

The goal of Galileo Engine is to accelerate the connection between that engine and the larger set of systems required to turn an engine into an actual browser product.

That means browser chrome, tabs, navigation, profiles, private browsing, history, bookmarks, downloads, settings, media, extensions, permissions, recovery and eventually the security and release infrastructure required for people to trust it.

We want to move quickly, but we also want to be precise about where the work comes from.

The foundation is Servo.

The acceleration and product integration are Galileo.

From an engine to a browser

One of the biggest lessons from the first month is that rendering a webpage and building a browser are very different problems.

A browser is not simply a window around a rendering engine.

It is a system composed of many interconnected parts.

During this first development period, Galileo has already started building or integrating many of those surfaces.

The current engineering inventory tracks 68 functional areas. In the latest reviewed snapshot, 54 had some observable implementation or behaviour.

That does not mean 54 features are finished.

We deliberately classify them as observed partial until focused tests can demonstrate that they behave correctly.

Among the areas already taking shape are the desktop browser shell, profiles and private browsing, native content blocking, WebExtensions infrastructure, media support and developer tools.

Tabs, navigation, history, bookmarks, downloads, settings and session recovery also exist at different stages of development.

The shell is becoming a product.

But there is still a significant difference between something existing in the repository and something being ready for users.

The first measurable milestones

We do not want Galileo’s progress to be measured only by screenshots or feature lists.

Testing started early.

On August 1, the official Cloudflare Turnstile canary was working across its three test modes: always-pass, always-fail and forced-interactive.

This was important because modern websites are not just HTML and CSS. Browsers have to survive increasingly complex JavaScript, security mechanisms, network behaviour and real-world web applications.

Media became another major target.

Media Source Extensions were part of the work from the beginning, and by August 14 the project had retained evidence for unattended YouTube playback, cold-start behaviour, clock stalls and replay.

There is also an intentionally small Web Platform Test reference suite.

In the retained August 13 run, Galileo passed all 286 applicable subtests across the selected three-test Phase 0 Core shard.

That number needs context.

It is not a claim that Galileo has 100% web compatibility.

Three WPT tests cannot represent the web.

Instead, this small suite gives us a reproducible baseline that can be retained, compared and expanded as the browser evolves.

That distinction is part of how we want Galileo to operate: measure what we can prove and clearly label everything else.

Extensions are becoming part of the architecture

Extensions are not being treated as something to bolt onto Galileo after the browser is finished.

They are part of the browser architecture.

Work already exists around Manifest V2 and Manifest V3 entrypoints, permission review, content scripts, storage and request blocking.

The longer-term goal is broader compatibility with extension APIs familiar to Chrome and Firefox users, while maintaining a clear security boundary around what extensions are allowed to do.

We also want Galileo to have its own extension format for capabilities that make more sense when designed directly for the browser rather than inherited from another ecosystem.

One particularly important target is uBlock Origin.

It is a target, not a compatibility claim.

We will only call it supported when the actual extension and the browser services it depends on — background execution, content scripts, storage, tabs, navigation, menus and blocking — work together under real tests.

For Galileo, ad blocking and user control are browser capabilities, not afterthoughts.

Privacy should start with architecture

The same principle applies to user data.

The current direction for Galileo is local first.

Using a browser should not require creating an account with the company that built it.

Profiles are designed to live on the user’s own machine.

Work has also started around protected profile vaults and encrypted device-to-device synchronization.

The vault contract already exists and has tests around its behaviour, while production encryption of profile data remains further work.

For synchronization, the envelope format and conflict-handling rules exist, while the transport itself is still being developed.

The intention is straightforward: your browser data should belong to your devices, not become the foundation of another cloud account.

There is still engineering to do before that promise can become a production guarantee, but the architectural direction is being established now rather than retrofitted later.

What we are not calling finished

Perhaps the most important part of the first month is understanding how much remains open.

Broad web compatibility has not been qualified.

Process isolation and the complete browser security model have not been qualified.

Startup performance, page-load performance and memory consumption do not yet have published baselines.

Cross-platform packaging is not complete.

Signed updates, release recovery, accessibility qualification and a sustainable security-response process remain release gates.

There is a bounded Linux engineering packaging path, but it is intended for controlled testing. It is not a public browser distribution.

This is why Galileo Browser currently has no public release.

A browser can appear functional long before it is safe enough to recommend.

We would rather show that boundary than hide it.

AI-assisted engineering without pretending AI replaces engineering

Galileo is also an experiment in how software can be developed.

AI-assisted engineering is part of the development process.

The interesting question is not whether AI can generate code.

It can.

The harder question is whether a small team can use these systems to understand a large existing codebase, accelerate implementation, build tests, investigate failures and connect complex subsystems while still maintaining engineering discipline.

That means generated code cannot simply be accepted because it compiles.

It still has to be understood.

It has to be tested.

Security assumptions have to be challenged.

Failures need evidence.

And when work is useful to Servo itself, our intention is to offer appropriate fixes upstream while clearly marking AI-assisted contributions and respecting Servo’s own contribution and review rules.

Speed without verification would make Galileo less interesting, not more.

What comes next

The next objective is not version 1.0.

It is a usable public pre-alpha.

Before that can happen, several gates need to move forward together: compatibility, security, packaging, updates and reproducible testing.

At the same time, the browser shell will continue to mature, extension support will be expanded, media and real-site compatibility will be tested more aggressively, and the separation between inherited Servo architecture and Galileo-owned browser services will become clearer.

Eventually, that boundary may become large enough for Galileo Engine to develop into a more independent engine of its own.

But independence is not something we need to pretend already exists.

It has to be earned through engineering.

Month one

A month is not enough time to build a production browser.

It is enough time to discover whether an idea deserves another month.

Galileo started as a question: how quickly can a small team move a serious browser project forward when an established open-source engine, modern tooling and AI-assisted engineering are combined?

We do not have the final answer yet.

But after the first month, we have something much more useful than a prediction.

We have code.

We have failures.

We have tests.

We have working pieces.

We have open problems.

And we have a browser beginning to take shape.

Month one is complete.

The experiment continues.