Changelog | n8n Docs n8n Docs ⌘Ctrlk ForumChangelogMore Get started Deploy Build Nodes Connect Administer Contribute n8n Docs Changelog Release notes Release notes 2.xArchived Release notes 1.xArchived Release notes 0.xArchived v3.0 Breaking changes v2.0 Breaking changes v2.0 Migration tool v1.0 Migration guide On this page For the complete documentation index, see llms.txt. This page is also available as Markdown. Copy On this page Changelog Changelog Every n8n release moves the platform forward. The changelog is where we call out the changes that matter most to the technical teams who build on n8n: new capabilities, more control over how your workflows run, and clearer visibility into what they're actually doing. Each entry is tied to the version it shipped in, newest first, and written to stand on its own, so it's easy to share the one update your team has been waiting for. Use this page alongside n8n's other release resources depending on what you need: Changelog (this page): a curated, narrative summary of the most important new features as they're rolled out. Release notes: a listing of all feature-level updates in each release. GitHub releases: full change detail of each release, linked to commits, including bug fixes and minor changes. Old-style release notes pages for 2.x, 1.x, and 0.x remain archived. Everything in the 2.x archive is covered by this changelog and the Release notes. Stable and Beta versions n8n releases a new minor version most weeks. The stable version is for production use. beta is the most recent release. The beta version may be unstable. To report issues, use the forum. Current stable: 2.34.5 Current beta: 2.35.2 Return webhook responses of any size from your workers Released: 2026-08-04 in n8n 2.34 Your queue mode workers can now return a webhook response however large the payload. In queue mode the worker runs the execution, but the client that made the request stays connected to the main or webhook instance, so a response from a Respond to Webhook node has to travel back through the queue. Redis holds the whole response while that message is in flight, which is why n8n caps it at 64 MiB by default (N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX). A response that serialized to more than that failed the node: a wide result set from a database query, a batch of aggregated API calls, or a CSV or XML document assembled in the workflow. Set N8N_WEBHOOK_RESPONSE_RELAY_OFFLOAD_ENABLED=true on your workers and n8n stores a response body above that limit in binary data storage instead. The queue message then carries only a reference, the main instance streams the body from storage to the client, and n8n deletes the stored copy once it delivers the response, so nothing accumulates. Redis memory stays flat no matter how large the response gets. Offloading needs a N8N_DEFAULT_BINARY_DATA_MODE that stores data (any mode except default) and storage that every instance can read. n8n recommends s3 or azure, since both stream the body a chunk at a time. Only a main instance running n8n 2.34.0 or later can read an offloaded body, so the variable ships turned off: upgrade your main and webhook instances first, then enable it on your workers. Refer to Large webhook responses for the full configuration, upgrade order, and troubleshooting. Read and write SharePoint Excel workbooks directly in n8n Released: 2026-07-28 in n8n 2.33 You can now read and write Excel workbooks stored in SharePoint document libraries, including files shared through Microsoft Teams sites, using the new Microsoft Excel (SharePoint) node. This gives you direct access to workbook data without needing separate authentication or intermediate steps to retrieve file contents. The node supports two authentication methods: sign in as a person using a Microsoft OAuth2 credential with the Sites.ReadWrite.All (or Sites.Read.All) scope, or sign in as an app using a Microsoft Entra Service Principal credential for unattended workflows that require no user interaction. Learn more in the Microsoft Excel (SharePoint) node documentation. Capture who approved and when in human-in-the-loop steps Released: 2026-07-07 in n8n 2.30 You can now get a full audit trail for every human-in-the-loop step in your workflows. Every Send and Wait node across Slack, Telegram, Discord, WhatsApp, Google Chat, Gmail, Outlook, Email/SMTP, Microsoft Teams, and the Chat Trigger node now includes a respondedAt ISO-8601 timestamp in its output the moment n8n receives a response. No configuration is required: the field appears automatically alongside the existing approved, text, or form fields and does not change the output shape for existing workflows. For Slack and Telegram, you can go further with the new Advanced Interactivity options on the Send and Wait for Response operation. Approvers respond with a single tap or click inside the app itself, and the node output records who responded: their ID, name, username, and (for Slack, when scopes allow) email, plus the channel and message ID. You can restrict which users are allowed to approve by listing their IDs in Restrict Who Can Approve. Anyone not on the list gets a private notice you can word yourself, and the workflow keeps waiting. You can also control what happens to the message after a decision with the After Decision setting: show the outcome and remove the buttons (the default), remove the buttons only, or leave the message unchanged. To enable approvals in Slack, your n8n instance must be reachable from Slack over public HTTPS. You will need to turn on Interactivity in your Slack app, set the Request URL to https://<your-n8n-instance>/webhook-waiting-slack, and paste your app's signing secret into the Signature Secret field of your Slack credential. Then, in the Slack node, set Response Type to Approval and turn on Capture Who Responded under the Advanced Interactivity section. For Telegram, your instance must be reachable over public HTTPS on a port Telegram supports for webhooks (443, 80, 88, or 8443). Enable Approve Within Chat in the same section: n8n registers the webhook for you using your existing Telegram credential, with no additional setup on Telegram's side. Learn more in the Approvals in Slack documentation. App-only authentication for Microsoft nodes Released: 2026-07-07 in n8n 2.30 You can now authenticate Microsoft nodes with a Microsoft Entra Service Principal, so workflows run as an application instead of a signed-in user. OneDrive and Outlook gained the option in n8n 2.29; Excel 365, Microsoft Teams, and Microsoft To Do follow in n8n 2.30, all sharing a single app-only credential. Until now, Microsoft automations were tied to a person's OAuth session: when that person left the company or their token expired, the workflow broke. With app-only authentication, the workflow authenticates non-interactively with tenant-level permissions and targets the user, mailbox, drive, or site you specify: read a shared mailbox, process files in any user's drive, or post to Teams channels with nobody logged in. OAuth2 remains the default everywhere, so existing workflows are untouched, and operations that only make sense for a signed-in user are disabled per node with a clear error. OneDrive and Outlook support released in n8n 2.29 (2026-06-30). mTLS authentication for Kafka Released: 2026-07-07 in n8n 2.30 The Kafka credential now supports mutual TLS: provide a CA certificate, client certificate, and private key (PEM) to connect to brokers that require client-certificate authentication. mTLS applies to the Kafka node, the Kafka Trigger, and the credential test, and n8n validates that certificate and key match before you save. AI Assistant: describe a goal, get a working automation Released: 2026-07-09 in n8n 2.29.9 You can now describe an automation in plain language and have AI Assistant plan, build, test, and iterate on it until it actually runs. Open the chat from anywhere in your instance, or expand it into a side-by-side view with the workflow canvas, and tell it what you want to automate. It proposes a structured plan, asks clarifying questions, builds the workflow in your selected project, executes it as it goes, and fixes the errors it finds. Describe what you want to automate, or start from a suggestion. AI Assistant supersedes the AI Workflow Builder, and the difference is autonomy. The AI Workflow Builder generated a workflow and handed off, leaving you to run it and debug failures yourself. AI Assistant works toward your goal: it runs what it builds, detects failures, and retries until the automation works. Its scope is broader than building, too. It can manage executions, credentials, nodes, and Data Tables, run one-off tasks, and research the web when web access is enabled. Credential setup happens progressively as it builds: fill values in manually, let it fetch what it can, or mock and skip where needed, with secrets never exposed in the chat. Every workflow it builds is a normal n8n workflow: a visible canvas you can open, inspect, edit, and publish, with step-by-step execution logs to audit, built on the 400+ integrations n8n already ships instead of rebuilt API connections. You stay in control throughout: high-impact actions such as publishing wait for your approval. This is an early first step, and we want your feedback on where to take it next. This feature is in preview. It can make mistakes, and its behavior may change while it's in development. Always review generated workflows before using them in production. Learn more in the AI Assistant documentation. Availability: n8n Cloud only. Self-hosted support is coming. MCP server updates Released: 2026-06-30 in n8n 2.29 We've shipped a number of updates to the n8n MCP server over the past few weeks. Here's a roundup, with the version each change landed in. Build with custom and community nodes. You can now use your installed custom and community nodes in the workflows you build, not just the built-in ones (n8n 2.29). Read and change workflow settings. Workflow settings are now editable through the MCP server, so you can connect an error workflow, set the timezone, or adjust execution options (n8n 2.29). View and restore workflow history. You can now browse a workflow's version history and restore an earlier version (n8n 2.29). More reliable credential assignment. Fixed a bug where the server could assign a credential that wasn't valid for a node (n8n 2.28). Look up real field values. Dynamic fields like Slack channels or Google Sheets tabs now resolve to live values, so nodes are configured with valid selections instead of placeholder IDs (n8n 2.27). Work with tags. Tags are now supported, so you can filter a workflow search by tag and apply tags when creating or updating workflows (n8n 2.27). Faster, targeted edits. Workflow updates now change only the nodes that need to change instead of rewriting the whole thing (n8n 2.22). List and choose credentials. You can now list the credentials on your instance and pick the right one when several could apply, for example among five Gmail credentials (n8n 2.21). Learn more in the n8n MCP server documentation. GitHub App authentication Released: 2026-06-30 in n8n 2.29 The GitHub node and GitHub Trigger can now authenticate as a GitHub App, alongside the existing personal access token and OAuth2 options. A personal access token belongs to a person. The workflow that triages issues or merges release PRs runs with one engineer's identity and access, so it stops working the day they change teams or leave. Until then, its actions appear in the audit log as that engineer working by hand. A GitHub App belongs to the organization. You register it once and install it on the repositories it should reach. Grant only the permissions it needs (read pull requests, write issues) rather than the broad repo scope a classic token hands out. Nobody's departure breaks it, its activity is attributed to the app rather than a colleague, and it gets its own rate limit. To set it up, cre…