Allowing external users to use CHAT nodes without exposing the n8n login screen

[DeveloperNameHere]

Allowing external users to use CHAT nodes without exposing the n8n login screen

Esentially - i am currently self hosting n8n and attempting to develop some workflows that can be used as a custom made agent/LLM by folks via the use of chat nodes.
I’ve seperated my UI access to n8n on a private domain, and set webhooks to use a public domain - exactly to have that security split and make sure nobody can access anything but what is absolutetly necceseary from the outside.

Webhook calls worked just fine, but the chat links once opened from outside the local network just gave dev tool errors of 403 and dropping the websockets connection.
As it turns out, that is because of my Reverse Proxy that blocks anything but mypublicdomain.si/webhook and /webhook-test.

I consulted the docs and got the information that fundamentally it is not possible to allow the use of chat nodes this way so that they are publically accesible without ALSO allowing access to the entire rest of your n8n app to the public - including the ui access and login screen, which is of course going against the fundamental cybersecurity level i wish to attain.

So my question is; Is there any way to achieve the split i am looking for? Or do i just… have to put my entire n8n on to the public web with 2FA in between / give people access to them via VPN?

Thank you for the read and your time.

[hoiyothaheem]

Yes, you can absolutely achieve this setup! The key is configuring your reverse proxy to allow specific chat-related paths while keeping the rest of n8n private. Here’s how:

Solution: Selective Path Exposure via Reverse Proxy

The paths you need to expose publicly for chat nodes:

1. /webhook-test/chat/* - For chat webhook endpoints
2. /webhook/chat/* - For production chat endpoints
3. /rest/oauth2-credential/callback - If using OAuth in your chat workflows (optional)
4. WebSocket upgrade support for the above paths

Example Nginx Configuration:

server {
    listen 443 ssl;
    server_name mypublicdomain.si;

    # Allow only specific webhook paths
    location ~ ^/(webhook-test|webhook)/chat/ {
        proxy_pass http://your-private-n8n:5678;
        proxy_http_version 1.1;
        
        # Critical: WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Disable buffering for chat streaming
        proxy_buffering off;
    }

    # Block everything else
    location / {
        return 403;
    }
}

Example Apache Configuration:

<VirtualHost *:443>
    ServerName mypublicdomain.si

    # Enable WebSocket proxying
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule ^/(webhook-test|webhook)/chat/(.*) ws://your-private-n8n:5678/$1/chat/$2 [P,L]

    # Allow chat webhook paths
    <LocationMatch "^/(webhook-test|webhook)/chat/">
        ProxyPass http://your-private-n8n:5678
        ProxyPassReverse http://your-private-n8n:5678
        
        ProxyPreserveHost On
        RequestHeader set X-Forwarded-Proto "https"
    </LocationMatch>

    # Block everything else
    <Location "/">
        Require all denied
    </Location>
</VirtualHost>

Example Caddy Configuration (simpler):

mypublicdomain.si {
    # Allow only chat webhooks
    handle /webhook-test/chat/* {
        reverse_proxy http://your-private-n8n:5678
    }
    
    handle /webhook/chat/* {
        reverse_proxy http://your-private-n8n:5678
    }
    
    # Block everything else
    handle {
        respond 403
    }
}

Important Notes:

1. WebSocket Support is Critical: The 403 error and dropped connections you’re seeing are because your reverse proxy isn’t handling WebSocket upgrades. Chat nodes require WebSocket for real-time communication.

2. n8n Environment Variables: Make sure your n8n instance has:

   N8N_WEBHOOK_URL=https://mypublicdomain.si/
   WEBHOOK_URL=https://mypublicdomain.si/
   

3. No Need for VPN or 2FA on Public Domain: With this setup, you’re only exposing the chat endpoints, not the UI or any admin functionality. This is secure.

4. Testing: When you access your chat URL from outside, it should look like:
   https://mypublicdomain.si/webhook/chat/your-workflow-id

Alternative: Embed Chat Widget

If you want even more control, you can embed the chat using the n8n chat widget on your own website:

<script type="module">
  import { createChat } from 'https://cdn.jsdelivr.net/npm/@n8n/chat/dist/chat.bundle.es.js';
  createChat({
    webhookUrl: 'https://mypublicdomain.si/webhook/chat/your-workflow-id'
  });
</script>

This approach keeps everything on your domain and gives you full styling control.

Let me know if you need help with a specific reverse proxy configuration!

[Wouter_Nigrini]

You could run 2 instances as well where one is used to edit your workflows and the other is purely for chat and webhook executions. On the instance you want to expose the chat and webhooks, but not have the UI accessible, you can set this env var

N8N_DISABLE_UI=true

Deployment environment variables | n8n Docs

You could also have a look at this documentation to separate the ui and backend completely, however this involves some manual build

Configure the Base URL for n8n's front end access | n8n Docs

[DeveloperNameHere]

Heyo, this worked! Thank you so much!

I had tried to do this exact thing on my own but was running into issues.
Now, i’ve got it figured out and it seems to be working just as i wanted

Thank you so much for the exhaustive and in-depth reply!

Likewise for the other fellow below, thank you both very much