Hey everyone! It’s been rad to see folks still building kegbots in 2026, gosh!
Kegbot is approximately 22 years old now. I think it’s been overdue for a little love and maintenance, so I wanted to share what I have in mind and invite your feedback.
Overall goals
Make it easier, simpler, and fun to build a new Kegbot in 2026.
Make it easier to contribute and hack on Kegbot.
Stop doing anything we (I) can’t really support.
Bring all dependencies up-to-date.
Existing systems can be migrated in place (but don’t forget to backup first!)
Major architectural changes
ESP32-based controller, http reporting. 10-15 years ago, Arduino devices & data over serial was pretty much the only game in town. And we did some (at the time) cool stuff to connect it to tablets (usb host mode). Times have long since changed, and (a) esp32 micocontrollers are ubiquitous, cheap, and awesome; (b) host mode support is terrible and limiting; and (c) we can do much better with ip/http/ble-capable devices. Let’s do it.
Clean, easier to maintain OpenAPI-spec’d API. Long ago, we used protocol buffers as a sort of IDL to generate the rest API. But it’s a pain to maintain, has always had poor documentation, and honestly I dread looking at it. Let’s start fresh with an intuitive, idiomatic, and easier to maintain OpenAPI-spec’able API.
Modern, client-side React web frontend. Yikes! We’re still running on Bootstrap 3. In addition to being a very dated component library, React is super popular for a reason (and your author has built many projects and products with it).
Other major changes
EOL the Android app. It’s been poorly maintained, app stores are an enormous pain, and (with the changes above) it should be easier for others build their own native apps if they are interested.
EOL kegbot-pycore. It’s the old “read a serial device, report back to kegbot-server" program and doesn’t really have a place; all that work will happen on kegboard-esp32.
I’m sure I’m forgetting a bunch of things, but those are the major things that have been on my mind.
So now I turn it over to you: What do you think? What would you like to see? I’ll keep this post updated as the plan evolves.
I hacked together a websocket bridge which is working pretty well, I have had one arduino running for almost 10 years… they are just so solid. Whatever needs to happen to remove that requirement for usb host mode in tablets has my vote. I wish I could contribute more on the dev side but more than happy to help with testing and documentation etc.
Update: Backend changes, including a new API and rewritten ReactJS dashboard, are coming along nicely as well.
The current focus remains on modernizing the stack, so the overall layout, information architecture, etc, aren’t dramatically different. New coat of paint + major under-the-hood overhauls.
This is very cool! I actually did a custom esp32 build for my setup about a year and a half ago and it works very well. I have 4 boards running, and it’s so much easier than having to deal with the old USB.
One other custom thing I worked on was using a combination of the Android App, Webhooks, and Amazon Rekognition service (facial recognition) , i’m able to assign pours from the photos. Surprisingly this works remarkably well, I have an identical twin brother and it is even able to tell the difference between us 99% of the time. the Rekognition only costs a fraction of a cent per scan, so a heavy weekend of pours may only increase my normal AWS bill by like 10-20 cents. But does require the Kegbot webhook to post to a custom AWS site that I have which takes the pour photo, matches it to a known user and then posts back to kegbot to assign the pour.
I’ve been using Kegbot for 10 years now and its worked great, usually have between 10 and 12 kegs running at a time, and over the course of 10 years have had almost 18,000 pints poured! - http://kegs.cussonpub.com/
That’s awesome! Yeah, esp32 is just such a no brainer these days. I love the facial recognition auth, super cool.
I’m pretty close to landing both the kegboard change and the backend overhaul. If you’re curious, here’s the new HTTP protocol which the esp32 will speak & which the backend will implement. I’m definitely open to feedback and of course anything I’m overlooking!
