Set Up n8n on Port 5678 with Localtonet

How the n8n and Localtonet setup works

n8n is a fair-code, self-hostable platform for workflow automation and AI agents. Its official quick start provides the docker.n8n.io/n8nio/n8n image, maps the application to host port 5678, and stores application data in a named Docker volume.

Docker and Localtonet perform different jobs. Docker starts the n8n application and controls which host interfaces can accept connections to port 5678. The Localtonet client then establishes an outbound connection to one of our relay servers and forwards an assigned public HTTPS address to that already working HTTP service. This workflow does not require inbound router port forwarding, a public IP address, VPN setup, or an inbound firewall rule for internet traffic.

The separation is useful for diagnosis. If n8n does not respond directly on the address that the Localtonet client will use, creating a tunnel cannot repair the container or its Docker port mapping. Always test the local or LAN target first, then create the tunnel.

Prerequisites and deployment decisions

This tutorial follows the official n8n Docker quick-start model. Before beginning, install Docker using the supported installation path for the host operating system and start the Docker engine. You also need a browser, a Localtonet account, and a Localtonet client running on a device that can reach n8n.

The most important decision is where the Localtonet client will run. Installing it on the same host as Docker allows n8n to remain bound to IPv4 loopback at 127.0.0.1:5678. Running the client on a separate machine requires n8n to listen on an address reachable over the local network, which changes the firewall and access-control requirements.

Check that Docker is available

docker --version
docker info

The first command reports the Docker client version. The second confirms that the client can communicate with the engine. If docker info reports a connection or permission error, resolve it before creating the n8n container. Depending on the host, the Docker service may be stopped, the desktop application may still be starting, or the current user may not have permission to access Docker.

Check whether port 5678 is already in use

Docker cannot publish a host address and port already occupied by another listener. Check currently running containers first:

docker ps

If Docker later reports that port 5678 is already allocated, determine whether an earlier n8n container or another application owns it. Do not stop an unfamiliar process until you understand its purpose.

Choose how to install n8n

Choose the correct Docker network binding

Docker's short publication syntax has an important security consequence. The official n8n example uses -p 5678:5678. Unless Docker or the host has been configured differently, omitting the host IP publishes port 5678 on all host interfaces, commonly represented as 0.0.0.0:5678 for IPv4 and potentially an IPv6 listener as well.

That mapping still allows http://localhost:5678 to work, but it is not loopback-only. Other devices may be able to connect directly to the Docker host over the LAN if routing and host firewall policy permit it. A public tunnel is not what creates that LAN exposure. The Docker publication already determines direct network reachability.

Same-host layout: bind n8n to loopback

This is the preferred layout for this tutorial. Docker and the Localtonet client run on the same machine, so n8n does not need a LAN listener. Publish the container through IPv4 loopback:

-p 127.0.0.1:5678:5678

The browser and Localtonet client on that host can reach http://127.0.0.1:5678. Devices elsewhere on the LAN cannot normally connect to that loopback listener directly.

Separate-client layout: permit only the necessary LAN path

If the Localtonet client must run on another device, loopback will not work because 127.0.0.1 always refers to the device making the connection. n8n must be published on an interface reachable from the client.

Docker can bind a publication to a specific host address using this form:

-p <n8n-host-lan-ip>:5678:5678

Replace the placeholder with the actual stable LAN address assigned to the n8n host. If you retain the upstream -p 5678:5678 form, understand that Docker normally publishes on all host interfaces rather than only the LAN interface you intended.

From the separate client device, test the target that will be entered in Localtonet:

curl -I http://<n8n-host-lan-ip>:5678

A successful HTTP response shows that the selected device can reach n8n. A timeout usually points to routing, address selection, or firewall policy. A connection refusal usually means no listener is available at that address and port.

Install n8n manually with Docker

The official upstream quick start contains the following commands:

docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

This is the documented upstream example, and it is useful for understanding n8n's expected image, volume, and port. However, -p 5678:5678 should not be described as loopback-only. For the preferred same-host Localtonet layout, use the explicit loopback adaptation below.

docker volume create n8n_data

docker run -it --rm --name n8n -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

What the Docker options mean

Verify n8n on port 5678

Open the local browser endpoint

For the loopback-bound deployment, open:

http://127.0.0.1:5678

The page should show the n8n interface or the first-run experience provided by the installed version. Using 127.0.0.1 here tests the exact IPv4 loopback target that Localtonet will use.

Request the endpoint from a terminal

curl -I http://127.0.0.1:5678

An HTTP response confirms that an application is listening and responding. A connection-refused error usually means the container stopped, the port was not published, or the wrong address was tested.

Confirm the container and publication

docker ps

Look for the container named n8n and verify its port publication. For the same-host layout, the host side should identify 127.0.0.1:5678. If the container is absent, inspect the terminal that launched it. Because the command includes --rm, a stopped container is removed automatically.

