How to Re-Enable Chat Hub in n8n 3.0: Restore the Chat Section After Upgrade

Introduction

You upgraded a self-hosted n8n instance to 3.0, opened the editor, and the Chat section is gone. No error message explains it, no banner points to a setting, and the chat workflows you built around it have nowhere to receive messages. This tutorial restores Chat Hub in n8n 3.0 with one environment variable, verifies the fix, and sets a migration deadline, because the same change that disabled Chat Hub also schedules its full removal. It is written for self-hosters running Docker Compose, with notes for other deployment styles, and it assumes you can restart your n8n container.

Quick answer

Add chat-hub to the N8N_ENABLED_MODULES environment variable, for example N8N_ENABLED_MODULES=agents,chat-hub, recreate the container, and the Chat section returns with your stored sessions intact.

Evidence

n8n 3.0 is a cleanup release, and Chat Hub is one of the features it retires. The official breaking changes document states the change plainly: “n8n 3.0 turns off the Chat Hub module by default. The Chat section disappears from the navigation and the Chat Hub endpoints stop responding. Your chat sessions, agents, and messages stay in the database. n8n 4.0 removes the feature.” That single paragraph contains the whole diagnosis and the whole deadline: the disappearance is expected behavior, your data is safe, and the re-enable path below works only until version 4.0.

The same document adds a status note that matters for planning: “n8n 3.0.0 is currently available as an early access release.” As of October 31, 2026, that means the behavior described here is documented and final for the 3.x line, but the exact general-availability date can still move. Check the release notes before scheduling a production upgrade window, and treat the steps below as the documented path, not a workaround discovered by trial and error.

The scale of the 3.0 cleanup explains why Chat Hub was not singled out with a migration wizard. The release removes more than 35 legacy nodes and helpers, ends npm and npx installs for self-hosters, and tightens several security defaults, so Chat Hub is one retirement among many. Our n8n 3.0 upgrade checklist walks through the full list, and this guide covers the one item on it that looks like data loss but is not. For context on how widely n8n is deployed, the project repository recorded about 209,000 stars and 61,000 forks on GitHub as of October 31, 2026, which is why a quiet default change like this one affects a large self-hosting audience at once.

Two primary sources anchor every factual claim in this guide. The n8n 3.0 breaking changes document defines the Chat Hub behavior, the exact environment variable, and the 4.0 removal date. The n8n environment variables reference documents how self-hosted configuration works, including where variables like N8N_ENABLED_MODULES belong. A third source, the n8n update guide, covers the upgrade mechanics that surround this fix, such as pulling a new image and recreating the container.

Prerequisites

• A self-hosted n8n instance on version 3.0, or a 2.x instance you are about to upgrade.
• Docker Compose deployment (the steps translate to any setup where you control environment variables, see Step 5 for the alternatives).
• Shell access to the host that runs the container, and permission to restart it.
• A backup of your workflows and credentials, or at least an exported workflow JSON for every chat workflow. Our self-hosted n8n update guide covers the backup step if you have not done it yet.
• Five minutes of downtime tolerance, because recreating the container briefly stops executions.

Step-by-step guide

Step 1: Confirm Chat Hub is the problem, not a failed upgrade

Before changing configuration, confirm the symptoms match the documented behavior. Open your n8n editor and look at the left navigation. If the Chat section is missing entirely, while workflows, credentials, and executions all load normally, that matches the 3.0 default exactly. If instead the whole editor fails to load, or workflows are missing, you have a different problem, such as a failed database migration, and the variable below will not fix it.

On a 2.x instance that you have not upgraded yet, open Settings, then Migration Report. The official document names this report as the place to see how the change affects every instance that uses Chat Hub, before you upgrade. Note which workflows use Chat Hub, so you can test exactly those workflows after the fix instead of clicking around the whole instance.

Step 2: Find where your container gets its environment variables

Open the docker-compose.yml file that starts n8n. Look for the environment: block under the n8n service. A typical self-hosted file looks like this:

services:
  n8n:
    image: n8nio/n8n:3.0.0
    environment:
      - N8N_HOST=n8n.example.com
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=your-encryption-key
    volumes:
      - n8n_data:/home/node/.n8n

If your file uses an env_file: line instead, the variables live in that file, and that is where the new variable goes. The rule is simple: edit the file that actually feeds the container, not a copy of it. Editing a compose file in a different directory is the most common reason this fix appears to fail.

Step 3: Add chat-hub to N8N_ENABLED_MODULES

The variable holds a comma-separated list of enabled modules, so keep every module you already enable and append chat-hub. The official document gives the canonical example:

environment:
  - N8N_ENABLED_MODULES=agents,chat-hub

If your file already sets N8N_ENABLED_MODULES to something else, add chat-hub to that existing list rather than adding a second line. Docker Compose applies the last duplicate entry, so a second N8N_ENABLED_MODULES line would silently replace the first one and could disable a module you rely on, such as agents. If your file does not set the variable at all, add the example line as shown, keeping any modules your deployment already needs.

Save the file. Do not restart the container yet, because a plain restart does not pick up compose file changes.

Step 4: Recreate the container and verify the variable landed

Recreating the container is the step people skip, and it is the step that makes the fix real. A plain docker compose restart reuses the existing container with its old environment, so it cannot apply a compose file edit. Run this from the directory that holds your docker-compose.yml file:

docker compose up -d

Compose detects the changed environment, recreates the n8n container, and starts it with the new variable. Wait for the container to report healthy, then confirm the variable actually reached the process:

docker compose exec n8n env | grep N8N_ENABLED_MODULES

