comment 0

Building a GitHub bot


This last week I’ve been writing a GitHub bot for Having some open-source repositories with lots of external contributors, we can use some help automating the contribution pipeline. So I set myself out to explore the current landscape of bot frameworks. The two that came out on top are Hubot (a bot framework built by GitHub with a lot of existing community scripts) and Probot (a more recent bot framework, also with a surprising amount of high-quality apps already built on it).


How do they compare?

Both Hubot and Probot are Node.js apps and normally you’ll leverage the same npm modules (e.g. the github package for accessing the GitHub API). Their API is similar enough that converting a bot from one framework to another shouldn’t be a big deal.

At first look, I thought that one major conceptual difference between both frameworks was that you’d normally build a single Hubot app that encapsulates many community and custom scripts, whereas Probot seems to prefer having one GitHub App per functionality. But upon deeper inspection, Probot also allows you to combine apps.


Hubot is built with CoffeeScript and you write your scripts on either CoffeeScript or JavaScript (there are plans to port Hubot to ES2015 though, and even to eventually merge with Probot). You have access to a brain, which allows you to persist data (the actual storage system is pluggable, with choices like Redis, Azure blobs, etc.)

Hubot pros

  • I haven’t made a thorough comparison, but Hubot may have the edge in terms of available community scripts (at least as of this writing).

Hubot cons

  • Hubot doesn’t force you to deploy your app as a GitHub App like Probot, but that means you’re on your own to implement that logic, although you have some npm modules that will help you there, such as jwt-simple.
  • The Hubot project seems to be less active than Probot nowadays.
  • No out-of-the-box way to expose your own HTTP endpoints.
  • No scriptable tooling to replay webhooks, need to use the UI.


Probot is built on Javascript, and you can leverage ES6 for your bot logic. It comes with some console tooling for experimenting with GitHub API requests, simulating webhook calls, etc. There are already a ton of open-source ready-to-install apps available built on the framework.

Probot pros

  • Probot takes care of all the little details like GitHub API authentication, setting up webhook listeners, etc., so that all you’re left with is writing the logic that makes your bot stand out from the rest. With Hubot you’re on your own to write that foundation code, even though you have libraries to help you.
  • Probot seems to have better tooling, like the ability to simulate GitHub webhooks.
  • Handling of GitHub webhooks is as good as it can be in Probot. As simple as robot.on('issues.opened', ctx => {...}).
  • Probot makes it easy to provide HTTP endpoints on your app through express.
  • Supports per-repo configuration through the probot-config extension.
  • Supports schedulers to perform regular actions on the repos that are accessible to the bot.

Probot cons

  • No support for key/value persistence store like the Hubot brain. Tracked in probot#258.


Based on these findings, I’ll probably port my newborn bot over to Probot, while it is still a very small task. It seems to have the best tooling and API, so there’s really no reason not to.

Hope this post has helped you get a good sense of the differences between the two frameworks, and make your own choice. If you have any comments, don’t hesitate to sound off in the comments section.

Filed under: DevOps, OSS

About the Author

Posted by

Go Core Team Lead @ (remote), previously Windows Team Lead @ Plex (remote), Architect, Codebase Whisperer, DevOps enthusiast, Continuous Learner