n8n Community Forum

On the encryption-key mismatch — the --decrypted export/import is the pragmatic path, but what bit me was that the moment you decrypt to JSON you’ve got plaintext secrets on disk, so that file has to be treated as live all the way through: encrypted transport, deleted after import, never in a repo. If you’d rather not move plaintext at all, the External Secrets route is the cleaner long-term answer — n8n only ever holds a reference, the real value lives in Secrets Manager/Vault, and dev vs prod just point at different secret paths. More setup up front, but then “syncing” stops being a task you run and becomes something that’s just true. For a smaller non-K8s setup, scripting the CLI export→import behind a scheduled job is the middle ground.

Seconding the Telegram Send-and-Wait approach — it’s the lowest-friction option when approvers aren’t n8n users. Two things that made it reliable for me in production: Put the actual write/side-effect after the wait, never before. The agent only ever proposes; the workflow commits. Easy to accidentally let the agent call the tool and “approve” the log afterwards — that’s what bites you. Log one row per decision (action + params hash + verdict + approver + timestamp), INSERT-only, like Kimetai said. When something breaks at 2am that append-only table is the only thing that tells you what was actually approved vs. what the agent claims. The Wait+Webhook audit gap goes away once the log is a separate append-only step instead of something you read back out of the execution.

The google nodes in my order form are continously failing and they are creating a lot of original failed orders does anyone have a clear solution for me so that there is no errors and the process of the workflow stays smooth, I tried to add retries and continue option if even after retries fail, those have brought some good positive changes but if anyone has any permanent solutions for the workflow please do let me know I have attached the workflow image for your reference

This is genuinely useful — the Cloud API friction you describe is real. I ship client bookings on the official WhatsApp Cloud API, and the two things that hurt most are exactly what you’re routing around: the template review turnaround the first time, and the 24h session window forcing everything outside it into pre-approved templates. One question on the unofficial side though — at what outbound volume does the proxy pinning actually hold up before you start seeing session drops or bans? That’s the thing that’s kept me on the official API for client-facing flows, and it’s the deciding factor for whether I’d run this on a real account vs. a throwaway.

Hey @Rummsteak , while you wait for a response, here are some things that might help: Suggested resources (click for more details) @jan , @Parintele_Damaskin , @Piotr_Sikora - you’ve helped with similar issues before, can you take a look? Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here .

BOnjour à tous, J’ai une question concernant les conditions d’utilisation. Les boites qui fabriquent et vendent des workflow à leur clients, elles font comment niveau hébergement ? Les clients ont leur vps, avec une instance n8n ou elles mettent les nouveaux workflow dessus ? Ou le provider a un gros vps, avec une instance vps par client ? Je n’arrive pas à comprendre ce que la license permet, quelqu’un saurait ce qui est possible de fzire ou non ? En vous remerciant, Rumm Describe the problem/error/question What is the error message (if any)? Please share your workflow (Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.) Share the output returned by the last node Information on your n8n setup n8n version: Database (default: SQLite): n8n EXECUTIONS_PROCESS setting (default: own, main): Running n8n via (Docker, npm, n8n cloud, desktop app): Operating system:

Good question — that’s the exact edge case that generates annoyed replies if you get it wrong. I don’t treat the recall list as final once it’s built. After the scan flags someone as inactive, I run a second lookup against the bookings source (calendar / bookings table) for that same contact and drop anyone who either has a future appointment on the books or a completed one dated after their “last visit” — so a rebooking that happened between scans clears them automatically. I also stamp a recall_sent_at field when a message goes out, plus a short cooldown, so even if someone slips back onto the list they don’t get hit twice in the same window. Cheap to add — one extra lookup node and a filter — and it kills the “why are you texting me, I was just in last week” problem.

