flowtemplates

n8n · troubleshooting · verified on n8n 2.25.7, 6 September 2026

n8n secure cookie error

If n8n replaces its editor with a page that reads “Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari,” the server is fine and your data is fine. n8n marks its authentication cookie Secure, so the browser refuses to send that cookie over a plain http:// origin, and without the cookie n8n cannot start a session. Three fixes, in n8n’s own order of preference: put TLS in front of it, open it on http://localhost:5678 instead of a LAN IP or hostname, or set N8N_SECURE_COOKIE=false — which n8n itself labels “not recommended”.

The variable is documented as Boolean, default true, “Ensures that cookies are only sent over HTTPS, enhancing security.” Nothing about this error is specific to your workflows, your database or your version.

The exact message, and where it comes from

The screen has no n8n styling — a 🚫 emoji, one heading and a three-item list — because it is not part of the app. n8n writes it with document.write before the editor mounts. The full text, from n8n’s English string file:

Your n8n server is configured to use a secure cookie, however you are
either visiting this via an insecure URL, or using Safari.

To fix this, please consider the following options:
  · Setup TLS/HTTPS (recommended), or
  · If you are running this locally, and not using Safari,
    try using localhost instead
  · If you prefer to disable this security feature (not recommended),
    set the environment variable N8N_SECURE_COOKIE to false

Copied from the keys settings.authCookie.insecureConnection.title, .fixIntro and .option.* in n8n’s i18n source, read on 6 September 2026. The text is routed through n8n’s translation layer, but the only locale file in the n8n repository is en.json, so this screen normally appears in English whatever your browser language is.

Which of the two causes is yours

The message names two, and they need different answers.

  • An insecure URLYou opened n8n at http:// on something that is not loopback: a LAN address like http://192.168.1.50:5678, a server hostname, a Tailscale name, or a domain whose proxy is not terminating TLS. Everyone on the team hits it, in every browser. Fix 1 or fix 2.
  • SafariOnly Safari users hit it, and http://localhost:5678 does not save them — the message explicitly says “and not using Safari”. Chrome and Firefox on the same machine load the editor fine. Fix 1 or fix 3.

A one-command check that tells you what the server thinks, before you change anything:

curl -s http://localhost:5678/rest/settings | grep -o '"authCookie":{[^}]*}'

On n8n 2.25.7 started with -e N8N_SECURE_COOKIE=false, that command returned {"secure": false} for us on 6 September 2026. If it still says true after you set the variable, the variable never reached the process — check that it is on the container and not on the shell, and that you recreated the container rather than restarting it.

The three fixes

Fix 1 — put TLS in front of n8n (n8n’s own first recommendation)

The warning’s first bullet is “Setup TLS/HTTPS (recommended)”. Any reverse proxy with a certificate — Caddy, Traefik, nginx + certbot, a cloud load balancer — makes the origin https:// and the cookie is sent normally. This is the only fix that keeps the session cookie protected in transit, and the only one you should use for an instance other people can reach.

Fix 2 — reach it on localhost instead of an IP or hostname

The warning’s second bullet is “If you are running this locally, and not using Safari, try using localhost instead”. Browsers treat locally-delivered origins as potentially trustworthy: MDN states that http://127.0.0.1, http://localhost and http://*.localhost “are not delivered using HTTPS, but they can be considered to have been delivered securely because they are on the same device as the browser.” So http://localhost:5678 works while http://192.168.1.50:5678 — the same server, same port — trips the warning. If n8n runs on another machine, an SSH tunnel turns it back into a localhost URL.

ssh -N -L 5678:localhost:5678 you@your-server
# now open http://localhost:5678 in the browser on your own machine

Fix 3 — set N8N_SECURE_COOKIE=false (n8n labels this “not recommended”)

The third bullet reads: “If you prefer to disable this security feature (not recommended), set the environment variable N8N_SECURE_COOKIE to false”. The docs list the variable as Boolean with default true and describe it as “Ensures that cookies are only sent over HTTPS, enhancing security.” Turning it off means your n8n session cookie travels in clear text — acceptable on a laptop, not on anything reachable from a network you do not control.

docker run -it --rm -p 5678:5678 \
  -e N8N_SECURE_COOKIE=false \
  -v ~/.n8n:/home/node/.n8n n8nio/n8n

Rule of thumb: if anyone but you can reach the URL, fix 1. If it is your own machine and you just want the editor open, fix 2. Reach for fix 3 only when the instance is bound to your own host and you accept that the session cookie is unprotected.

After the editor opens

This error blocks the editor, not the runtime — scheduled workflows kept running the whole time, and webhook URLs were unaffected. Once you are back in, two adjacent problems are worth knowing about, because both look like “n8n is broken” and neither is: a production webhook that answers “The requested webhook … is not registered”, and the editor refusing a workflow file with “Could not import file”.

If you are setting up the server for the first time, our self-hosted n8n guide covers the install and the environment variables around this one, and the free n8n templates are a fast way to confirm the instance really works end to end — the API fetch template needs no credentials at all.

Sources and last verified

Reproduced on n8n 2.25.7 in Docker on 6 September 2026; every quoted string was read from the pages below on the same day. If n8n’s docs and this page disagree, n8n wins — write to support@flowtemplates.app and we will re-verify.

Frequently asked questions

What does the n8n secure cookie error mean?

It means the n8n server is configured to mark its authentication cookie Secure, so the browser will only send that cookie over an HTTPS origin — and you opened the editor over plain HTTP (or in Safari, which n8n’s own message calls out separately). Without the cookie n8n cannot log you in, so it replaces the whole page with the warning instead of showing a broken editor.

Why do I only see a 🚫 and one paragraph instead of the n8n interface?

The warning is written with document.write before the Vue application mounts, which is why it replaces the entire page and carries no n8n styling. The source comment in settings.store.ts says exactly that: the structural markup and inline styles stay in code “because this is written via document.write before the Vue app mounts”.

Why does http://localhost:5678 work but http://192.168.1.50:5678 does not?

Because browsers treat loopback origins as potentially trustworthy even without TLS. MDN’s secure-contexts page says http://127.0.0.1, http://localhost and http://*.localhost “can be considered to have been delivered securely because they are on the same device as the browser.” A LAN IP is not loopback, so the Secure cookie is dropped and n8n shows the warning.

Is it safe to set N8N_SECURE_COOKIE=false?

n8n marks this option “not recommended” in the warning itself. It is defensible on a machine only you can reach — a laptop, a Docker container bound to 127.0.0.1 — because the cookie never leaves the host. It is not defensible on a VPS, a LAN box other people use, or anything behind a plain-HTTP tunnel, because the session cookie is then readable by anyone on the path.

How can I check what my instance is actually configured to do?

n8n publishes the setting in its unauthenticated settings endpoint. On n8n 2.25.7 we ran the instance with N8N_SECURE_COOKIE=false and curl http://localhost:5678/rest/settings returned an authCookie object containing "secure": false. With the variable unset the default is true, per the docs table. This is the quickest way to tell whether your environment variable actually reached the process.

Does N8N_SAMESITE_COOKIE cause the same screen?

No — it is a separate variable. The docs list N8N_SAMESITE_COOKIE as an enum of strict, lax and none with a default of lax, controlling cross-site cookie behaviour; the docs note that the none value itself requires HTTPS. If you are embedding the editor in another page and losing the session there, that is the variable to look at, not N8N_SECURE_COOKIE.