What is Beaker Browser and why people still talk about it

The internet as we know it is built on client-server architecture. You type an address, the browser goes to a server somewhere in an AWS or Cloudflare data center, fetches the HTML, and renders the page. If the server goes down, the site is gone. In 2016, a small team at Blue Link Labs led by Paul Frazee proposed an alternative: what if every user became their own server?

This is how Beaker Browser came to be, an experimental browser based on Electron and Chromium that used the Hypercore protocol (originally Dat) for peer-to-peer content publishing. No backend, no hosting: you create a site right in the browser, and other users connect directly to your computer.

The project was archived in December 2022, but its ideas live on. Paul Frazee became CTO of Bluesky, and the Hypercore protocol itself continues to evolve. Below you will find how Beaker worked under the hood, what P2P APIs web developers had access to, and what can replace it today. If you are building something on the decentralized web, these lessons will save you weeks of trial and error.

💡 Quick overview:

• Install Beaker from GitHub releases for Windows, macOS, or Linux. Binary builds are still available, no separate hosting required.

• Click "Create New Site" and the browser generates a site with a hyper:// address right on your computer. No DNS, nginx, or deployment.

• Edit files in the built-in code editor and Hyperdrive, share the hyper:// address with another Beaker user, and they connect to you directly.

• The project was closed in 2022: the network is nearly empty. For working experiments with Hypercore, check out Agregore and Peersky Browser.

How Beaker Browser reinvented the web

Beaker was not just a Chromium wrapper with torrent support. It was a full-fledged browser that added a new layer to the web platform: the ability to read and write files directly to a peer-to-peer network.

When you visited a site with the hyper:// protocol, Beaker loaded its files from the computers of other users who had visited that site. After downloading, you yourself started seeding the files, either temporarily while the page was open, or permanently if you enabled seeding. It was similar to BitTorrent, but built right into the browser and tied to web addresses.

Six features that made Beaker worth installing

Instant site publishing. You clicked "Create New Site" and Beaker generated a site with a hyper:// address. The site was immediately available on the network; anyone with Beaker could open it if they knew the address. No DNS configuration, nginx, or deployment.

Collaborative hosting. The more visitors came to a P2P site, the faster it loaded, because each visitor helped distribute the content. This reduced the load on the author: no powerful server was needed during traffic spikes, the network scaled itself.

P2P applications using web technologies. Beaker provided the beaker.hyperdrive JavaScript API for reading and writing to a peer-to-peer file system. This meant that a web application could store data not on a server but in a decentralized network, and users controlled their own files.

The Hyperdrive file system. Each site in Beaker was not just a set of pages but a full-fledged file system with versioning. You could browse the site structure as in a file manager, see the change history, and even fork other people's projects, similar to GitHub but for the entire web.

Built-in terminal. Beaker included Webterm, a command line environment right in the browser. Developers could run scripts, manage files, and interact with APIs without leaving the browser window.

Source code editor. The integrated editor let you edit the site's HTML, CSS, and JavaScript and see the result immediately, side-by-side with the open page. An idea similar to modern online IDEs, but for the decentralized web.

Working with the Hypercore API: code examples

Beaker added a beaker namespace to the global window object with several key APIs. Let us break down the main ones; all code has been verified against the project documentation.

Working with the Hyperdrive file system

The beaker.hyperdrive API provided direct access to P2P site files. Here is what creating a drive, writing, and reading looked like:

1
const drive = await beaker.hyperdrive.createDrive()
2
 
3
await drive.readdir('/')
4
await drive.writeFile('/hello.md', '# Hello, P2P web!')
5
 
6
const stat = await drive.stat('/hello.md')
7
console.log('Size:', stat.size, 'bytes')
8
console.log('Modified:', stat.mtime)
9
 
10
const content = await drive.readFile('/hello.md', 'utf8')
11
console.log(content) // '# Hello, P2P web!'
12
 
13
await drive.unlink('/hello.md')

The methods are intuitive and similar to the Node.js fs module: writeFile, readFile, stat, unlink, readdir. The difference is that data is written not to local disk but to the peer-to-peer network, and any other user with access to this drive can read it.

Querying the file system

The beaker.hyperdrive.query API allowed searching for files by pattern across multiple sites simultaneously. This opened the door to decentralized feeds, search engines, and social networks without a central server:

1
async function readSocialFeed(sites) {
2
  return beaker.hyperdrive.query({
3
    path: '/microblog/*',
4
    drive: sites.map(site => site.url),
5
    sort: 'ctime',
6
  })
7
}

One call, and you get a time-sorted list of posts from microblogs of all sites in the sites array. No API keys, no OAuth, no server infrastructure.

Peer-to-peer messages

The beaker.peersockets API provided direct communication between site users, similar to WebSocket but running over the Hypercore network:

1
const topic = beaker.peersockets.join('chat')
2
 
3
topic.addEventListener('message', (e) => {
4
  const message = new TextDecoder().decode(e.message)
5
  console.log(e.peerId, 'says:', message)
6
})
7
 
8
function sendToPeer(peerId, message) {
9
  const encoded = new TextEncoder('utf-8').encode(message)
10
  topic.send(peerId, encoded)
11
}

This API enabled building decentralized chats, collaborative editors, and real-time applications where messages go directly from user to user without an intermediary server.

Why the project was shut down: three lessons from Beaker Browser

On December 27, 2022, the Beaker repository was officially archived with a note from Paul Frazee: "The time has come." He moved to Bluesky, a decentralized social network where the AT Protocol solves similar problems but at a different level.