Hi Rami, thanks — here are the four clarifications. 1. Short walkthrough of an existing n8n build The attached execution screenshot is from my currency-data test project, recorded on 14 August. It is a test/demo project, not an electrical-parts RFQ client deployment, and the image contains no credentials or customer data. The loader runs: Schedule / Manual Trigger → Configuration → Ensure Data Table → HTTP Request → Validate & Normalize → Upsert → Success Summary. The validation node checks the response structure, expected currency coverage and positive numeric values before any rate rows are written. A stable pair key (for example USD/EUR) is used for upserts. Network, validation and storage errors have a separate error branch. In the recorded acceptance check, two runs each processed 33 rows and the table still contained 33 rows rather than 66. The screenshot shows the first successful execution. This demonstrates ingestion, validation, repeatability and error routing; it does not demonstrate PDF parsing. I have not re-tested the live deployment today. 2. Revisions and bug fixes For the full prototype I would include one consolidated revision within the agreed scope, plus correction of reproducible defects against the written acceptance criteria reported within seven calendar days after acceptance. The paid test retains its own one revision. New layouts, features, catalogue cleansing, third-party changes and ongoing operation would require separate agreement. 3. Hosting For

Hi JEnterprises — I’ll answer your main filter first: I cannot honestly point you to a verifiable 6+ month n8n + Postgres deployment under my name, so I won’t claim one. If that exact proof is a hard gate, I understand. What I can make testable is the reliability architecture you’re asking for. I would keep Postgres as the only operational source of truth; agents stay bounded/stateless, prompts/models are versioned, every run/checkpoint/action is logged, retries are idempotent, and anything external-facing remains behind an explicit human approval. pgvector would be retrieval only, not authoritative state. Daily canaries should use fixed fixtures and fail loudly on source/schema/output drift. Rather than ask you to trust a broad Phase 0/1 promise, I’d propose a paid first milestone: USD 750 fixed, 3–5 business days after we agree the redacted brief and acceptance criteria. No PHI or patient data. Deliverables: tenant/RLS schema and isolation tests; workflow_run/checkpoint/audit/dead-letter tables; self-hosted n8n + Postgres deployment skeleton and backup/restore check; one public-source Phase-1 path into a human approval queue, with no auto-send; one daily canary fixture plus alert path; handoff/runbook and a fixed quote for the next slice. Acceptance gates would include: cross-tenant read/write attempts return no foreign rows; a retry cannot duplicate an external action; canary failure is visible; and no outbound action can execute without an approval record. From the public

Nevermind, I just realized that this capability has already been added to a newer version (2.29) that I’m running.

@hemchandra @Anshul_Namdev ok .. if the main reason for downgrading is to get the migration Report, i don’t think that will help , the report was introduced in 1.121.0, so 1.109.2 won’t have it . i’d first figure out what is actually breaking on 2.32.7 and work through the v2 compatibility changes . Downgrading all the way back to 1.109.2 just to get the report would probably take you in the wrong direction. if you can share what you’re trying to check, there may be a better way to test the compatibility without rolling back.

I second this feature request. Github recommends using GitHub Apps over OAuth apps (which are currently supported in N8N) for a number of reasons and it would be really great if it was supported. Looks like a feature request for this has been submitted as a the Github issue years ago, but the requestor has been recommended to move it to this forum: github.com/n8n-io/n8n Source Control: support GitHub App authentication (auto-refreshed installation tokens) opened 07:46PM - 23 Jun 26 UTC closed 07:46PM - 23 Jun 26 UTC DrFaust92 closed:enhancement/feature ## Is your feature request related to a problem? n8n Source Control (Environmen … ts) currently authenticates to the Git remote with either an **SSH deploy key** or **HTTPS username/password**. For HTTPS, the password is a static token (PAT). Static tokens have two problems for org-managed deployments: 1. **They expire.** When a static HTTPS token expires, source control breaks — and per #28311 an expired token can even **prevent n8n from starting after a restart**. Someone has to manually rotate the secret. 2. **They're coarse / long-lived.** PATs are tied to a user account and are broadly scoped; SSH deploy keys are per-repo but are long-lived static secrets with no built-in rotation. For organizations syncing workflows to GitHub, a **GitHub App** is the standard, recommended auth model: org-installable, fine-grained repo permissions, and **short-lived installation access tokens (~1h) that are minted on demand** rather than s