httptoolkit-desktop: the Electron shell that packages HTTP Toolkit's server and UI into one installer
Electron wrapper to build and distribute HTTP Toolkit for the desktop
At a glance
- What is it?
- This repository is not the proxy. It is the packaging layer that bundles httptoolkit-server with the web UI inside Electron Builder targets for Windows, Linux and Mac. The interesting engineering is in process lifecycle and release plumbing, not in HTTP inspection.
- Who is it for?
- Adopt this repository if you need to change the desktop shell itself: window lifecycle, installer targets, or how the bundled server is started and killed. Do not adopt it if you want to debug HTTP traffic, because the proxy and UI live in httptoolkit-server and httptoolkit-ui, and this repo only assembles them.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What this repository actually owns
HTTP Toolkit is split across three repositories. The README names two runtime parts: a UI written as a single-page web application, and a server written as a node.js CLI application. This repository is the third piece, described in its own README as "mostly Electron configuration & setup, and build configuration for the executable and various installers." The stated job is to produce a single executable that includes the latest build of httptoolkit-server, starts that server in the background when run, opens the UI in an Electron window, and kills the server when the window closes. There is no proxy logic here, no certificate generation, no interception code. If you file a bug about how a request is captured or how a rule matches, the README points you to github.com/httptoolkit/httptoolkit instead. That split matters when you evaluate the project, because most of what users experience as HTTP Toolkit is not in this codebase.
The bundled server, the Electron window, and who kills whom
The data flow described in the README is a three-step lifecycle. The packaged executable starts httptoolkit-server as a background process. It then opens the UI in an Electron window, where the UI is a single-page web application rather than Electron-rendered markup. When the window closes, the server process is killed. That last step is the part worth scrutinising in any Electron wrapper, because it couples the lifetime of a child process to a window event. A crash in the renderer, a forced quit, or an OS-level termination can all bypass a normal close handler, and the README does not describe a supervision or orphan-reaping mechanism. Treat the kill-on-close behaviour as the documented intent rather than a guarantee, and verify it yourself on the platform you ship. The README also notes that the resulting executable does not autoupdate at the moment. Updates instead come from two other channels: the server, which is an oclif application, and the web UI, which updates through service workers. That is an unusual arrangement. The shell you install stays put while the two things it hosts move underneath it.
Building and running it: what the material gives you
The build tool is Electron Builder, named in the README with its documentation link. Builds run on GitHub Actions, and tagged main builds are published automatically from there as GitHub releases. The release list shows the cadence: v1.27.1 on 2026-08-13, v1.27.0 on 2026-08-07, v1.26.1 on 2026-06-10. That is a shell version, not a proxy version, and it moves on its own schedule. The README does not print the npm or yarn commands to produce a local build, and it does not list the Electron Builder configuration keys used for each target format. It defers that to CONTRIBUTING.md, which is not included in the material available here. So the honest position is that the entry point is CONTRIBUTING.md plus the Electron Builder configuration in the repository, and anyone quoting a specific build command for this project would be guessing. What is confirmed is the output: standalone installers and executables for Windows, Linux and Mac, produced by Electron Builder and published as GitHub releases. The README also states that running the desktop app is not the only option. You can run the server as a standalone tool and open the UI at app.httptoolkit.tech in any browser, which the README calls the less convenient path but a fully supported one.
Where a wrapper like this is the wrong tool
If your goal is to script HTTP interception in CI, the desktop build is the wrong layer. It exists to give a human a window and an installer. The README's own alternative is the one to take: run the server as a standalone tool and point a browser at the hosted UI, or drive the server directly. A second limitation is packaging reach. The README lists Windows, Linux and Mac as the targets, and adding a new target platform or format is explicitly framed as contribution work, which means it is not a configuration toggle a downstream user flips without touching the build setup. Third, the split update model has a practical consequence. Because the executable does not autoupdate, a fix that lands in the shell requires a new release and a manual reinstall, while a fix in the server or the UI can reach an existing install through oclif and service workers. If you are pinning versions for a fleet of machines, you are pinning three moving parts with three different update paths, and only one of them is under your direct control.
How it differs from shipping the server alone
The obvious alternative is not another Electron wrapper. It is skipping the wrapper entirely: install httptoolkit-server, run it, and open the UI in a browser. The difference in approach is where process management lives. In the browser model, you start and stop the server yourself, and the UI is served from app.httptoolkit.tech rather than from a bundled copy. In the desktop model, the Electron shell owns that lifecycle for you, which is the whole reason the README calls it the most convenient option for most users. The trade is control for convenience. A browser-based setup gives you a plain CLI process you can supervise with whatever you already use, and no Electron runtime in the picture. The desktop build gives you a double-clickable installer and a window, at the cost of an extra runtime layer and the kill-on-close coupling described above. Neither is a superset of the other, and the README is explicit that both are supported ways to run the same product.
Licence, redistribution and the two-track binary terms
The source in this repository is AGPL-3.0, as stated in the README and the LICENSE file. The binary downloads are offered under a choice the README spells out: AGPL-3.0 for those who want to modify and redistribute them within that licence's constraints, or Creative Commons Attribution-NoDerivatives 4.0 International for those who do not need those rights and want to avoid concerns about AGPL licensing. That second option is narrower than it first appears. NoDerivatives means you cannot ship a modified build under those terms, so the moment you patch the shell, the CC route is off the table for that artifact. This is a summary of what the README states, not legal advice, and the interaction between the AGPL source and the dual-licensed binaries is exactly the kind of question to put to a lawyer before you redistribute anything commercially. Note also that the AGPL applies to the desktop shell here, while the server and UI are separate repositories with their own terms that this material does not cover.
Maintenance cost and what a shell bump buys you
Three releases between June and August 2026, with a patch landing six days after a minor, suggests active but not frantic upkeep. The maintenance burden for a downstream fork is concentrated in two places: Electron version churn, which forces rebuilds and platform testing across Windows, Linux and Mac, and the Electron Builder target configuration for each installer format. Neither is visible in the README, so the real cost estimate has to come from reading CONTRIBUTING.md and the build configuration directly. The compensating factor is that the shell is thin. It starts a process, opens a window, and kills the process. There is little surface area to keep in sync with upstream, and the parts that change fastest, the server and the UI, update themselves without a new desktop release. For a team that just wants the desktop app, the cost is zero: download a release. For a team that wants to change the shell, budget for Electron upgrades and per-platform installer testing rather than for HTTP logic.
Editorial conclusion
Adopt this repository if you need to change the desktop shell itself: window lifecycle, installer targets, or how the bundled server is started and killed. Do not adopt it if you want to debug HTTP traffic, because the proxy and UI live in httptoolkit-server and httptoolkit-ui, and this repo only assembles them. Before building, read CONTRIBUTING.md and confirm three things: which Electron Builder target you are producing, how the server process is terminated when the window closes, and which of the two binary licences (AGPL-3.0 or CC BY-ND 4.0) applies to what you intend to redistribute.
Community notes