There were several reasons for the shutdown. First, the P2P web never moved beyond experimentation. The average user is not ready to run a browser that does not support extensions, does not sync bookmarks, and does not work with familiar sites without caveats. Second, the cold start problem for a peer-to-peer network proved harsh: if the site author is offline and other visitors are not seeding, the site is unavailable. Third, Chromium turned out to be too heavy a foundation for a niche browser: maintaining a fork with custom APIs required resources that a team of three people did not have.

But the lessons from Beaker are more valuable than the browser itself. The project demonstrated that a browser can be not just a window into the web but a full-fledged development environment. That hyper:// as a protocol has a right to exist. And that decentralized APIs (beaker.hyperdrive, beaker.peersockets) can be as convenient as fetch or localStorage.

Video: Beaker Browser in action

Watch a demonstration of Beaker by Paul Frazee, a 2017 recording where he shows creating a P2P site in real time:

In 5 minutes, the video explains more clearly than any words how instant publishing worked and why the idea was powerful.

What came next: Agregore and other P2P browsers

The spirit of Beaker did not die. Today several projects continue the idea of a browser for the decentralized web:

Agregore Browser is a minimalist browser for the distributed web, supporting IPFS, Hypercore, and BitTorrent protocols out of the box. Unlike Beaker, Agregore does not drag along full Chromium but is built on lightweight Electron with a focus on P2P protocols. Web store extensions are supported, HTTP sites work as usual. The project has over 900 stars on GitHub and is actively updated.

Peersky Browser is another experimental P2P browser with IPFS, Hypercore, and Web3 support. Peersky adds its own set of P2P applications (peersky://p2p/) and focuses on integration with on-chain data. The project is younger than Agregore but is developing in the same direction: the browser as a platform for the decentralized web.

The Hypercore protocol itself continues to live independently from any browser: it powers Keet (P2P video calls from the protocol creators) and other decentralized applications.

⁉️🤔 Frequently asked questions

Can you download and run Beaker Browser now?

Binary builds are still available on the GitHub releases page for Windows, macOS, and Linux. The browser will launch, but the P2P network is practically empty: most peers are offline, sites are unavailable. For experiments with the Hypercore protocol, you should look at Agregore or Keet instead.

Yes, the installation files are still on GitHub Releases. But there is no practical point in installing it today: the Beaker network is dead, the documentation at docs.beakerbrowser.com is unavailable, and the project has not received security updates since 2022. To understand the concept, the source code on GitHub and video demonstrations are sufficient.

How was Beaker different from a regular browser with a torrent extension?

Beaker was a complete platform, not an add-on. A torrent extension only downloads files, while Beaker gave sites a JavaScript API for reading, writing, searching the file system, and direct messaging between users. All of this worked as part of the web platform, not an external plugin.

A regular browser with a torrent client lets you download a file via a magnet link. Beaker went further: a site on hyper:// could search for content on other sites using beaker.hyperdrive.query(), and exchange messages with visitors using beaker.peersockets. This is a different level of integration: P2P was not a browser feature but the foundation of the web platform.

Did Beaker work with regular HTTP sites?

Yes, fully. Beaker was built on Chromium and correctly opened any HTTP/HTTPS sites. The problem was the reverse: regular browsers did not support the hyper:// protocol, so P2P sites were invisible to 99.9% of internet users. This was one of the reasons the project did not take off.

Compatibility was one-way. You could use Beaker as a regular browser for the entire web, but the P2P site you created was visible only to other Beaker users. Mass adoption required either support for hyper:// in Chrome and Firefox, or gateways like Hashbase that translated P2P sites to HTTP. Neither happened at sufficient scale.

What happened to Paul Frazee and the Blue Link Labs team?

Paul Frazee became CTO of Bluesky, a decentralized social network built on the AT Protocol. In a post on Bluesky, he explains that the Beaker experience directly influenced the AT Protocol architecture. Blue Link Labs ceased to exist. The second key figure in the project, Tara Vancil, wrote a touching post "A Fond Farewell to Beaker" about the project's ups and downs.

Technically, Frazee did not abandon decentralization but moved to a different level. Instead of a browser for the P2P web, he is building a protocol for a decentralized social network. AT Protocol in Bluesky solves many problems that tripped up Beaker: a federated model instead of purely peer-to-peer, clear separation between servers and clients, support for scaling.

Is there any point in studying Beaker today?

As a codebase, yes. The source code on GitHub shows how to integrate a P2P protocol into an Electron application, how to design an API for a decentralized file system, and how to build browser extensions with custom protocols. As a product, no, but as an educational project on decentralized technologies, absolutely.

The Beaker source code represents 6,752 stars on GitHub and dozens of repositories with experiments around the Hypercore protocol. For a developer interested in P2P technologies, this is a treasure trove of architectural decisions: from handling custom protocols in Electron to building append-only logs based on Hypercore.

Is it worth looking back at Beaker in 2026

Beaker Browser did not become mainstream. But it showed that an alternative web model is possible: a model where the user is not separated from the server by a stack of CDNs, load balancers, and API gateways, but is themselves a node in the network.

Beaker's ideas migrated to Bluesky, the Hypercore protocol lives on in Keet and other projects, and Agregore Browser continues the experiment with a multi-protocol P2P browser today. If you are a web developer and want to understand where the decentralized web is heading, start with the Beaker source code on GitHub and the active Agregore.

The experiment did not succeed, but the idea itself proved contagious. And that is perhaps more important than market success.