Webhooks don’t care that your laptop is offline

Local development environments and webhook senders operate on completely different schedules.

Your application runs when you need it. It may stop when you close your laptop, restart Docker, lose your internet connection, or finish work for the day.

A webhook provider does not know any of that. When an event occurs, it sends the request.

So what happens when your local application is unavailable?

A tunnel only works while the tunnel is running

Tunneling tools provide a convenient route from the public internet to a local application:

Webhook provider → tunnel → local application

This works well while the tunnel, internet connection, and application are all running.

If any part of that path becomes unavailable, the request cannot reach your handler. Some providers retry failed webhooks, but they control the retry schedule. You do not decide how many attempts they make, how long they wait, or when they give up.

A tunnel provides connectivity. It does not necessarily provide durable request storage or deferred delivery.

You could build the infrastructure yourself

One solution is to rent a VPS and build an intermediate webhook receiver.

That usually involves:

• configuring DNS and HTTPS;
• running a reverse proxy;
• storing incoming requests;
• implementing retries and deferred delivery;
• setting up logs and monitoring;
• installing security updates;
• keeping the entire system available.

You could deploy those components to Kubernetes as well.

That may be appropriate for a production platform, but it is a lot of infrastructure when the original requirement was simply:

Receive a webhook now and deliver it to my local application later.

Separating receipt from delivery

This is the problem we designed Adal to solve.

Instead of making the local machine permanently accessible, Adal separates webhook receipt from local delivery:

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, including its method, path, query parameters, headers, and body.

When Adal CLI connects, it forwards requests to a configured local Destination such as:

http://127.0.0.1:3000

If Deliver pending requests on connect is enabled, requests received while the CLI was offline can be delivered after it reconnects, as long as they are still within the plan’s retention period.

A simple example

Imagine testing a payment.completed webhook while traveling.

The payment provider sends the event while your laptop has no connection. With a standard tunnel, delivery depends on whether the provider retries after you are back online.

With Adal:

1. The provider sends the webhook to the Adal Server.
2. Adal accepts and stores the request.
3. Your laptop reconnects and Adal CLI starts or reconnects.
4. The CLI forwards the pending request to your local handler.
5. You inspect the delivery result in the Adal dashboard.

There is no need to repeat the test payment just to generate the same event again.

The same workflow can help when developing bots, testing GitHub events, debugging CRM integrations, or connecting services available only inside a private network.

Use infrastructure that matches the problem

Tunnels, VPS instances, and Kubernetes all have valid use cases.

Use a tunnel when you need temporary public access to a running local port. Use a VPS or Kubernetes when you need to host and operate persistent applications.

But if the problem is receiving webhooks while a local environment is unavailable, you may not need to build an entire delivery system yourself.

Sometimes you need webhooks—but not Kubernetes.

You can try the workflow using the Adal quickstart guide.

Read the complete article: When You Need Webhooks but Not Kubernetes