External services operate on their own schedule. They do not know that you have closed your laptop, restarted Docker, switched to a mobile connection, or finished work for the day. When an event occurs, they simply send the webhook.
A local development environment works differently. It usually runs only when a developer needs it. At any given moment, it may be offline, unreachable, or not yet ready to accept requests.
This creates a fundamental mismatch: an external system that can send events at any time is trying to communicate with an environment that is available only intermittently.
Tunneling tools make a local machine reachable from the internet, but they still assume that the tunnel and the application are running when the webhook arrives. If the laptop is off, the connection drops, or the application has not started yet, what happens to the request?
You could provision a VPS, configure a domain and HTTPS, add a message queue, and build your own delivery infrastructure. You could even deploy the entire setup to Kubernetes.
But do you really need production-grade infrastructure just to debug one webhook handler locally?
Why a standard tunnel may not be enough
Tunneling services solve an important problem: they create a route from the public internet to an application running on your machine.
While the tunnel is active, the flow is straightforward:
External service → tunnel → local application
The problem begins when the connection disappears. If the laptop is off, the internet connection drops, or the tunnel client stops running, there is no longer a working route to the local application.
Some webhook providers retry failed deliveries, but relying on those retries alone can be risky. The external service controls the retry policy: how many attempts it makes, how long it waits between them, and when it gives up. One provider may retry for several hours, while another may not retry at all.
A tunnel provides connectivity, but connectivity does not necessarily include request storage or deferred delivery. Restoring your internet connection does not guarantee that a webhook missed during the outage will be sent again.
How Adal approaches the problem
Adal does not try to keep your local machine permanently available. Instead, it separates two independent responsibilities: receiving the webhook and delivering it to your local environment.
External service → Adal Server → Adal CLI → local application
The request first arrives at the public HTTPS URL of an Adal Server. The Server can accept it regardless of whether the developer’s laptop is currently connected.
Once accepted, the request is stored in the selected region. Adal records its method, path, query parameters, headers, and body. The retention period depends on the selected plan and begins when the request is accepted. You can find the details in the data storage and retention documentation.
When Adal CLI reconnects, Adal delivers pending requests to it if Deliver pending requests on connect is enabled for the Server. Requests can wait for delivery only while they remain within their retention period.
A Destination can point to the base address of a local application, for example:
http://127.0.0.1:3000
Adal forwards the original method, path, query parameters, headers, and body without hidden transformations.
Your laptop may be temporarily unavailable, but the public webhook URL remains online and ready to receive requests.
Example: debugging a payment integration while traveling
Suppose a developer is testing a handler for a payment.completed event.
The payment provider sends the following request:
POST /webhooks/payment.completed
Content-Type: application/json
{
"payment_id": "pay_123",
"status": "completed"
}
At that moment, the developer’s laptop is offline.
With a standard tunnel, the request cannot reach the local application. What happens next depends entirely on whether the payment provider retries the delivery and when that retry occurs.
With Adal, the flow is different:
The payment provider sends the webhook to the permanent URL of an Adal Server.
Adal accepts the request and stores it in the selected region.
The developer gets back online and starts Adal CLI, or the running CLI reconnects automatically.
If delivery of pending requests is enabled, the CLI forwards the waiting request to the local handler.
The delivery result becomes available in the delivery history.
There is no need to repeat the test payment or wait for the payment provider’s next delivery attempt.
The same workflow can help in many other situations:
developing a Telegram bot without losing a test message;
debugging GitHub events such as
pushorpull_request;connecting a website form to a CRM;
testing order, delivery, or subscription notifications;
working with an internal service that is available only from a local or corporate network.
When running your own VPS is too much
A VPS can receive webhooks while your laptop is offline. It is a perfectly reasonable choice for permanent infrastructure or complex request processing.
But a virtual server alone does not provide the complete workflow. You will usually need to:
rent and configure the VPS;
connect a domain and configure DNS;
install a reverse proxy;
configure TLS certificate issuance and automatic renewal;
set up a firewall;
deploy an application that receives requests;
implement storage and deferred delivery;
configure logging and monitoring;
install security updates;
monitor the availability of the entire system.
If the server also needs to buffer webhooks while the local machine is unavailable, you will need a queue or another form of intermediate storage. A basic reverse proxy cannot hold a request until your laptop reconnects.
A small webhook debugging task can quickly turn into a separate infrastructure project.
What if you have a static IP address?
Another option is to receive webhooks on a machine at home. That requires a public IP address, router configuration, open ports, a domain, and HTTPS. The machine must also remain powered on and reachable around the clock.
Even a static IP address does not eliminate every risk. Residential internet providers generally optimize their networks for consumer access, not for hosting public services.
One member of our team encountered this firsthand. Their provider moved the connection to a different plan and changed the IP address in the process. Services still pointing to the previous address stopped working. Diagnosing the problem took longer than expected because an IP address change seemed like one of the least likely causes.
Router restarts, maintenance windows, restrictions on incoming connections, and the lack of hosting-grade availability guarantees add further points of failure.
When a VPS or Kubernetes does make sense
The point is not that you should never run your own infrastructure.
A VPS makes sense when you need to host a persistent webhook processor, control the complete runtime environment, or operate several related services.
Kubernetes may be appropriate when you already have a cluster and need orchestration, scaling, resilience, automated deployments, and consistent management across many components or teams.
For local development of a single webhook handler, however, you usually do not need:
a cluster;
an ingress controller;
a separate message queue;
a public IP address;
a reverse proxy;
your own TLS certificate management.
Sometimes the entire requirement is simply to receive a request and deliver it to a local application.
Tunnel, VPS, or Adal?
| Requirement | Standard tunnel | Self-managed VPS | Adal with CLI |
|---|---|---|---|
| Public HTTPS endpoint | Yes, while the tunnel is active | Yes, after configuration | Yes |
| Receives requests while the laptop is off | Usually not | Yes | Yes |
| Waits for the local environment to reconnect | Usually not | Must be implemented | Built in |
| Request history | Depends on the service | Must be implemented | Built in |
| Server administration | Not required | Required | Not required |
Delivery to localhost |
Yes, while the tunnel is active | Requires an additional mechanism | Through Adal CLI |
| Suitable for hosting a persistent application | Usually not | Yes | The CLI is designed primarily for local and private environments |
The right choice depends on the job.
If you only need to expose a local port briefly, a tunnel may be enough. If you are hosting a persistent application, managing your own infrastructure may be appropriate. If you need to receive webhooks while a laptop is offline, store them, and deliver them to a local environment later, Adal provides that workflow without requiring a separate server.
Getting started
You can set up a local Adal workflow in three main steps:
Create an Adal account.
Create a Server in the appropriate region and add an Adal CLI Destination pointing to your local application.
Download Adal CLI and run it with the generated token:
adalcli --token <your-cli-token>
Once connected, the CLI begins forwarding new webhooks to the configured local address. Accepted requests and delivery results are available in the Adal dashboard.
To receive requests that arrived while the CLI was disconnected, enable Deliver pending requests on connect in the Server settings.
The complete setup process is available in the Adal quickstart guide.
Infrastructure should match the problem
Webhook senders need a stable public endpoint. Local applications need a way to receive requests. Connecting the two does not always require a self-managed VPS, let alone Kubernetes.
For many development workflows, the simpler approach is to separate receipt from delivery. Adal receives the webhook while the local environment is unavailable, and Adal CLI forwards it once the connection is restored.
Sometimes the best way to simplify infrastructure is not to build it where running a CLI is enough.