Instance-level MCP settings not persisting via UI (self-hosted Docker)

[Hugo_de_Groot]

After migrating from n8n Cloud to self-hosted, MCP settings do not persist when configured through the UI. This affects both:

1. Instance-level MCP (Settings → Instance-level MCP): I can enable MCP access, but after navigating away and returning, the toggle is reset to off.

2. Workflow-level MCP (Workflow Settings → “Available in MCP”): I can toggle it on, but after saving/publishing and reopening the workflow, the setting reverts to off.

Even re-publishing a workflow causes MCP access to be lost and it cannot be re-enabled because the setting won’t persist.

Important: Writing the MCP settings directly to the database via terminal does work, which confirms it’s a UI persistence issue, not a backend/database problem. However, this workaround is impractical because every workflow change requires manual database edits and container restarts.

Steps to reproduce

1. Go to Settings → Instance-level MCP

2. Enable MCP access → toggle turns on

3. Navigate away from the page

4. Return to Settings → Instance-level MCP → toggle is off again

Same behavior for workflow-level:

1. Open a workflow → Settings → toggle “Available in MCP” on

2. Save/publish the workflow

3. Close and reopen the workflow → toggle is off again

Expected behavior

MCP settings should persist after being toggled on, both at instance level and per workflow, without requiring direct database manipulation.

What is the error message (if any)?

No error message is shown. The UI accepts the toggle change without any visible error, but the setting simply doesn’t persist.

Information on your n8n setup

• n8n version: 2.8.3

• Database: SQLite (default)

• Running n8n via: Docker (docker-compose)

• Operating system: Ubuntu (VPS)

• Reverse proxy: Caddy

Docker-compose environment variables

yaml

environment:
  - N8N_HOST=<my-domain>
  - N8N_PORT=5678
  - N8N_PROTOCOL=https
  - NODE_ENV=production
  - WEBHOOK_URL=https://<my-domain>/
  - GENERIC_TIMEZONE=Europe/Amsterdam
  - N8N_PROXY_HOPS=1
  - N8N_DEFAULT_LOCALE=nl
  - EXECUTIONS_DATA_MAX_AGE=168
  - EXECUTIONS_DATA_PRUNE=true
  - N8N_RUNNERS_MODE=internal
  - N8N_RUNNERS_MAX_CONCURRENCY=5
  - NODE_OPTIONS=--max-old-space-size=1024

No MCP-related environment variables are set (confirmed via docker exec env | grep -i mcp). N8N_DISABLED_MODULES is not set.

Additional context

• Migrated from n8n Cloud (where MCP worked perfectly) to self-hosted

• All workflows were exported from Cloud and imported into self-hosted

• This appears to be the same issue reported by another user: Workflows not appearing in Instance-level MCP table after selection

• Instance-level MCP is still labeled as Beta, so this may be a known limitation

[A_A4]

Hi @Hugo_de_Groot

What you can reasonably do next

Based on n8n docs :

• Double‑check that the affected workflows are:

  • Published, not just saved as drafts.

  • Using one of the supported triggers (Webhook, Schedule, Chat, Form).

• Confirm that N8N_DISABLED_MODULES is truly unset in the running container (docker exec <container> env | grep N8N_DISABLED_MODULES), which you’ve effectively already done.

• If all of that is correct (and it sounds like it is), this falls outside what the public docs cover and is almost certainly a bug in 2.8.3’s MCP UI/API.

At this point, the only realistic path is to:

• Open an issue or support request with:

  • Your exact n8n version (2.8.3), DB type (SQLite), and deployment (Docker + Caddy).

  • A short reproduction (as you’ve written it).

  • The fact that direct DB updates persist correctly, which proves the backend and schema are fine and the problem is in the UI/API layer.

• Ask whether this matches the “Workflows not appearing in Instance-level MCP table after selection” bug you referenced and whether a fix is already in a newer version.

[jab-lure-unthawed]

Had the same problem today, 2.9.0 has a fix for it:

fix(editor): Fix mcp toggle in workflow settings by MiloradFilipovic · Pull Request #25630 · n8n-io/n8n · GitHub