Confirm that the volume exists

docker volume ls

The output should include n8n_data. This confirms that the Docker volume object exists, but it does not test whether a backup can be restored.

Operate and restart the quick-start container

The quick-start command is interactive. It does not run detached, define a restart policy, or retain a stopped container. Those choices make initial setup easy to inspect, but they are not a complete unattended-service design.

Stop n8n

In the terminal attached to docker run, use the terminal interrupt appropriate to the environment, commonly Ctrl+C. Docker stops n8n and removes the container because --rm was specified. The named data volume remains separate.

Start the same-host deployment again

docker run -it --rm --name n8n -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Reusing the same volume name and mount path reconnects the replacement container to the existing n8n data. Verify the editor after every restart before assuming the tunnel or a workflow callback is healthy.

Plan upgrades deliberately

Restarting a container and upgrading n8n are different operations. Before changing the image version, review the release guidance for the intended n8n version, confirm compatibility, and create a tested backup. A persistent volume does not provide automatic rollback if an application upgrade changes stored data.

For an unattended or important deployment, evaluate deliberate restart behavior, service monitoring, image version pinning, backup retention, upgrade testing, logging, database architecture, and recovery procedures. The compact command in this guide is an installation and integration baseline rather than a universal production design.

Install and prepare the Localtonet client

Install the Localtonet client on the Docker host when possible. The client application must run on the device selected for the tunnel and must be able to reach the configured n8n address.

Localtonet provides client applications for supported operating systems, but the supplied verified evidence does not include current platform-specific package names, installation commands, executable paths, or service-start commands. Those details can change between client versions and packaging methods, so we do not invent commands here.

Create and start the Localtonet HTTP tunnel

Use an HTTP tunnel because n8n exposes an HTTP web application on port 5678. The HTTP process types provide a public HTTPS address for that local content. Available choices, relay servers, and plan-specific capabilities can vary, so select from the values currently shown in your account.

The following sequence keeps the process-type decision, device selection, server selection, target configuration, tunnel creation, Start action, and endpoint verification separate. Creating a tunnel does not start it.

For the maintained dashboard workflow, see the Localtonet HTTP tunnel documentation. If you use a custom domain, follow the current DNS instructions shown by Localtonet rather than assuming a record type or destination from an older guide.

Configure public editor and webhook URLs

Opening the editor remotely and registering an inbound production webhook are related but different tasks. The editor URL tells users and browser-facing parts of n8n where the public interface is located. The webhook URL controls the public base address n8n uses when it displays or registers callback endpoints for webhook-driven workflows.

If you only need temporary browser access to the editor, the basic tunnel may be sufficient. If an external service must call an n8n webhook, configure n8n with a stable public HTTPS base URL and then verify the exact callback URL generated by the Webhook node or trigger integration.

Understand the relevant n8n settings

Choose and start the public address first

Start the Localtonet HTTP tunnel and copy its assigned HTTPS URL from the dashboard. Use the exact scheme and hostname. The examples below use https://your-public-host.example only as a placeholder. Replace it with the public address assigned to your running tunnel.

Production webhook registrations should use an address expected to remain stable. A temporary generated URL is useful for testing, but changing, stopping, or replacing that public URL can invalidate callback addresses already stored by external services.

Recreate the quick-start container with public URL settings

Docker environment variables are fixed when a container is created. Restarting an existing container does not add variables that were absent from its original configuration. In this tutorial the container uses --rm, so stop it and run a replacement container with the same n8n_data volume plus the public URL variables.

For the same-host, loopback-bound layout:

docker run -it --rm --name n8n \
  -p 127.0.0.1:5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e WEBHOOK_URL=https://your-public-host.example/ \
  -e N8N_EDITOR_BASE_URL=https://your-public-host.example/ \
  -e N8N_PROXY_HOPS=1 \
  docker.n8n.io/n8nio/n8n

Replace the placeholder host with the exact Localtonet HTTPS hostname. Preserve the n8n_data volume mapping so the replacement container uses the existing application data. If your shell does not support backslash line continuation, enter the same options on one line using the syntax supported by that environment.

For a separate-client design, replace only the host side of the port publication with the intentionally selected LAN address:

-p <n8n-host-lan-ip>:5678:5678

After recreation, verify the local endpoint again, confirm that the Localtonet client can reach it, and restart the tunnel if necessary.

Verify the public editor URL

1. Open the configured N8N_EDITOR_BASE_URL in a private browser session.
2. Confirm that the request uses HTTPS and the expected Localtonet hostname.
3. Confirm that n8n presents its normal authentication flow rather than anonymous administrative access.
4. Sign in and verify that ordinary editor navigation remains on the intended public hostname.

Verify the webhook URL generated by n8n

