Beaker

Beaker is a web browser that lets you publish a website from your own computer with no server behind it. Create a new site from a menu, edit its pages in a built-in editor, and the browser hands out a hyper:// address that other people running the same browser can open. The files live in a hyperdrive, a folder that synchronises itself to anyone who visits, and every visitor who keeps the site open helps serve it to the next, the way a torrent spreads a file. Ordinary web pages load as they do in any browser, since the engine underneath is the same Chromium most browsers share, and the peer-to-peer part sits alongside.

The idea is the attraction, and the state of the project is the first thing to know. Beaker was an experiment, it was closed by its own team, its source repository is archived and its website is gone. The browser still installs and still opens ordinary pages, but the network of peer-to-peer sites it was built for has largely emptied, and the Chromium inside it has not received a security fix since. What follows describes what the program does, and the sections on the network and the engine say plainly what that means in practice today.

Publishing a site from the browser

A new Beaker site starts from the menu with a title and a template, and it appears as a folder in the browser’s own file manager. Pages are HTML, CSS and JavaScript files like any website, edited in a code editor built into a sidebar, with changes visible on reload. There is no upload step and no hosting account, because the folder itself is the site and the browser serves it. A site can also be made from an existing folder on the disk, which turns a project directory into a published page in a minute.

Every hyperdrive has a public key as its address, and sharing that address is sharing the site. Forking copies someone else’s site into your own hyperdrive, where you can edit it, which is how templates and themes passed around the network. A version history records every change, and old states can be compared and restored.

Browsing peer-to-peer sites

Open a hyper:// address in Beaker and the browser finds peers holding that drive, downloads what it needs and renders the page, keeping a copy that it serves to others while the tab is open. A site with many visitors loads quickly from all of them. A site whose author is offline and whose visitors have all left simply does not load, which is the trade of having no server. A pin option keeps a site hosted from your machine even when you are not visiting, and that is how a small community kept each other’s sites alive.

The browser also exposes APIs so a site can read and write files in the visitor’s own hyperdrives with permission, which made hostless applications possible, a notes app or a feed reader that stored its data in your drive rather than on someone else’s server, the same instinct that drives a bundle of decentralised privacy tools with maintained software behind it. Those applications were the most interesting thing built on it, and they depend on the same peers that have gone quiet. A handful still run for the people who kept them, which is the only way to see what the model felt like in use.

The network today

Peer-to-peer sites need peers, and Beaker has few left. With the project closed and its community moved on, most hyper:// addresses from the browser’s active period no longer resolve, because nobody is online holding them, and the directory pages that listed sites have disappeared with the project’s own website. A hyperdrive you create still works between machines you control or friends who install the browser, so the publishing tool functions for a closed group, much as a peer-to-peer folder sync tool moves files between your own devices without a server. As a window onto a living network, it shows mostly empty rooms.

The protocol itself continues under other names, and a minimal successor browser exists for anyone who wants the peer-to-peer web with a maintained engine. This program’s value now is as a demonstration of the idea rather than as a daily browser, and anyone keeping sites alive with it is doing so on purpose. For a group that wants exactly that, the mechanism is intact and the empty network is no obstacle.

The engine, and why it matters

The Chromium build inside Beaker is frozen at the version it shipped with, and browser engines accumulate security fixes weekly. Using an old engine on the open web exposes the machine to vulnerabilities every current browser has patched, and no proxy or care in browsing compensates for a hole in the renderer. Modern sites also lean on web features the old engine lacks, so pages break in ways that look like the site’s fault and are not.

What to use instead, and for what

The honest use is therefore narrow. Keep ordinary browsing in a current browser such as Brave Browser, which shares the same engine family with its fixes applied, and open this one only for a hyperdrive you or someone you trust is sharing. The peer-to-peer publishing is the part to keep, and the browsing is the part to hand to something maintained.

Conclusion

Beaker suits the curious who want to see what a website without a server feels like to build and share, and small groups who will install it together to pass hyperdrives among themselves. The publishing tools remain the most approachable demonstration of the peer-to-peer web ever shipped, and creating a site from a folder still works as it always did.

It is not a browser to live in, and it should not be anyone’s window on the ordinary web. Treat it as a museum piece that still powers on, use a current browser for everything else, and look to the protocol’s living successors if the idea itself is what drew you here.