# dstotijn/hetty: a self-hosted MITM proxy and HTTP toolkit for security research

> Hetty is an MIT-licensed HTTP toolkit written in Go: a machine-in-the-middle proxy with logging, search, intercept and replay, plus a web admin interface. It is aimed at penetration testers and bug bounty hunters who want a self-hosted alternative to commercial proxy suites.

**dstotijn/hetty** — An HTTP toolkit for security research.

- Repository: https://github.com/dstotijn/hetty
- Website: https://hetty.xyz
- Stars: 12,504 · Forks: 822
- Language: Go
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dstotijn-hetty

## What Hetty is for, and who it is meant to serve

Hetty is an HTTP toolkit for security research. The README states the project aims to become an open source alternative to commercial software like Burp Suite Pro, with features tailored to the infosec and bug bounty community. That framing sets the audience precisely: people who already understand proxies, certificates and request replay, and who want the tooling on their own machine rather than in a licensed product.

The feature list is short and specific. A machine-in-the-middle HTTP proxy with logs and advanced search. An HTTP client for manually creating and editing requests, and for replaying proxied requests. Interception of requests and responses for manual review, where you can edit, send or receive, or cancel. Scope support. A web based admin interface. Project based database storage so work stays organized across engagements.

If you are auditing a single web application and you want a proxy you can run locally, inspect, and extend in Go, this is the target use case. If you need a proxy for load testing, for TLS inspection at the network edge, or for long-running production traffic capture, the design here is pointed elsewhere.

## The mechanism: one binary, three services, bbolt on disk

Running `hetty` starts an HTTP server that bundles a MITM proxy, a GraphQL service, and a web based admin interface, according to the usage text in the README. That single-process design is the central architectural fact. The admin UI in the repository lives under `admin/`, and the Dockerfile builds it with Node and Yarn, exports it, and copies the result into `cmd/hetty/admin` before the Go build runs. So the front end is compiled into the binary rather than served from a separate process.

Storage is embedded. The `--db` flag defaults to `~/.hetty/hetty.db`, and `go.mod` lists `go.etcd.io/bbolt` as a dependency, which is where captured traffic lands. Project based storage means you can keep separate databases per engagement by pointing `--db` at different files; the README does not describe an in-app project switcher beyond that.

Certificates are generated on demand. The `--cert` and `--key` flags default to `~/.hetty/hetty_cert.pem` and `~/.hetty/hetty_key.pem`, and the help text says each file is created if it does not exist. There is a `cert` subcommand for certificate management. The `smallstep/truststore` dependency suggests the tool can install that root CA into the system trust store, though the README does not spell out the exact behaviour per platform.

The client-facing surface is GraphQL. `gqlgen.yml` and the `99designs/gqlgen` dependency in `go.mod` indicate the API between the UI and the Go backend is generated GraphQL, which is also how the admin interface reads logs and issues replay actions. The `--chrome` flag launches Chrome with proxy settings applied and certificate errors ignored, which is the fastest way to get a browser pointed at the proxy without manually configuring a profile.

## Installing Hetty and capturing your first request

The README calls a package manager the quickest way to install and update Hetty. On macOS the tap is `hettysoft/tap/hetty`:

```bash
brew install hettysoft/tap/hetty
```

On Linux the package is published as a snap, and on Windows through a Scoop bucket. Both are one-liners from the README:

```bash
sudo snap install hetty
```

```bash
scoop bucket add hettysoft https://github.com/hettysoft/scoop-bucket.git
scoop install hettysoft/hetty
```

If your OS or architecture is not covered by those, the README points to the GitHub releases page for a binary you move into your `$PATH`. Docker images are published to GitHub's Container registry and Docker Hub. The README gives this command to run Hetty with a volume for database and certificate storage and port 8080 forwarded:

```bash
docker run -v $HOME/.hetty:/root/.hetty -p 8080:8080 \
  ghcr.io/dstotijn/hetty:latest
```

Once installed, start it with `hetty` and open the admin interface on port 8080. The default listen address is `:8080` per the `--addr` flag. To see every option, run `hetty --help`; the README shows that this prints the flags for cert, key, db, addr, chrome, verbose, json and version, plus the `cert` subcommand.

For a first real use, launch with `hetty --chrome`. The README describes that flag as launching Chrome with proxy settings applied and certificate errors ignored, which removes the manual certificate step for a quick session. Point the browser at a site you are authorized to test, then return to the admin UI to see the request logged. From there the HTTP client lets you create or edit a request by hand, and the replay action resends a proxied request with your modifications.

## Where Hetty stops being the right tool

The release history is the first limitation worth naming. The most recent release is v0.7.0, published on 2022-03-29, and the two before it are v0.6.0 from 2022-03-02 and v0.5.1 from 2022-02-26. The repository's last push was on 2026-07-21, so the codebase has moved since that release, but no newer tagged release has been published. The README says Hetty is under active development and points at a backlog for current status. If your adoption process requires a recent tagged release, that gap matters more than the commit activity.

The README also does not document an upgrade path. There is no migration note for the bbolt database format, no statement about whether a newer build reads a database written by an older one, and no rollback instructions. For a tool that stores engagement data on disk, that silence is a real operational risk. Copy `~/.hetty/hetty.db` before upgrading, because nothing in the README tells you the format is stable.

