Building HearthVTT: A Homebrew-First Virtual Tabletop

Alexey Bachmanov — Sat, 23 May 2026 02:28:28 +0000

I think some of the best software in the world comes from a place of passion, but in a pinch, frustration will suffice.

This started December 2025. I was playing a fun D&D campaign, with a group of people I really liked. We've been fighting Strahd for three long, grueling, grim, dark years, and finally the goal was in sight. We'd get him soon, or he'd get us, but then what? We needed a new game, and I wanted to be the one to run it, so it was time to start looking at the logistics of how.

The Problem

The traditional and most frictionless way to play is with pen and paper, around a table loaded with junk food and energy drinks. Most game systems are actually designed around this infrastructure, people getting together in the same place, and playing pretend with rules and math rocks. But, our group was all over the country. No good. We had to do something online.

The next best way is with a virtual tabletop (VTT). Software that can handle a map, the pieces on it, and the rules governing how they interact. There's lots of them out there, and have been for a long time. Why not pick one of those, Alexey? I wanted to reduce the friction with our play, so fights don't feel like data entry. I didn't want to hemorrhage money paying for subscriptions and sourcebooks. And lastly, and this was absolutely non-negotiable, the campaign had to have flying whales.

The Solution Space

The existing space has lots of tools that are popular, powerful, and easy. But spoilers, I didn't find what I'm looking for. Let's take a look at what's available:

Roll20, the big dog in the space. I've used it for years. Map interaction, check. Character information, campaign information, and notes all live in the same space, check. Automation for the math so it doesn't feel like work, check. Can I make my own entities and use them in the campaign? Well, sort of, but not in the way I want. It can handle homebrew inside a campaign, and people have made workarounds over the years, but private, reusable content that integrates as seamlessly as the official marketplace content has long been a sore spot in the community. So no, no flying whales.
D&D Beyond, the official source for all your D&D needs. I've used it for years as well, and it has great support for characters and homebrew. As of late, it even integrates maps into its system, so it's a lot closer to a full table than it used to be. But it's still fundamentally an official D&D ecosystem, it won't be able to accommodate every game.
Fantasy Grounds, comprehensive but not hackable. It is automated, it will handle the game systems well, it's got a mature marketplace, and supports custom extensions and rulesets. The extension system is XML and Lua based. Close, but not the kind of ecosystem that would support what I want to do.
Owlbear Rodeo, snappy, lightweight, and fast. It's very good at what it does: maps. But for rule systems, I'd have to bolt on something else.
MapTool, free and open-source. Own your setup, customize heavily, self-host your game, don't depend on a marketplace. It aligns with a lot of the things I value in software, in games, and in general. This one was hard to reject. However, it comes from an older line of desktop tools. No playing on a tablet, no animated maps.
Foundry VTT, this one was the hardest to reject. Self-hosted, extensible, browser-based, and very powerful. But it's also a proprietary core surrounded by a huge ecosystem of systems and modules, and that ecosystem has a very real problem with managing compatibility. There's a risk of my campaign becoming fragile across version changes, or of me freezing on an old version because updating might mean auditing the whole stack of systems and modules.
Roll20 for maps + D&D Beyond for rules and entities + Discord for tracking campaign notes? This is what we've been using for the Strahd campaign. But the sources of truth were spread across three applications, and the duct tape holding it together was starting to wear out. We can do better, I think.
Build your own. No, that's biting off a lot more than I can chew.

Build Your Own

Ok, if we build our own, we can at least fail in the direction we want.

What I needed originally:

One place to play. Maps, characters, campaign notes, rules and handouts should not be scattered across multiple applications.
Less arithmetic at the table. No interrupting the story to calculate 1d10 + 4 slashing + 1d4 cold + 1d6 necrotic damage. Our paladin stole a sword from a ghost. It was awesome. He loved the sword, hated the math.
Room for weird homebrew. I will have my flying whales. If the campaign needs something strange, the software should not be the thing that says no.
A campaign I can keep. I do not want the game to depend on a subscription, a marketplace, or a company's product roadmap.

What I liked from the other systems:

Browser-based play, like Foundry and Roll20. Players should be able to join without installing a lot of software.
Extensibility, like Foundry. The system should be open to new rules, new tools, and new ways of playing.
Open-source and self-hostable values, like MapTool. If the community depends on the tool, they should be able to inspect it, run it, and preserve it.
Fast map interaction, like Owlbear Rodeo. The table should feel responsive, not like a database with a battlemap attached.
Useful automation, like Roll20, Foundry, and Fantasy Grounds. The computer should handle the boring parts, as long as the GM can still understand and override what happened.

And what I can add because I want it:

Portable campaign files. A campaign should be something you can back up, move, archive, and restore. No renting it from a cloud provider.
A clean split between campaigns, rules, and content. The current state of the game, the reusable source material, and the logic making the rules work should not be smeared together.
Homebrew entities that automation can understand. My whales should be a creature, a vehicle, a mount, or whatever the campaign needs them to be, possibly all at the same time.
Inspectability and undo by default. Automation should disappear during play, but it should leave an audit trail if something goes wrong.
Local-first without being lonely. Self-hosting should be a first-class path, but the game should still be easy to share with players over the internet.

Now, we can ask a different question: what would a VTT look like if the first-class user was not the person buying a polished official adventure, but a GM building a weird homebrew campaign that needs to survive, move, fork, and grow over the years?

That's the thing I want to build. I'm not trying to beat every VTT at their own game. I'm making something for the people who want a game of their own.

So What Are You Doing About It?

Biting off a lot more than I can chew. But the core architecture is in place, the server serves, the client clients, and I'm working on the websocket connection between the two. And I didn't come here empty-handed:

HearthVTT on GitHub

This is still early, and I'm sure that some of my assumptions are wrong. If you use a VTT in your games, either the ones I talked about or something smaller and stranger, I'd love to hear where you think I'm being unfair. More than that, I'd love to hear about your pain points, and where your campaigns break down. Is it custom rules, custom monsters, automation, hosting, performance, portability, or just keeping your notes from turning into digital archaeology?

Next up: turning "homebrew-first" from a slogan into an architecture.

DEV Community: Alexey Bachmanov

Building HearthVTT: A Homebrew-First Virtual Tabletop

The Problem

The Solution Space

Build Your Own

So What Are You Doing About It?