Your application is already running. The database is in place, deployments are routine, and monitoring tells you how the system is doing. Then a new integration calls for receiving or sending HTTP requests through a different region.
It sounds like a small addition: rent a VPS and route webhooks through it. But your usual provider has no presence there. Another provider's pricing or signup requirements don't work for you. And even if the machine handles only a few events an hour, someone still has to patch it, secure it, and monitor it.
Before adding another server, identify which part of the integration actually needs to run in that region. Often, it is just webhook reception or delivery. Your application and database can stay where they are.
A small VPS comes with ongoing work
A virtual machine gives you compute resources and control over the environment. A working webhook service still needs to run on top of it.
A public receiver needs HTTPS, access controls, and monitoring. If the destination goes offline, the service needs to retain the event and deliver it later. If a request times out, you need a record of the attempt to understand what happened.
The cost includes both hosting and maintenance. Even a lightly used machine is part of your production infrastructure, with updates, credentials, disk space, and failures to account for.
Add a second or third country, and those responsibilities multiply. For a modest webhook workload, the question becomes: how much infrastructure do you need to maintain for this one regional requirement?
Separate where webhooks arrive, run, and leave
A webhook integration involves several locations:
Reception: the public address where an external service sends an event.
Storage: the region where the request and its history are retained.
Processing: the application that performs the business operation.
Sending: the region from which an outgoing HTTP request reaches the recipient.
These can all be in the same place, but they do not have to be.
A public receiver can run in one region while the handler runs inside a private corporate network. For outgoing webhooks, an application can hand a message to a delivery service in a selected region without moving its own infrastructure.
This lets you add regional capabilities incrementally. You choose the geography of each flow without first relocating the application and database.
Receive in a selected region and deliver to your existing application
For incoming webhooks, create a Server in Adal Cloud in one of the available regions. Then configure the external service to send events to the Server's permanent HTTPS URL.
The Server accepts a Request and, with storage enabled, retains it in the selected region. Adal Cloud then delivers it to the configured Destination: a public HTTP service or a private environment connected through Adal CLI.
External service
→ Server in your chosen Adal Cloud region
→ application in your infrastructure
If the application runs on a private network, Adal CLI runs inside that network and establishes a secure outbound connection. The handler needs neither a public IP address nor an open inbound port. This works for local development as well as production services on private networks.
Consider a team whose webhook handler already runs in its own infrastructure. A new integration needs a regional receiving endpoint. The team creates a Server in a suitable Adal Cloud region and configures delivery to the existing handler. There is no additional regional VPS, operating system, or forwarding service for the team to maintain.
Reception and processing remain separate steps. The dashboard shows the accepted Request and the outcome of delivery. Temporary destination failures follow the configured retry policy. To deliver pending Requests when the CLI connects, enable Deliver pending requests on connect; those Requests must still be stored and within their retention period.
Send through a selected region with Adal Outbound
The requirement may run in the other direction: your application needs to send webhooks to customers or partners through a particular region.
Adal Outbound handles this flow. Your application selects an available region and submits the recipient's URL, HTTP method, headers, and request body. Adal Cloud handles delivery and retries, and keeps the attempt history in that region.
Your application
→ Adal Outbound in your chosen region
→ recipient's public HTTP service
A 202 Accepted response means the message has been accepted for delivery. The outcome of the request to the recipient is recorded separately in the attempt history. Your application can hand off delivery to Adal Cloud, while your team can check how it turned out.
Outbound operates independently of incoming Servers in Adal Cloud. You do not need to create a receiving endpoint or move your application to the sending region first.
This is useful when different integrations call for different sending regions. The region is an explicit choice for each submission; Adal Cloud does not select it automatically. The recipient must have a public HTTP or HTTPS address.
Use multiple regions without deploying your application in each one
A practical starting point for multi-region architecture is choosing where individual operations happen.
One flow can receive events in one region, while another uses a different region. Your application can send messages through selected Adal Outbound regions. Where the handlers run remains a decision for your application's architecture.
Adding a regional integration therefore does not have to begin with provisioning another machine. Webhook reception, storage, and delivery become a separate part of the system, with a location you can choose.
Regional choice and redundancy are separate capabilities. Having several regions does not, by itself, imply data replication, automatic transfer of accepted requests, or failover during an outage. Adal Outbound does not provide automatic failover between regions. Handling an unavailable region requires a separate plan.
What does “unavailable” mean for your integration?
If you cannot rent a VPS from your usual provider but Adal Cloud offers the region you need, you can use the service for the regional part of your webhook integration.
If Adal Cloud does not yet offer that region either, the existing regional options will not meet that requirement. Tell us which location you need and whether you want to receive webhooks, send them, or both. We will assess whether we can support it. Availability and launch timing for any new region need to be confirmed individually.
If “unavailable” means a network outage, look at the specific connection that is failing. For incoming webhooks, the sender must be able to reach the Server in Adal Cloud. For outgoing messages, your application must be able to submit to the selected region. Regional delivery cannot remove those connectivity requirements.
The scope of the service matters, too. Adal Cloud handles webhooks; it does not provide a virtual machine for arbitrary application code or a database. If the requirement is to host an entire service in a particular region, a regional webhook URL alone will not satisfy it.
Consider the full request path
Before configuring a region, establish where requests should be received, where they should be stored, and where they will go next.
If a Request is stored in one region and then delivered to a handler in another country, its data passes through both environments. Selecting a storage region in Adal Cloud does not keep the rest of the request's journey within that region.
The same principle applies to latency. A receiver closer to the sender may shorten one part of the route, but total processing time also includes delivery to your application and the handler's own work. Measure the complete path with your actual integration.
Account for retention when storing requests, and keep signature verification and idempotent processing in the handler. Choosing a region changes where delivery happens. It does not remove the possibility of duplicate events.
Start with the flow you need
When a VPS in the required region is expensive or difficult to obtain, first identify the job it would perform. For regional webhook reception, create a Server in Adal Cloud and configure a Destination that points to your existing application. For outgoing delivery, choose an Adal Outbound region.
Your integrations can then expand into available regions as requirements emerge, without adding a VPS for every webhook flow.
Follow the quickstart to set up incoming delivery. For outgoing messages and region selection, see the Adal Outbound documentation.