Expose and Secure Your Self-Hosted n8n Workflows
n8n allows you to self-host, which is great when you're testing workflows, but when you're ready to turn your instance into a production-ready automation solution and don't want to buy a domain or pay for hosting, you might feel lost.
ngrok works with the self-hosted and enterprise editions of n8n, including both Docker and npm-based installs, to securely expose them to the public internet. That way, you can share n8n with colleagues or accept webhooks to fire off workflows.
1. Reserve a domain
Navigate to the Domains section of the ngrok dashboard and click New + to reserve a free static domain like https://your-n8n-instance.ngrok.app
or a custom domain you already own.
We'll refer to this domain as $NGROK_DOMAIN
from here on out.
2. Start your n8n endpoint
On the same system where n8n runs, start the agent on port 5678
, which is the default for n8n, and reference the n8n.yaml
file you just created.
Be sure to also change $NGROK_DOMAIN
to the domain you reserved earlier.
Loading…
3. Try out your n8n endpoint
Visit the domain you reserved either in the browser or in the terminal using a tool like curl
.
You should see the app or service at the port connected to your internal Agent Endpoint.
Optional: Secure your n8n dashboard with Traffic Policy
Even though n8n comes with built-in user administration, you can protect the sign-in page from automated attacks by restricting access to only trusted IPs.
Go to our IP address helper tool to get your public IP address.
Next, create a file named n8n.yaml
on the same system where n8n runs and paste in the following policy, replacing $YOUR_IP
.
Loading…
What's happening here?
This policy applies the restrict-ips
Traffic Policy action and allows only
devices with a matching IP address to access your n8n instance.
All other requests are denied at ngrok's network without reaching your service.
Restart your ngrok agent to apply the new policy.
Loading…
Optional: Enforce verification on incoming webhooks
If you want to receive webhooks from external services, but also want to control precisely which services can send these requests and during what conditions, you can use the verify-webhooks
action.
For example, if you want to verify a webhook from GitHub, create or edit a your n8n.yaml
file and paste in the policy below.
Replace $WORKFLOW_UUID
with your workflow's path and $SECRET
with the secret you configured when you created your webhook.
Loading…
What's happening here? This policy filters for only traffic that contains the specific /webhook/$WORKFLOW_UUID
path, then verfies that it both originates from GitHub (or another supported provider) and contains the appropriate secret.
Restart your ngrok agent to apply the new policy.
Loading…
Configure both IP restrictions and webhook verification
If you configured IP restrictions earlier, and then set up webhook verification, you'll find that your webhooks won't work because you haven't added the provider's IP to your restrict-ips
action to allow them.
Because it's next to impossible to identify all the IPs where a provider's webhooks might come from, it's easier to disable IP restrictions on the /webhooks/
path.
Edit your n8n.yaml
file with the policy below.
Loading…
What's happening here? This policy first verifies any incoming webhooks as before. Then, the policy applies IP restrictions to only traffic not to the /webhook/
path, which allows your webhooks provider's request to reach n8n successfully.
What's next?
- Watch our livestreamed n8n workshop to see this example deployed live.
- Read more about Traffic Policy, core concepts, and actions you might want to implement next.
- View your Ollama traffic in Traffic Inspector.