Second, the extension story is thin. Commercial proxies have plugin marketplaces and scripting APIs; Hetty's documented surface is the proxy, the HTTP client, intercept, scope and the admin UI. If your workflow depends on third-party extensions, this is the wrong tool. Third, `--chrome` disables certificate error handling by design, which is convenient for a lab and unacceptable on a machine you also use for normal browsing. Run it in a dedicated profile or a container.

Finally, if you need a proxy that other people's machines route through at scale, or one with a documented team collaboration model, Hetty's own README asks professional pen testers for survey feedback on team tooling. That is a fair signal that multi-user workflows are not the settled part of the design.

## How Hetty differs from mitmproxy and Burp Suite Community

The closest open source comparison is mitmproxy. Both are MITM proxies, both are open source, and both let you inspect and modify traffic. The difference is in the shape of the tool. mitmproxy is a console and Python-scripting proxy: you write addons in Python, and the primary interface is a terminal UI or a command-line tool. Hetty puts a web based admin interface in front of a Go backend, and its stated ambition is to sit alongside commercial suites rather than to be a scripting platform. If your workflow is already a pile of Python addons, mitmproxy is the more natural fit. If you would rather click through captured requests in a browser tab and replay them without writing code, Hetty's model is closer to that.

Burp Suite Community is the other reference point the README itself invokes with Burp Suite Pro. The practical difference is that Hetty is self-hosted, MIT-licensed, and has no feature gating or license server. What it lacks is Burp's extension ecosystem and the depth of its scanner. Hetty's documented feature set stops at proxy, client, intercept, scope and storage; there is no scanner in the list.

One more distinction worth noting: Hetty is written in Go with an embedded bbolt database and a compiled-in front end. That makes distribution simple, a single binary or a container image, and it makes the tool easy to read if you want to modify the proxy itself. It also means extending it means forking Go code, not dropping a script into a plugins directory.

## Licence, maintenance and what an upgrade actually costs

Hetty is MIT licensed, and the README carries a copyright line reading 2019 to 2025 Hetty Software. MIT is permissive: you can use it commercially, modify it, and redistribute it, provided the licence text and copyright notice travel with it. That is a statement about the licence file, not legal advice, and if you plan to redistribute a modified build inside a product you should read the LICENSE file in the repository yourself.

The maintenance picture is mixed and worth stating plainly. The repository is not archived, and its last push was on 2026-07-21, which is recent. But the newest release is v0.7.0 from 2022-03-29, so the shipped artifacts trail the source tree by years. For anyone installing through brew, snap, scoop or a container tag, the thing you get is built from a release line that has not been tagged in a long time.

Upgrade cost is where this bites. Because the README does not document database migration or rollback, treat the `--db` file as the unit you protect. Back up `~/.hetty/hetty.db` and the `~/.hetty/hetty_cert.pem` and `~/.hetty/hetty_key.pem` files before changing versions. If you build from source, note that `go.mod` declares Go 1.23 with a toolchain of go1.23.4, while the Dockerfile still pins `GO_VERSION=1.17` and `NODE_VERSION=16.13` as build arguments. Those two facts disagree, and a source build is the place where the disagreement will surface. The Makefile's `build` target runs `build-admin` first, which installs the admin front end with Yarn and exports it into `cmd/hetty/admin`, so a source build needs both a working Go toolchain and Node available.

## Conclusion

Adopt Hetty if you want a self-hosted MITM proxy with a browser-based admin UI and per-project storage, and you are comfortable with a tool whose latest release is v0.7.0 from 2022-03-29. Do not adopt it if you need a mature extension ecosystem or a documented upgrade path; the README does not describe one. Before committing, verify that the current binary still builds against the Go 1.23 toolchain in go.mod, that your OS has a package-manager path or a GitHub release asset, and that the proxy certificate installs cleanly on your test client.

## FAQ

### What is Hetty, and what is it used for?

Hetty is an HTTP toolkit for security research, distributed as a single binary or container. It runs a machine-in-the-middle HTTP proxy with logs and advanced search, an HTTP client for creating and replaying requests, request and response interception, scope support, and a web based admin interface.

### How do I install Hetty on macOS, Linux or Windows?

The README lists a package manager as the quickest route: brew install hettysoft/tap/hetty on macOS, sudo snap install hetty on Linux, and a Scoop bucket on Windows. Docker images are published to GitHub's Container registry and Docker Hub, and binaries are available from the GitHub releases page.

### What port does Hetty listen on, and where does it store captured traffic?

The default listen address is :8080, set by the --addr flag. Captured data goes to the database file given by --db, which defaults to ~/.hetty/hetty.db and is created if it does not exist.

### Can Hetty replay or modify a proxied request?

Yes. The README lists an HTTP client for manually creating and editing requests, and replay of proxied requests. Interception lets you review requests and responses and then edit, send or receive, or cancel them.

### Does Hetty launch a browser with the proxy already configured?

The --chrome flag launches Chrome with proxy settings applied and certificate errors ignored, and it defaults to false. That behaviour is convenient for a test session and should not be used on a browser profile you rely on for normal browsing.

## Sources

- [dstotijn/hetty on GitHub](https://github.com/dstotijn/hetty)
- [License: MIT](https://github.com/dstotijn/hetty/blob/main/LICENSE)
- [Project website](https://hetty.xyz)
- [README](https://github.com/dstotijn/hetty/blob/main/README.md)
- [Releases](https://github.com/dstotijn/hetty/releases)

---

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