We needed reliable local webhooks, not more infrastructure

While building webhook integrations, we kept running into the same mismatch.

External services can send events at any time. Local development environments are available only when a developer is actively working.

Your laptop may be offline. Docker may be restarting. The local application may not be running yet. But the webhook provider does not know that—it simply sends the request.

The obvious solutions came with trade-offs

A tunneling service can expose a local port to the internet, but the tunnel still depends on the laptop, internet connection, and application being available when the webhook arrives.

We could also run our own VPS. That would mean configuring DNS, HTTPS, a reverse proxy, request storage, retries, monitoring, and security updates.

And yes, we could deploy the whole thing to Kubernetes.

All of those approaches are valid in the right context. But they felt excessive when the original requirement was simply:

Receive the webhook now and deliver it to the local application later.

The idea behind Adal

This problem shaped one of the core ideas behind Adal: webhook receipt and local delivery should be separate operations.

The resulting flow is simple:

Webhook provider → Adal Server → Adal CLI → local application

An Adal Server provides a permanent public HTTPS endpoint. When it accepts a webhook, it stores the request in the selected region.

Adal CLI connects the Server to a local or private application. If the laptop is offline when the webhook arrives, the request can wait until the CLI reconnects, subject to the configured delivery settings and retention period.

This means developers do not have to keep a tunnel running continuously or repeat an external action just to generate the same webhook again.

For example, if a payment provider sends a payment.completed event while the developer is offline, Adal can receive it first and deliver it to the local handler later.

What we learned

The useful part of this approach is not replacing every tunnel, VPS, or Kubernetes cluster.

It is recognizing when infrastructure is solving a larger problem than the one you actually have.

A tunnel is useful when you need temporary public access to a running local port. A VPS or Kubernetes makes sense when you need to host and operate persistent applications.

But when the requirement is delayed delivery to a local environment, separating receipt from delivery can remove a surprising amount of infrastructure.

We are still developing Adal and refining this workflow. We would be interested to hear how other founders and developers handle webhooks during local development:

• Do you rely on provider retries?

• Do you keep a tunnel running?

• Have you built your own webhook receiver?

• Or do you simply repeat the original event when something gets lost?

Read the complete article: When you need webhooks but not kubernetes