Add or open a workflow that uses n8n's Webhook node or another trigger that displays a callback URL. n8n distinguishes test and production webhook behavior:

• The test URL is intended for development while the editor is actively listening for a test event.
• The production URL is intended for ongoing callbacks after the workflow is activated.
• The exact path is generated by n8n. Do not construct it by guessing.

Inspect the URL displayed by n8n. Its scheme and hostname should match the configured public Localtonet address, not localhost, 127.0.0.1, a container address, or a private LAN address.

Run an end-to-end callback test

Security and production considerations

A successful tunnel establishes connectivity, not authorization. Localtonet forwards the selected HTTP service, while n8n remains responsible for its accounts, workflow permissions, integration credentials, and application-level controls.

Protect the editor

Complete the supported n8n owner or account setup before sharing the public URL. Use strong, unique credentials and limit administrative access. Do not embed credentials in URLs, screenshots, workflow names, or webhook test data.

Apply least privilege to workflow credentials

Workflows may call databases, cloud services, messaging platforms, code repositories, and internal APIs. Grant each n8n credential only the permissions its workflow requires. Keep Localtonet device tokens separate from n8n integration credentials because they serve different purposes and have different security boundaries.

Minimize direct network exposure

Prefer the same-host loopback design. If the Localtonet client is separate, bind Docker to the necessary LAN interface where practical and restrict host firewall access. Do not add router port forwarding for port 5678 as part of this workflow.

Do not confuse the HTTP tunnel with a VPN

This setup publishes one HTTP service. It does not expose an entire private network and is not a VPN connection. Localtonet VPN Manager is our separate private mesh VPN feature.

Troubleshoot common setup problems

Docker cannot connect to the engine

If docker info fails, n8n has not started. Start the Docker service or desktop application and resolve local permissions. A Localtonet tunnel cannot forward an application that is not running.

Docker reports that port 5678 is already allocated

Run docker ps and check whether an existing container already publishes the selected address and port. If an earlier n8n instance is running, test it before starting another copy. A binding conflict can also be specific to the selected host IP, so compare the complete publication rather than only the port number.

The container starts and then disappears

The quick-start command includes --rm. When n8n exits, Docker removes the stopped container. Read the first error in the attached terminal. Image retrieval failures, occupied ports, daemon problems, invalid options, and data-directory errors require different remedies.

The browser reports connection refused

Confirm that the terminal running n8n remains open, run docker ps, and test:

curl -I http://127.0.0.1:5678

For a separate-client design, also test the LAN address from the Localtonet client device. A loopback test on the Docker host does not prove that the separate device can connect.

n8n is unexpectedly reachable from another LAN device

Check whether the container was started with -p 5678:5678. That form normally publishes on all host interfaces. Stop the quick-start container and recreate it with -p 127.0.0.1:5678:5678 if Localtonet runs on the same host. If a separate client is required, use an intentional interface binding and restrictive firewall policy.

Local access works, but the public URL does not

1. Confirm that n8n still responds on the exact configured local target.
2. Confirm that the selected Localtonet client is connected.
3. Confirm that the tunnel is started, not merely created.
4. Verify the selected Process Type, device token, relay server, local IP address, and port 5678.
5. If the client is separate, repeat the direct LAN test from that device.
6. Open the currently assigned public HTTPS URL.

The editor works publicly, but n8n displays localhost webhook URLs

Recreate the container with the correct WEBHOOK_URL and N8N_EDITOR_BASE_URL values. Confirm that the public URL includes https:// and that the webhook base includes the expected trailing slash. Environment variables must be present when the container is created.

The webhook URL is public, but callbacks fail

Confirm that the external service uses the production URL displayed by n8n rather than the test URL. Verify that the workflow is active, the tunnel is running, and the registered hostname still matches the current Localtonet endpoint. Then inspect the n8n execution history and the sender's delivery result.

If requests reach n8n but client-address or forwarded-request behavior is incorrect, verify N8N_PROXY_HOPS against the real proxy chain. Do not increase it arbitrarily.

Webhook callbacks stopped after the tunnel changed

External services may still have the old callback URL registered. Start the intended stable tunnel, confirm n8n's current production webhook URL, and update the external service. Send another controlled event to verify the complete path.

Data appears missing after recreation

Confirm that the replacement command includes the original mount:

-v n8n_data:/home/node/.n8n

A missing mount or differently named volume gives the new container a different storage context. Stop before deleting anything, inspect existing volumes, and determine which volume belongs to the deployment.

The public endpoint stops when the host is idle

Check whether the n8n terminal closed, the Docker engine stopped, the host entered sleep mode, the Localtonet client disconnected, or the tunnel was stopped. Both n8n and the tunnel must remain active. For unattended operation, use a deliberately supervised deployment rather than relying indefinitely on an attached terminal.

Frequently asked questions