Comparison to huginn

Is there a comparison to huginn somewhere?

GitHub - huginn/huginn: Create agents that monitor and act on your behalf. Your agents are standing by!

I am wondering about the state of integrations, oauth support, deployment requirements and just the general approach.

Hello,

welcome to the community!

Sorry, there is no comparison yet. I wanted to create a few different ones for a while but sadly is there currently always to much other stuff to do, that I did not get to it yet.

However, you can see all the integrations which currently exist here:

n8n does currently not have OAuth-Support yet. It is however planned. To deploy n8n not much is needed except a system with Docker or Node.js installed. That can be even done locally in combination with our tunnel to make n8n web-accessible (however only recommended for testing & development) or on any server. CPU and memory depend mainly on how much workflows you want to run in parallel and what they do. But let’s say at least something like 0.5 CPUs and 256 MB RAM. By default, it uses SQLite but also supports Postgres (recommended) and Mongo.

Not sure how to answer the question about the general approach. Never really used huginn to compare n8n to it.

If you have any other questions. Simply get back to me.

Thanks for the quick response. I’ve already had a look at the nodes list - but how well they are supported feels a little vague.

I am currently looking at a deployment route to give n8n a try. Unfortunately the auth aspects are a little concerning. It would be much easier if the admin interface would be possible to have on a different port than the webhooks.

Having all those credentials just secured by just a basic auth sounds like terrible idea. Of course a path based switch and stronger auth is possible when using e.g. nginx in front - but that makes the setup more involved.

How do you run it in production?

1 Like

To just give a try I would recommend just running it locally with the build-in tunnel. It is quite simple with docker or Node.js npx n8n start --tunnel.

If you activate authentication it uses that authentication only for the UI. The webhooks bypass it and have their own (if activated, on a per webhook basis).

I for example currently use Docker Swarm with traefik and also another one with Kubernetes.

Locally I’ve already tried n8n (albeit without the tunnel). So far I am liking it. But my point was that I don’t want the web UI only secured by basic auth publicly available. With the web UI on the same port as the webhooks it’s a bit more finicky. IMO it would be great to separate the two servers.

Do you mind sharing your traefik config?
I was just looking into that and it isn’t as straightforward as I hoped.

Ah yes as long as you do not want to use webhooks from external services no tunnel is needed. Great to hear that you like it!

Are there any security issues with basic auth? I thought always that it is still quite secure.

Here the basic swarm traefik setup:
https://keybase.pub/janober/swarm-setup.zip

Here also basic docker-compose setup:
https://keybase.pub/janober/compose-setup.zip

Both not tested in that exact configuration. But should theoretically work and should get you 95% there. If something is wrong please inform me. That I can fix it. Thanks!

I have mine working with traefik and the following compose file:


version: '2.2'

services:
  n8n:
    image: n8nio/n8n 
    restart: always
    container_name: n8n 
    restart: always
    networks:
      - traefik_proxy
    ports:
      - 5678:5678
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.${DOMAIN_NAME}`)"
      - "traefik.http.routers.n8n.tls=true"
      - "traefik.port=5678"
      - "traefik.docker.network=traefik_proxy"
      - "traefik.http.middlewares.n8n.headers.SSLRedirect=true"
      - "traefik.http.middlewares.n8n.headers.STSSeconds=315360000"
      - "traefik.http.middlewares.n8n.headers.browserXSSFilter=true"
      - "traefik.http.middlewares.n8n.headers.contentTypeNosniff=true"
      - "traefik.http.middlewares.n8n.headers.forceSTSHeader=true"
      - "traefik.http.middlewares.n8n.headers.SSLHost=${DOMAIN_NAME}"
      - "traefik.http.middlewares.n8n.headers.STSIncludeSubdomains=true"
      - "traefik.http.middlewares.n8n.headers.STSPreload=true"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /home/bruno/n8n/.n8n:/root/.n8n
    environment:
      - N8N_HOST=n8n.${DOMAIN_NAME}
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - VUE_APP_URL_BASE_API=https://n8n.${DOMAIN_NAME}/
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=USER
      - N8N_BASIC_AUTH_PASSWORD=PASS
networks:
  traefik_proxy:
    external:
      name: traefik_proxy
  default:
    driver: bridge

2 Likes

@brunoamaral Thanks a lot!

1 Like

Cool. So many options to pick from :slight_smile:
I got a first version working with caddy now.

version: '3.1'
services:
  n8n:
    image: n8nio/n8n
    restart: always
    ports:
      - 5678:5678
    volumes:
      - ./vol/n8n:/root/.n8n
  web:
    image: abiosoft/caddy
    restart: always
    ports:
      - 443:443
    links:
      - n8n
    volumes:
      - ./vol/caddy:/root/.caddy
      - ./cfg/Caddyfile:/etc/Caddyfile

Maybe it’s possible to also get rid of the tiny config file - but I will also try the traefik version.

How important is it do set these env variables? On a first glance in non-production it seems to work OK without:

  NODE_ENV: "production"
  N8N_HOST: "demo.example.com"
  N8N_PROTOCOL: "https"
  N8N_PORT: "443"
  VUE_APP_URL_BASE_API: "https://demo.example.com/"
  GENERIC_TIMEZONE: "Europe/Berlin"
  EXECUTIONS_DATA_SAVE_ON_SUCCESS: "none"

PS: As for Basic Auth:

@tcurdt Great to hear that you got it working!

Information about the most mention environment variables you can find here:

The other ones like host, port, … get then, for example, important once you want to use webhooks as they get used to create the Webhook-URLs to display it to you in the Editor-UI and to create them in the backend for external services like Github.

Thanks a lot for the link about BasicAuth. It was never meant to be a long-term solution and will be changed in the future for sure. Sadly because my resources are very limited I do not know when I get to it.