Connect external webhook providers to local n8n workflows without opening inbound network ports
An n8n instance running on localhost can receive requests from your browser, but payment platforms, source control systems, messaging services, and other webhook providers cannot reach that private address. In this guide, we explain the networking model behind the problem and show how an outbound Localtonet HTTP tunnel can provide a public HTTPS endpoint for a local n8n service. We also distinguish n8n's internal listening address from its public webhook address, cover tunnel lifecycle behavior, and provide practical security guidance for development and testing.
Why localhost webhooks cannot receive public events
When n8n runs on a developer workstation, home server, or private lab device, it normally listens on an address that is reachable only from that device or its local network. An address such as http://localhost:5678 refers to the loopback interface of whichever machine is making the request. If a remote webhook provider tries to call that address, localhost refers to the provider's own system, not to your n8n installation.
Private LAN addresses create a similar limitation. An address in a private network range may work from another device on the same network, but it is not directly routable from the public internet. Network address translation, router rules, firewalls, and the absence of a public IP can all prevent an unsolicited inbound request from reaching n8n.
A webhook provider therefore needs a publicly reachable URL. It stores that callback URL and sends an HTTP request when an event occurs. The request must reach the n8n Webhook node at the correct path, method, and environment. n8n distinguishes between test and production webhook URLs, so developers must also register the URL that matches how the workflow is currently being used.
The local listening address tells n8n where it is available inside your machine or network. The public webhook address tells external services where they can send events. Creating a tunnel does not automatically update every URL generated or stored by n8n. Review the current n8n deployment documentation for the public webhook URL setting that applies to your installation method.
How a Localtonet HTTP tunnel fits into the request path
With Localtonet, the client application runs on the device that can reach n8n. The client establishes an outbound connection to a Localtonet relay server. The HTTP tunnel supplies a public URL and forwards requests arriving at that URL to the configured local IP address and port.
This outbound model means the workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. n8n remains on the local device, while the public tunnel endpoint gives an external provider a route to the configured service.
The request flow is straightforward: a provider sends an HTTPS request to the public URL, the Localtonet relay receives it, the active tunnel carries it to the selected client device, and the client forwards it to the local n8n target. n8n then matches the request to the appropriate webhook path and starts the workflow if the node and workflow are in the required state.
Test URLs, production URLs, and stable callbacks
n8n's Webhook node provides separate test and production URLs. A test URL is intended for workflow development and is registered when n8n is listening for a test event or executing an unpublished workflow in the applicable test mode. It is useful when you want to inspect incoming data directly while building the workflow.
A production URL is used after the workflow is published or activated according to the n8n version and workflow model. Production executions are generally reviewed through n8n's execution history rather than appearing directly in the editor as test input. Registering the wrong URL with a provider is a common reason for a request to reach n8n without triggering the expected workflow.
Many providers retain a callback URL until it is manually changed. For that reason, the public address should remain consistent for as long as the provider is expected to use it. A random subdomain may be convenient for short tests, but do not assume that a generated address will remain unchanged across every tunnel replacement or configuration change. Where a consistent address is required, review the currently available Custom Sub Domain or Custom Domain options. Exact DNS requirements for a custom domain should always be checked against current Localtonet documentation before changing records.
| Address or mode | Primary purpose | Important behavior |
|---|---|---|
| Local n8n address | Access from the host or private network | External providers cannot use a localhost address to reach your machine. |
| n8n test webhook URL | Capturing events during workflow development | The test listener must be active under the conditions defined by n8n. |
| n8n production webhook URL | Triggering a published or active workflow | The workflow must be in the appropriate production state, and the provider must use the production path. |
| Localtonet random subdomain | Temporary testing and development | It serves the configured local content over a public HTTPS address while the client and tunnel are running. |
| Custom subdomain or custom domain | Callbacks that need a deliberately selected public name | Support and configuration requirements must be confirmed in the current dashboard and documentation. |
How to create the Localtonet HTTP tunnel
First, confirm that n8n is already running and reachable from the device where the Localtonet client will run. Use the actual local IP address and port appropriate for your deployment. A containerized n8n service may have different reachability rules from a process running directly on the host, so test the local address from the client's network context before creating public access.
Install and run the Localtonet client
Install our client on the device that can reach the local n8n service. Keep n8n running and verify that its local address responds before continuing.
Authenticate or select the device
Use the device-specific authentication token to identify the client that will run the tunnel. Treat this token as a credential. Do not place it in source code, screenshots, webhook payloads, or shared configuration files.
Select an available relay server
Choose an available server or region from the current Localtonet dashboard. Server codes and available locations can change, so obtain the value from the product rather than copying a hardcoded value from an old tutorial.
Create the HTTP tunnel configuration
Select the HTTP tunnel family, choose the appropriate Process Type, and set the target to the local IP address and port where n8n is reachable. Random Sub Domain, Custom Sub Domain, and Custom Domain all serve the configured content at a public HTTPS address.
Start the tunnel and use the public URL
Press Start after reviewing the target. Tunnel creation alone does not make the endpoint available. Once started, use the assigned public URL as the external base address and combine it with the correct n8n test or production webhook path.
Stop or delete access when it is no longer needed
Stop the tunnel after a temporary test or delete it when the configuration is no longer required. The public route works only while the selected client is connected and the tunnel is running.
For the current product workflow and available options, review the Localtonet HTTP tunnel documentation before configuring a long-lived callback or custom domain.
An HTTP tunnel forwards requests to the configured local web service. Depending on n8n's routes and deployment configuration, using the service root as the target may make more than a single webhook path reachable through the public URL. A tunnel is not an authorization boundary. Protect n8n with its supported security controls, restrict webhook access where possible, and verify exactly what the public address exposes before sharing it.
Configure and test the n8n webhook carefully
Set the public webhook base address
n8n must know the externally reachable base URL if you want it to generate webhook URLs that use the tunnel address rather than localhost. The exact configuration depends on whether n8n runs through Docker, Docker Compose, npm, or another supported deployment method. Use the current n8n deployment documentation for your installation and restart or reload n8n if that configuration requires it.
Avoid copying an environment-variable example without checking your deployment. Quoting, persistence, container recreation, and trailing-slash handling can differ among shells and orchestration files. After applying the setting, inspect the URL displayed by the Webhook node and confirm that it begins with the expected Localtonet HTTPS address.
Choose the correct webhook mode
Use the test URL while building a workflow and activate n8n's test listener before sending the event. Use the production URL only after the workflow is ready and in the state n8n requires for production registration. Confirm that the provider's configured HTTP method matches the Webhook node. n8n supports standard methods including GET, POST, PUT, PATCH, DELETE, and HEAD, but the provider and node must agree.
Send a controlled test event
Start with a non-sensitive sample payload. Verify the response status at the provider, inspect the corresponding n8n execution, and confirm that the payload reached only the intended workflow. If the provider reports a timeout, check the response mode selected in the Webhook node. A provider that expects a fast acknowledgement may not tolerate waiting for a long workflow to finish.
If no execution appears, troubleshoot the path in order. Confirm that n8n responds locally, the Localtonet client is connected, the tunnel is running, the public base URL is correct, the test listener or production workflow is active, and the HTTP method and path match. This sequence separates local application failures from tunnel lifecycle issues and webhook registration mistakes.
Security checklist for public n8n webhooks
Treat every webhook as untrusted input, even when the URL is known only to a small team. Validate data before using it in database queries, shell commands, file operations, notifications, or downstream API calls. Apply least privilege to credentials used by the workflow so that a malformed or forged event cannot perform unrelated actions.
Also consider response content. Returning complete workflow output may disclose internal identifiers, error details, or transformed data to the caller. Select the n8n response mode and response body that the provider actually requires. A minimal acknowledgement is often safer than returning the output of every downstream node.
Standard Localtonet HTTP tunneling publishes a configured local web target through a public address. It should not be described as private VPN access. Our separate VPN Manager feature provides private mesh VPN functionality and granular firewall rules, but it is not required for the public webhook workflow described here.
Frequently asked questions
Why can a webhook provider not call my local n8n URL?
A localhost address exists only within the machine making the request. Private LAN addresses are also not generally routable from the public internet. The provider needs a public endpoint that can route its request to your local n8n service.
Does creating a Localtonet tunnel make it active immediately?
No. Creating the configuration does not mean the tunnel is running. You must press Start, and the selected client device must remain connected. You can later stop or delete the tunnel.
Should I register the n8n test URL or production URL?
Use the test URL while actively listening for a development event. Use the production URL for a published or active workflow. The correct choice depends on the workflow state and the current n8n behavior, so verify the URL shown in the Webhook node before registering it with the provider.
Does the Localtonet tunnel automatically secure my n8n webhook?
The HTTP tunnel provides public connectivity to the configured target, but it does not replace application-level authorization. Configure supported n8n authentication, validate provider signatures or secrets where available, restrict source access when practical, and limit the permissions of workflow credentials.
Will the n8n webhook remain reachable if my computer sleeps?
No reliable forwarding can occur when the selected device is offline, asleep, disconnected, or no longer running the client. The n8n service must also remain available, and the tunnel must be in the running state.
Do I need router port forwarding, a public IP, or a VPN?
Not for this Localtonet HTTP tunnel workflow. Our client establishes an outbound connection to a relay, so the setup does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Connect your local n8n webhook with Localtonet
Run our client on the device that can reach n8n, create an HTTP tunnel for the correct local target, and start the tunnel when you are ready to test external events. Review the public endpoint carefully and apply n8n authentication and validation before sharing the callback URL.
Get Started Free →
