# Probot: building GitHub Apps in Node.js and TypeScript

> Probot is a framework for building GitHub Apps in Node.js, written in TypeScript. It handles the webhook plumbing so your app can react to events like issues.opened, and the repository ships the npm package that Probot Apps run on.

**probot/probot** — 🤖 A framework for building GitHub Apps to automate and improve your workflow

- Repository: https://github.com/probot/probot
- Website: https://probot.github.io
- Stars: 9,616 · Forks: 1,050
- Language: TypeScript
- License: ISC
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/probot-probot

## The gap Probot fills between a GitHub webhook and a working app

GitHub Apps are first-class actors inside GitHub. The README describes them as extensions that can be installed on organizations and user accounts, granted access to specific repositories, and given granular permissions plus built-in webhooks. That is a lot of surface area to wire up by hand: you need a webhook endpoint, signature verification, an installation token, and an Octokit client bound to the right installation before you can do anything useful.

Probot is aimed at developers who want to skip that layer. The README frames it as a framework for building GitHub Apps in Node.js, written in TypeScript, and says the repository hosts the code for the npm Probot package that all Probot Apps run on. The intended audience is a Node developer who has an idea for repository automation and would rather write the behaviour than the transport.

The README is also explicit that this repository is not the starting point for most readers. It states that if you landed there looking to build your own app, the Probot website at probot.github.io carries the getting started documentation. Treat this repository as the runtime, not the tutorial.

## How a Probot app receives events and calls the GitHub API

The mechanism is an event emitter. The README says GitHub Apps listen to webhook events sent by a repository or organization, and that Probot uses its internal event emitter to perform actions based on those events. Your app is a function that receives the app object, and you attach handlers to named events.

The README's example shows the shape of it. An app exports a default function taking app, registers a handler for issues.opened, builds a comment body through context.issue, and returns context.octokit.issues.createComment. Two more hooks appear in the same example: app.onAny receives every event with its name and payload action, and app.onError receives errors. The context object is where the useful state lives, including a logger reachable as context.log and the Octokit client as context.octokit.

```js
export default (app) => {
  app.on("issues.opened", async (context) => {
    const issueComment = context.issue({
      body: "Thanks for opening this issue!",
    });
    return context.octokit.issues.createComment(issueComment);
  });
};
```

The package metadata points at the dependency stack underneath: @octokit/core and @octokit/plugin-enterprise-compatibility are listed among the dependencies, so the GitHub API calls go through Octokit rather than a bespoke HTTP client. The repository also carries a jsr.json file and a bin/ directory, which means the package is published in more than one registry format and ships a command-line entry point.

## Installing Probot and running a first app locally

The README does not give install commands. It directs readers to probot.github.io/docs for the set-up process, and the package.json is the only place in this material that shows how the package is driven.

The package declares a bin entry named probot pointing at ./bin/probot.js, and a start script that runs node ./bin/probot.js. So the CLI is the documented way the package is launched from a checkout of the framework itself.

```bash
npm install probot
```

For the framework's own development workflow, the repository defines a build step and a test step. Note the pretest script, which removes the lib directory, rebuilds, and type-checks the test tree before vitest runs.

```bash
npm run build
npm test
```

There is a Redis path for tests that need shared state. The scripts start a Redis container on port 6379 and pass REDIS_URL to the test run, then stop the container.

```bash
npm run redis:start
REDIS_URL=127.0.0.1 vitest run --testTimeout 10000
npm run redis:stop
```

If you run those commands, expect the first to print the container id, the second to execute the vitest suite against the running Redis, and the third to stop the container. Whether your own app needs Redis depends on how you configure it; the README does not describe the app-side configuration keys, so check probot.github.io/docs before assuming a default.

## Where Probot stops being the right tool

Probot is a Node.js framework. If your team writes Go, Python or Ruby, nothing here helps you; the README names Node.js and TypeScript and does not describe bindings for other runtimes.

It is also not a hosted service. The README describes a library and a CLI, not a dashboard where you toggle rules. Anyone expecting to install an app, click through a settings page and be done will be disappointed, because the behaviour only exists once someone writes and deploys the handler function.

