Webhook.site self-hosted: the open source build of the webhook tester

The problem Webhook.site solves, and who it is for

Testing an outgoing webhook normally requires a receiver. You need a host with a public address, a TLS certificate, a route that accepts POST bodies, and somewhere to read what arrived. Webhook.site removes that work: the README says you "instantly get a unique, random URL that you can use to test and debug Webhooks and HTTP requests". The request arrives, the tool stores it, and the frontend displays it.

The README lists the use cases it is built around: receiving webhooks without an internet-facing web server, sending webhooks to a server behind a firewall or private subnet, transforming webhooks into other formats and re-sending them, connecting APIs that are not compatible, building contact forms that send email, and building APIs without infrastructure. The audience is developers and integrators who are wiring two systems together and need to see the raw payload before writing a parser. The repository is a Laravel API plus an Angular.js single-page app, with Redis for broadcasting and an optional SQLite database.

How the Laravel API, Angular SPA and Redis fit together

The repository layout shows a conventional Laravel application: app/, bootstrap/, config/, database/, public/, resources/, storage/, artisan and composer.json, with server.php at the root for the built-in PHP server. The frontend is compiled separately. package.json lists Angular 1.4, angular-ui-router, bootstrap-sass, highlight.js, clipboard and laravel-echo, and gulp (laravel-elixir) builds the CSS and JS that the Dockerfile later copies out of the node stage into public/css and public/js.

Live updates are the interesting part. The docker-compose.yml runs three services: webhook (the PHP application), redis, and laravel-echo-server. The webhook service is started with php artisan queue:work --daemon --tries=3 --timeout=10, so request processing is queued rather than done inline. Its environment sets BROADCAST_DRIVER=redis, CACHE_DRIVER=redis and QUEUE_DRIVER=redis, and ECHO_HOST_MODE=path. The echo server listens on port 6001 and is configured against the same Redis instance. In other words, a captured request is written by the API, broadcast through Redis, and pushed to the Angular client over the echo server, which is why the UI can show requests as they arrive. The .env.example documents the alternative: BROADCAST_DRIVER=pusher with PUSHER_KEY, PUSHER_SECRET, PUSHER_APP_ID and PUSHER_CLUSTER for live reload through Pusher instead of a self-run echo server.

Running Webhook.site with Docker Compose on port 8084

The repository ships a docker-compose.yml that builds from the local Dockerfile by default. The comment above the image line says "Comment out next line to use prebuilt image", so the image webhooksite/webhook.site can be used instead of a local build. The compose file maps port 8084 on the host to port 80 in the container and sets APP_URL=http://localhost:8084, so the UI is reachable there once the stack is up.

docker-compose up -d

Three containers start: webhook-site, webhook-redis and laravel-echo-server. The compose file sets APP_ENV=dev and APP_DEBUG=true, which is a development configuration, not a production one. The database defaults to sqlite (DB_CONNECTION=sqlite), and the Dockerfile creates database/database.sqlite and runs php artisan migrate during the image build.

To exercise it, open http://localhost:8084 in a browser. The frontend issues a random URL, and anything sent to it appears in the request list. The compose file itself gives the queue worker as the application command:

php artisan queue:work --daemon --tries=3 --timeout=10

The README does not document the exact route shape for self-hosted instances, so use the URL the UI displays. If a request does not appear, check the queue worker container first: with QUEUE_DRIVER=redis, nothing is processed unless php artisan queue:work is running, which the compose file does for you.

What the open source build leaves out

The README is unusually direct about the split. It states that the open source, MIT-licensed version "can be self-hosted using e.g. Docker, is great for testing Webhooks, but doesn't include features like Custom Actions". Custom Actions, the graphical workflow editor, and WebhookScript, the scripting language for transforming and validating requests, are described in the README as capabilities of the product generally, but the open source section excludes Custom Actions specifically. Anyone whose use case is "transform this payload and re-send it somewhere else" should treat the self-hosted build as a request viewer, not a transformation engine.

A second constraint is operational. The compose file is written for development: APP_ENV=dev, APP_DEBUG=true, APP_LOG=errorlog, and SQLite as the database. The .env.example recommends Redis for the cache driver and syslog for logging when not in development, and mentions a Redis unix socket as "more performant", but the compose defaults do not follow that advice. There is no documented migration path here for running at scale, and the README does not discuss retention, storage limits, or what happens to captured requests over time. The Dockerfile also pins node:11 for the asset build stage and bkuhl/fpm-nginx:7.4 for the runtime, both old base images, so rebuilding the image means inheriting those versions.

Alternatives: request bins versus a self-hosted inspector

The closest alternatives are hosted request bins such as RequestBin-style services and Pipedream, which give you a URL and a web UI with no infrastructure to run. The difference in approach is where the data lives and what you can change. A hosted bin is someone else's server: you get the URL, you cannot inspect the queue, and you depend on their uptime. The self-hosted Webhook.site build puts the Laravel application, the Redis queue and the echo server on your own machine, which is the point if you are testing traffic you cannot send to a third party, or if you need the endpoint to survive a vendor outage.

Another alternative is writing the receiver yourself, a small Express or Flask route that logs the body. That is a few dozen lines and no Redis, but you then own the UI, the request history, and the live update mechanism. Webhook.site's value is that the display layer already exists. The trade-off is the reverse of the usual one: you are adopting a full Laravel application with three containers to avoid writing a twenty-line handler, and you get the older Angular 1.4 frontend and the node:11 build stage along with it.

Maintenance status, licence and upgrade cost

The repository is not archived, and the last push was on 2026-07-22, which is recent. That is the strongest maintenance signal available here. The release history is a different story: the newest listed release is 1.3 ("Version 1.3 LTS") from 2023-06-21, preceded by 1.2 in 2021 and 1.1 ("Version 1.1 Redis support") in 2018. Commits continue between releases, but tagged releases are years apart, so anyone pinning to a version tag should expect to sit on it for a long time.

On licensing, the two sources disagree and that matters for adoption. The README says the GitHub version is "completely open-source, MIT-licensed". The repository metadata reports NOASSERTION, which means GitHub could not classify the licence from the files present. Before shipping this inside a company, read LICENSE at the repository root and confirm the terms yourself; this is not a legal opinion, just a note that the two signals do not match.

Upgrade cost is dominated by the frontend toolchain. The asset build runs through gulp and laravel-elixir with node:11, and the runtime image is bkuhl/fpm-nginx:7.4. Moving to a current Node or PHP version means touching the Dockerfile's build stage and the composer constraints, not just bumping a tag. If you only need the request-capture behaviour, the prebuilt image avoids the node stage entirely.

Editorial conclusion

Adopt the self-hosted build if you need an internet-facing endpoint that logs requests without standing up your own API, and if you are comfortable running a Laravel app with Redis and a queue worker. Do not adopt it if you need Custom Actions, WebhookScript or the other features the README attributes only to the cloud version, and do not adopt it if you expect a maintained release cadence: the newest tag is 1.3 from 2023-06-21. Before you commit, verify the licence situation yourself, since the repository metadata reports NOASSERTION while the README calls the GitHub version MIT-licensed, and confirm that the docker-compose.yml defaults (APP_ENV=dev, APP_DEBUG=true, sqlite database, port 8084) are acceptable for your environment.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. webhooksite/webhook.site on GitHub