You should see N8N_ENABLED_MODULES=agents,chat-hub (or your own list including chat-hub). If the output is empty, the variable is not reaching the container, and the troubleshooting section below covers the likely causes. Do not move on until this check passes, because every later check depends on it.

Now open the n8n editor and look at the left navigation. The Chat section should be back. Open it and confirm your previous chat sessions, agents, and messages are listed, as the official document promises. Then open one chat workflow that used Chat Hub and run a test message through it end to end, so you verify behavior, not just navigation.

Also check the startup logs once, because n8n prints a deprecation warning for Chat Hub at startup while the module is re-enabled:

docker compose logs n8n | grep -i "deprecat" | head -20

Seeing that warning is expected, not a sign of failure. It is the reminder that this module has an expiry date, which the final step addresses.

Step 5: Adapt the fix to non-Compose deployments

If you do not use Docker Compose, the variable is the same, only its home changes. With plain Docker, pass it on the run command with -e N8N_ENABLED_MODULES=agents,chat-hub, and remember that a container created without the flag keeps its old environment until you recreate it. With a systemd unit, add Environment=N8N_ENABLED_MODULES=agents,chat-hub under the Service section, run systemctl daemon-reload, then restart the service. With any other process manager, set the variable in the environment that launches the n8n process, not in a shell you open by hand, because a hand-set variable disappears when that shell closes. In every case, verify with the equivalent of the env | grep check above before declaring the fix done.

Step 6: Plan the migration before n8n 4.0

Re-enabling Chat Hub buys time, it does not cancel the removal. n8n 4.0 removes the feature entirely, and no environment variable will bring it back. Use the 3.x window to decide what replaces it for each chat workflow.

The practical replacement depends on what Chat Hub did for you. If Chat Hub was the inbox where a team chatted with agents, a chat trigger workflow behind your own chat frontend, or a messaging integration such as Slack or Telegram, can take over that role, and those paths are supported long term. If Chat Hub was a testing convenience while building agents, the workflow chat testing built into the editor covers that need without a separate module. Inventory each Chat Hub workflow, pick its replacement, and migrate one workflow at a time while the old module still runs, so a failed migration never strands a production conversation. When the last workflow is off Chat Hub, remove chat-hub from N8N_ENABLED_MODULES and recreate the container again, so the deprecation warning disappears and your configuration matches the supported 4.0 shape ahead of time.

Troubleshooting

The Chat section is still missing after recreating the container

This almost always means the variable never reached the process. Run the docker compose exec n8n env | grep N8N_ENABLED_MODULES check from Step 4. If it prints nothing, you edited the wrong compose file, edited an env file that the compose file does not reference, or ran docker compose up -d from a different directory than the one holding the file. Find the file with docker compose config | grep -A2 N8N_ENABLED_MODULES, which prints the merged configuration Compose actually used, then edit that source and recreate again.

The variable is set, but another module stopped working

You probably replaced the module list instead of appending to it. N8N_ENABLED_MODULES is a full list, not an add-only flag, so setting it to chat-hub alone disables every module that was previously enabled by default or by your earlier configuration, including agents. Fix it by writing the complete list, for example N8N_ENABLED_MODULES=agents,chat-hub, then recreate the container. Re-check the affected module immediately, because this mistake is silent: n8n starts fine, and only the missing module reveals it.

Chat Hub is back, but old chat sessions look empty

First, confirm you are looking at the same instance and database volume as before the upgrade. Chat sessions live in the n8n database, so a container recreated against a fresh volume, or pointed at a different database, shows an empty Chat Hub even with the module enabled. Check that your compose file still mounts the original data volume, such as n8n_data:/home/node/.n8n, and that no second n8n container is running against a different volume. If the volume is correct and sessions are still missing, restore from the pre-upgrade backup before making further changes, because continued use on the wrong database can overwrite the data you are trying to recover.

The startup log shows a deprecation warning for Chat Hub

That warning is the intended behavior, not an error to fix. It appears because Chat Hub is deprecated in the 3.x line and scheduled for removal in 4.0, and n8n prints it on every startup while the module is enabled. Do not silence it by removing the variable unless you have already migrated, because removing the variable disables Chat Hub immediately. Treat the warning as your migration countdown and work through Step 6 before the 4.0 upgrade.

You upgraded from an npm install and cannot find a 3.0 image step

n8n 3.0 no longer supports installations run with npm or npx, and the 3.0 line does not publish a runnable npm package. There is no environment variable that fixes an npm-based 3.0 install, because that install path no longer exists. Migrate to a Docker-based deployment first, following our npm to Docker migration guide, then apply the Chat Hub variable in the Docker configuration. If you are still on 2.x with npm, Chat Hub still works there, and the migration report will flag it before you upgrade.

FAQ

The FAQ entries in this article’s front matter answer the questions readers ask most: why Chat Hub vanished, whether old sessions survive, how long the re-enable lasts, whether restarts preserve it, whether Cloud users can use it, and whether to check before upgrading. Read those answers before opening a support thread, because the official document already settles each one.

Conclusion

Chat Hub did not break in n8n 3.0, it was switched off by design, and one environment variable switches it back for the whole 3.x line. Set N8N_ENABLED_MODULES to include chat-hub, recreate the container rather than merely restarting it, verify the variable with the env check, and confirm your stored sessions return. Then use the time you bought to migrate before n8n 4.0 removes the feature for good. Next, work through our n8n 3.0 upgrade checklist for the rest of the breaking changes, and our complete n8n guide if you are planning a larger self-hosting refresh alongside the upgrade.

Frequently asked questions