The README is thin on operational questions. It does not document deployment targets, scaling, secret storage, rollback, or how the CLI behaves behind a proxy. Those are exactly the questions that decide whether a framework survives contact with production, and their absence from the README is a real cost: you will be reading probot.github.io/docs and the TypeScript source instead. The repository layout suggests the documentation lives in docs/ and generated API docs come from typedoc, so the answers exist somewhere, but not in the file most people read first.

Finally, the repository is a framework, not an app store. The README points people who want to share ideas at a separate probot/ideas repository and people looking for existing apps at a GitHub topic search for probot-app. If you want a ready-made automation, you are in the wrong repository.

## Probot against a direct Octokit integration

The obvious alternative is to skip the framework and use Octokit directly. Octokit is already a Probot dependency, and it exposes the same API calls that context.octokit exposes inside a handler. The difference is what sits above the HTTP layer.

With Octokit alone you own the webhook endpoint, the signature check, the mapping from an installation to a token, and the dispatch from an incoming event name to your code. With Probot, the README describes an internal event emitter doing that dispatch, and the handler signature gives you a context object with the issue helper, the logger and the bound Octokit client already assembled.

The trade-off runs the other way too. A direct Octokit integration puts you in control of the HTTP server, the middleware chain and the deployment shape, and it does not tie you to Probot's app-function convention or its CLI. The repository does include an example named example/node-middleware.mjs, which suggests Probot can be mounted inside an existing Node HTTP stack rather than owning the process. That file is the place to look if you want the framework's event handling without its server.

## Maintenance, releases and what the ISC licence means here

The last push to the default branch was on 2026-09-15, six days before the date used for this review, and the repository is not archived. The most recent release listed is v14.3.2 from 2026-04-03, preceded by v14.3.1 on 2026-03-20 and v14.3.0 on 2026-03-16. Commits landing after the last tagged release are normal for a project that tags less often than it merges.

The package.json version field reads 0.0.0-development, which is the placeholder used when a release pipeline stamps the real version at publish time. Do not read that string as the shipped version; read the npm registry or the release list instead.

Upgrade cost is mostly the Octokit dependency. The declared ranges include @octokit/core ^7.0.3 and @octokit/plugin-enterprise-compatibility ^6.0.1, so a major bump in Octokit is the event most likely to break a Probot app, and the framework's own major versions are where that gets absorbed. The licence is ISC, a permissive licence that permits commercial use and modification; the repository ships a LICENSE file and the package metadata repeats the identifier. This is a description of the licence text, not legal advice, and ISC does not by itself settle questions about the GitHub API terms your app operates under.

## Conclusion

Adopt Probot if you are writing a GitHub App in Node.js or TypeScript and want the webhook and authentication plumbing handled for you. Do not adopt it if you need a Discord bot (the search results for that name point at a different product), or if you want a hosted no-code automation service. Before committing, verify that the npm package installs cleanly and that the CLI in bin/probot.js starts your app locally, then read probot.github.io/docs for the setup path, because the README defers to that site rather than documenting installation itself.

## FAQ

### What is Probot and what does it do?

Probot is a framework for building GitHub Apps in Node.js, written in TypeScript. It listens to webhook events from a repository or organization and uses an internal event emitter to run handlers you attach to those events.

### How do I install Probot?

The npm package is named probot, so npm install probot is the install step. The README does not document installation itself and sends readers to probot.github.io/docs for the getting started process.

### Does Probot work with TypeScript?

Yes. The README states Probot is written in TypeScript, the package ships types at ./lib/index.d.ts, and the build script runs tsc against tsconfig.json.

### What licence does Probot use?

The package metadata and the LICENSE file both give ISC, a permissive licence. The README does not discuss licence terms beyond that identifier.

## Sources

- [License: ISC](https://github.com/probot/probot/blob/master/LICENSE)
- [probot/probot on GitHub](https://github.com/probot/probot)
- [Project website](https://probot.github.io)
- [README](https://github.com/probot/probot/blob/master/README.md)
- [Releases](https://github.com/probot/probot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/probot-probot