DEV Community: Stepan Nikonov

RAG for Small Businesses: AI That Searches Your Company Knowledge

Stepan Nikonov — Thu, 30 Jul 2026 23:02:43 +0000

RAG sounds technical, but the useful idea is simple: let AI search selected company documents before it answers, instead of asking it to guess from a blank chat window.

Most small businesses do not have a knowledge problem because they lack information. They have one because the information is scattered. A price note is in one folder, a refund rule inside an old PDF, a support answer buried in email, a delivery process in someone's private notes. The owner, manager, or senior admin becomes the living search engine.

This is where RAG can be useful. Not as a black box AI agent. Not as a replacement for good operations. Just as a practical way to help a team search its own knowledge before asking AI to write an answer.

RAG is not the AI knowing everything. It is the AI looking at selected company information first, then answering from that context.

The actual business problem

A small team usually knows the answers. The slow part is finding the right answer at the right moment.

A new employee asks the same onboarding questions every week.
Sales needs the latest package details before replying to a lead.
Support has to search old conversations for a policy answer.
Operations keeps a checklist in one place and exceptions somewhere else.
The owner becomes the person everyone asks before making a small decision.

A normal keyword search helps only when the person knows the exact word to search for. Real questions are messier. Someone asks "can we still refund this?" while the document says "cancellation window." Someone asks "what do we include in the starter package?" while the pricing file says "basic implementation scope."

RAG in plain English

RAG means retrieval-augmented generation. In plain English: the system retrieves relevant information first, gives that information to the AI model, and then asks the model to generate an answer from that context.

That matters because a normal chatbot can write confidently without knowing your internal rules. A RAG assistant can be told to answer only from selected business documents and to say when the answer is not in the provided knowledge.

A simple RAG pattern: selected company documents become searchable knowledge, a team asks a question in chat, and the answer is grounded in retrieved context.

What a vector database does

A vector database helps search by meaning, not only by exact keywords. If someone asks about "refund rules" and the document says "cancellation and return policy," a semantic search can still find the right section. That is the useful part; the business does not need a lecture on embeddings before it can benefit from better internal search.

One practical detail matters: the embedding step is separate from the answer-writing step. An embedding model turns each approved document chunk into a vector. Qdrant stores and searches those vectors. A language model can then write an answer from the retrieved context. Those jobs should not be blurred together.

Where the tools fit

In a small RAG workflow, each tool should have one clear job.

n8n coordinates the workflow. It receives a question, triggers the search step, sends the retrieved context to the model, logs the result, and returns the answer to the team.

Qdrant stores searchable document chunks. It keeps selected company knowledge in a form that can be searched by meaning rather than exact wording.

An embedding model creates the vectors. This can be OpenAI’s embedding API or another dedicated embedding model. Its job is to convert the documents and the user’s question into comparable numerical representations.

A language model writes the answer. Groq or another LLM can be used here, but it should answer from the retrieved context rather than invent a policy that is not in the documents.

Slack gives the team a familiar interface. Questions and answers can stay inside a private internal channel instead of another dashboard nobody opens.

The stack itself is not the point. Qdrant, n8n, an embedding model, an answer model, and Slack are useful only when the workflow answers a real operational question faster and more consistently than manual search.

Business questions this can help with

A knowledge assistant is most useful when the answer already exists somewhere, but the team wastes time finding it.

Pain	Useful first version	Human check
New staff asks the same setup questions.	Search onboarding docs and SOPs from Slack.	Escalate missing or outdated answers.
Sales needs package and pricing details quickly.	Retrieve the latest service scope, inclusions, and limits.	Manager approves unusual discounts or exceptions.
Support repeats answers from old tickets.	Search FAQ, policy, and troubleshooting notes.	Agent reviews before sending to a customer.
Operations has checklists across files.	Find the relevant process step or exception rule.	Owner confirms edge cases.

This is why RAG can be a good fit for small team automation work. Many teams already run on Drive folders, PDFs, spreadsheets, Notion pages, email threads, and chat, and the first win is often not replacing those tools. It is making the right parts searchable.

For small businesses in the Philippines, the knowledge layer is often less polished than a formal company wiki. It may be a mix of Google Drive folders, Facebook Messenger threads, WhatsApp or Viber chats, Gmail, shared spreadsheets, and a few documents only one person knows about. A useful AI knowledge assistant should respect that reality: start with the approved files and processes, then connect to the team's actual tools only when the workflow is clear.

What this will not fix

RAG does not make bad documents good. If the source material is outdated, contradictory, or missing, the assistant should not pretend otherwise.

It will not decide company policy for you.
It will not clean years of messy files by itself.
It should not answer sensitive questions without access control.
It should not hide uncertainty behind a confident paragraph.
It still needs testing with real questions from the team.

A good version should be allowed to say: "I cannot find that in the provided documents." That answer is sometimes more valuable than a polished guess.

Start smaller than you think

The first version does not need every file the company has ever created.

A better starting set might be 10 to 30 useful documents: current pricing, service scope, refund policy, onboarding SOP, support FAQ, delivery checklist, and a few internal notes that people already ask about. That is enough to test whether the assistant retrieves useful context before you spend time connecting more systems.

The first build should also have a narrow promise: answer internal team questions from selected documents. Not update customer records, not send client replies, not make decisions without review.

Questions to map before building

Before turning this into a workflow, map the knowledge first.

Which documents are actually current?
Which questions does the team ask repeatedly?
Which answers are safe for internal use only?
Which answers should require manager approval?
Where should the assistant answer: Slack, email, Notion, or another tool?
What should happen when the answer is missing or uncertain?

These questions matter more than the model choice. A fast model connected to messy, unreviewed knowledge will still produce messy answers faster.

Bottom line

RAG is useful when the business already has answers, but the team loses time finding them. Start with a small, approved knowledge set, test real questions, and make the assistant show uncertainty instead of filling gaps with confident guesses.

The practical goal is not to make a chatbot sound impressive. It is to help a team find the right internal answer faster, with enough context for a human to trust, check, or improve it.

Want to see the workflow version? I built an inspectable Slack Knowledge Bot with n8n, Qdrant, and Groq that answers from approved Google Drive docs, shows sources, and marks low-confidence matches.

Sources

Originally published on FloxoLab.

How to Fix Core Web Vitals: LCP, CLS, and INP in Plain English

Stepan Nikonov — Sun, 26 Jul 2026 19:33:34 +0000

I took this site from a mobile score of 77 to 98, and to 100 on desktop. Here is what each Core Web Vital measures, what drags it down, and the fixes that actually moved the numbers, in plain language you can act on.

Core Web Vitals are three numbers Google uses to measure how a page feels to a real person: how fast the main content loads, whether the layout jumps around while it does, and how quickly the page reacts when you tap or click. They are part of Google's page experience signals, which means they work as a ranking tie-breaker. Between two pages that answer a query equally well, the faster, steadier one has the edge.

This guide explains each of the three, plus the supporting numbers you will see in the same report, and then shows the real fixes that took this site's mobile score from 77 to 98. Nothing here is theory. It is the same work I run on client sites in an SEO audit.

What a good result looks like

Here is where this site sits today, straight from Google's PageSpeed Insights: 98 on mobile and 100 on desktop, on the same code. The two tests look different because mobile is run on a throttled, slower simulated device, so it always has less room to work with. Mobile is the harder target, and since mobile traffic dominates most sites, its real-user data usually carries the most ranking weight, so it is the score worth chasing. Google measures mobile and desktop separately, so desktop still counts too.

Mobile: performance 98, LCP 1.9s, CLS 0, all vitals in the green.

Desktop: performance 100, LCP 0.5s, CLS 0, speed index 0.4s.

The three Core Web Vitals, one at a time

Everything on the scoreboard comes down to three real-user metrics. A page passes when 75 percent of real visitors fall inside the "good" band for each.

Metric	Measures	Good	Poor
LCP (Largest Contentful Paint)	Loading	2.5s or less	Over 4s
CLS (Cumulative Layout Shift)	Visual stability	0.1 or less	Over 0.25
INP (Interaction to Next Paint)	Responsiveness	200ms or less	Over 500ms

LCP: how fast the main thing loads

Largest Contentful Paint is the moment the biggest element in view finishes rendering, usually the hero image or the headline block. It is the reader's gut sense of "has this page loaded yet". What drags it down is nearly always one of four things: a heavy, uncompressed hero image, a slow server or host, render-blocking CSS and JavaScript that must run before anything paints, and web fonts that arrive late.

The fixes follow the causes. Compress and serve the hero as WebP at the right size, and preload it so the browser fetches it early. Use srcset so a phone pulls a small version and a desktop a larger one, instead of shipping one heavy file to every device. That is a separate lever from preloading: preload fetches the image sooner, srcset makes sure it is the right weight, and on a slow mobile connection the srcset part is often what saves the most. Cut or defer render-blocking scripts, and self-host your fonts instead of pulling them from a third-party domain. On this site LCP is 1.9s on mobile and 0.5s on desktop, and the single biggest lever was the hero image: right format, right size per device, preloaded.

CLS: whether the page holds still

Cumulative Layout Shift measures how much the content jumps around as the page loads. You have felt it: you go to tap a link, an image or banner loads above it, and the whole page shoves down. The usual culprits are images and embeds with no width and height set, ad or banner slots injected after load, and fonts that swap and reflow the text.

This is the most fixable vital, and the cheapest win on the list. Put explicit width and height (or an aspect ratio) on every image and iframe so the browser reserves the space before the file arrives. Give injected elements a fixed slot. Set font-display so a font swap does not reshuffle the layout. This site sits at a CLS of 0, and it got there almost entirely by adding size attributes to images.

INP: how fast the page answers you

Interaction to Next Paint replaced First Input Delay in March 2024. It measures the delay between you doing something, a tap, a click, a keypress, and the page actually showing a response, taking close to the worst interaction across the whole visit. A high INP is a page that feels sluggish and unresponsive, and the cause is almost always JavaScript hogging the main thread: heavy frameworks, big third-party scripts, and long tasks that block the browser from reacting. It is also the vital the most sites fail, so it is worth the attention.

The fix is to give the main thread less to do. Defer or split heavy JavaScript, hold third-party scripts off the critical path until the user needs them, and break long tasks into smaller pieces. The clearest example on this site is analytics: the Google tag does not load until the first interaction or the browser goes idle, so it never blocks that first tap. That one change keeps total blocking time, the lab stand-in for INP, at 40 milliseconds.

The other numbers in the report

The same Lighthouse report shows three more metrics. These are lab diagnostics, useful for finding problems, but they are not the vitals Google ranks on.

First Contentful Paint (FCP). When the first text or image appears. An early signal that something is happening.
Total Blocking Time (TBT). How long the main thread was blocked during load. It is the lab proxy for INP, so lowering TBT usually lowers INP for real users too.
Speed Index. How quickly the page visibly fills in. On this site it shows 3.5s on mobile and lands in the amber band, while every actual vital is green. That is a fair reminder that the overall score is a blend, and a single amber lab number is not worth panicking over when the real-user vitals all pass.

Lab data and field data are not the same

There are two ways to measure all of this, and mixing them up causes a lot of confusion. Lab data is a single simulated test, like the Lighthouse run in the screenshots above, on a fixed device and connection. It is repeatable and great for debugging. Field data is what real Chrome users actually experienced over the last 28 days, and it is what Google uses for ranking. You can see your own field data in the Core Web Vitals report inside Search Console.

The practical order: use the lab test to find and fix problems fast, then watch the field data in Search Console to confirm real users feel the change. A lab score can be perfect while the field still lags, especially on a page that only just got fixed, because the field window is a rolling average. Reading that report is part of the wider habit covered in how to read your monthly SEO report.

What actually moved this site from 77 to 98

The jump was not one clever trick. It was a short list of unglamorous fixes, each aimed at a specific metric:

Self-hosted the fonts. Pulling fonts from a third-party domain adds a connection and a render delay. Serving them from the same domain, preloaded, cut straight into LCP.
Deferred analytics off the critical path. The Google tag now loads on first interaction or idle instead of during load, which kept total blocking time, and therefore INP, low.
Responsive images in WebP. Every image ships as WebP at several sizes with srcset, so a phone downloads a small file and a desktop a larger one, never the wrong one.
Width and height on everything. Explicit dimensions on images and figures reserve their space, which is why CLS is 0.

None of that touched the design or the content. It is exactly the kind of finite, technical work that a small site needs once, not every month, which is the point I make in the technical SEO fixes agencies won't touch.

A quick checklist

Compress the hero image, serve it as WebP, and preload it.
Set width and height on every image, iframe, and embed.
Self-host fonts and set font-display so text does not reflow.
Defer analytics and other third-party scripts off the load path.
Test in the lab with PageSpeed Insights, then confirm in Search Console field data.

Frequently asked questions

What are Core Web Vitals?

Three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. They come from real Chrome users and feed into ranking as a page experience signal.

What is a good Core Web Vitals score?

A page passes when 75 percent of real users see LCP at 2.5s or less, CLS at 0.1 or less, and INP at 200ms or less. In the Lighthouse lab test the overall score is good from 90 to 100. This site scores 98 on mobile and 100 on desktop.

Why is my mobile score lower than desktop?

Lighthouse tests mobile on a throttled, slower simulated device and connection, so the same page has less CPU and bandwidth to work with. Mobile is the harder target, and because mobile traffic dominates most sites, its real-user data usually carries the most ranking weight, so it is the score to optimise for. Google measures mobile and desktop separately, so desktop still counts.

Do Core Web Vitals affect SEO rankings?

Yes, as a tie-breaker rather than a magic lever. Between two pages of similar relevance, the faster and steadier one has an edge. Fixing vitals will not outrank a far more relevant page on its own, but poor vitals can hold back a page that otherwise deserves to rank.

Sources checked

Originally published on FloxoLab.

Slack Knowledge Bot with n8n, Qdrant, and Groq

Stepan Nikonov — Fri, 24 Jul 2026 10:49:36 +0000

A practical workflow that turns approved Google Drive docs into a Slack assistant. It chunks selected files, stores embeddings in Qdrant, retrieves relevant context, asks Groq to answer only from that context, and replies with sources or a low-confidence note.

Many teams already have the answer somewhere: a pricing note, an onboarding doc, a service FAQ, a checklist, or a handoff process. The slow part is finding the right section while work is happening.

This workflow gives Slack a searchable knowledge layer. A team member asks a question, n8n searches an approved Google Drive folder through Qdrant, and Groq writes an answer from the retrieved context with source files attached.

The useful part is not a confident answer.

It is a traceable answer: what documents were searched, which sources were used, and whether the match was weak enough to treat with caution.

Knowledge source	Search layer	Team interface
Approved Google Drive Markdown files	Qdrant vectors from local embeddings	Slack mention with sources

Approximate running cost

For this demo, the software bill can stay very low. Ollama runs the embedding model locally. n8n can run as a free self-hosted community edition. Qdrant can run locally or start on a free cloud tier for testing. Groq is the main paid API part, and a small internal bot like this can often be tested on a small balance when question volume is modest.

Ollama embeddings: no API bill when the embedding model runs on your own machine or server. The cost is local compute.
n8n: free if self-hosted, with hosting and maintenance still owned by someone. n8n Cloud is paid if you want managed hosting.
Qdrant: local/self-hosted can be free to run as software. Qdrant Cloud also has a free tier for testing and prototypes, with paid usage when the project grows.
Groq: the answer generation step is usage-based. For a low-volume demo, a small balance such as USD 5 can be enough to test the pattern for a while, but real spend depends on model choice, prompt size, and usage volume.

Low software cost to start. Real cost is hosting, API calls, and whoever maintains it.

Groq: the answer generation step is usage-based. For a low-volume demo, a small balance such as USD 5 can be enough to test the pattern for a while, but real spend depends on model choice, prompt size, and usage volume.

Low software cost to start. Real cost is hosting, API calls, and whoever maintains it.

The full workflow map

The canvas has two lanes. The top lane refreshes the knowledge base: list files, filter approved text files, chunk them, embed them, delete old chunks for the same source, and upsert the fresh points into Qdrant. The bottom lane answers questions from Slack.

Two visible paths: document ingestion on top, Slack question answering below.

1. Start with approved docs

The workflow starts from a controlled Google Drive folder. In this demo, the folder contains Markdown files for FloxoLab pricing, services, FAQ, workflow examples, onboarding, and intake process notes.

That matters because a useful knowledge bot should not begin by crawling a messy shared drive. The first version should use current, approved documents that are safe for internal answers.

The workflow filters for Markdown files, so the first knowledge base stays simple and reviewable.

2. Chunk the files with metadata

Each file is downloaded and passed through a code node that splits text by headings, keeps chunks under a practical word limit, and adds metadata such as source, file index, chunk index, word count, and last modified time.

Metadata is not decoration. It is what lets the answer show where the context came from, and it gives the workflow a clean way to replace old chunks from the same source during the next ingestion run.

Each chunk carries source and index data, not just text.

3. Store searchable chunks in Qdrant

The workflow uses Ollama with nomic-embed-text for embeddings, then prepares a Qdrant point with a deterministic id, vector, and payload. Before upserting new points, it deletes old chunks for the same source so stale content does not sit beside fresh content.

Qdrant stores the vector plus the payload fields the workflow needs later: text, source, chunk index, timestamps, and word count.

4. Ask from Slack

The question flow starts when someone mentions the bot in Slack. n8n removes the mention text, embeds the clean question, searches Qdrant for the top matching chunks, and builds a compact context block for Groq.

The answer prompt is deliberately strict: answer only from the provided context, do not invent pricing, services, guarantees, timelines, or policies, and keep the message concise enough for Slack.

The user asks inside Slack. The bot answers from the retrieved context and appends source files.

5. Make uncertainty visible

The workflow also marks weak retrieval. If the top Qdrant score is below the threshold, the answer includes a low-confidence note. That is a practical guardrail because the user can see the answer should be checked before it becomes a decision.

A missing answer should stay visible. Here the bot says it does not know and marks the match as low confidence.

What I would improve next

The demo proves the path, but a production version should make ownership clearer.

Better source links. File names are useful, but links back to the exact Google Drive document would make review faster.
Threaded Slack replies. Posting answers in the original thread would keep channels cleaner.
Low-confidence review. Weak matches could be logged to a sheet or sent to a private review channel.
Ingestion logs. A clear record of files, chunk counts, and failures would make handoff easier.

Bottom line

A Slack knowledge bot is useful when the answer already exists, but the team wastes time finding it. The important choices are not only model and database. They are the approved knowledge set, the retrieval threshold, the source display, and the fallback behavior.

This workflow keeps those parts visible: selected docs in, searchable chunks stored, Slack question asked, context retrieved, answer written from that context, sources shown, uncertainty surfaced.

Related guide

For the plain-English explanation behind this pattern, read RAG for Small Businesses: AI That Searches Your Company Knowledge.

Originally published on FloxoLab.

n8n Webhook Not Working? Test URL, Production URL, and 404 Fixes

Stepan Nikonov — Tue, 21 Jul 2026 07:25:33 +0000

If an n8n webhook receives nothing or returns 404, check the URL mode and registration state before changing the workflow. This guide follows the shortest useful diagnostic order.

An n8n webhook normally fails before the first workflow node runs. A 404 usually means the request did not match a registered webhook route. The common causes are a test URL with no active listener, a production URL for an unpublished workflow, the wrong HTTP method, a changed path, or an incorrect public URL on a self-hosted instance.

Fastest check: open the Webhook node, copy the URL again, confirm whether it is Test or Production, and send the same HTTP method configured in the node. Do this before debugging credentials, expressions, or downstream nodes.

Start with the symptom

Symptom	Most likely check	First action
Test URL returns 404	No current test listener	Select Listen for test event, then resend within 120 seconds.
Production URL returns 404	Workflow is not published	Publish the workflow and copy the Production URL again.
URL works in a browser but not from the app	GET versus POST mismatch	Match the sender's method to the Webhook node.
URL has the wrong domain, port, or protocol	Self-hosted proxy configuration	Check `WEBHOOK_URL`, proxy hops, and forwarded headers.
Webhook runs but no data appears on the canvas	Production execution	Open the workflow's Executions tab.

Test URL versus Production URL

Every Webhook node exposes two URLs at the top of its panel. The official Webhook node documentation treats them as two different operating modes, not interchangeable copies of the same endpoint.

Use the Test URL while building

Select Test URL, then select Listen for test event before the external system sends its request. n8n registers the test webhook for 120 seconds and displays the incoming data in the editor. If the timer expires, register it again and resend the event.

Opening the workflow is not enough by itself. A saved test URL can return 404 later because test registration is temporary. This is useful during development because it lets one test payload appear directly on the canvas, but it is the wrong URL for a service that must call n8n at any time.

Use the Production URL after publishing

Select Production URL, copy it into the sending service, and Publish the workflow. Current n8n documentation uses Publish terminology. Publishing registers the production webhook and makes the published workflow version available to external requests until the workflow is unpublished.

Production payloads do not appear live on the editor canvas. Open Executions to confirm whether the request created a production execution and to inspect its input. No data on the canvas does not mean the webhook failed.

The n8n webhook 404 checklist

Run these checks in order. Stop as soon as the request reaches n8n.

Copy the URL from the node again. Do not rely on a URL saved in an old note, form, app, or API client.
Confirm Test or Production. Test requires a temporary listener. Production requires a published workflow.
Confirm the HTTP method. A POST request does not match a webhook registered only for GET.
Compare the path exactly. Check spelling, hyphens, route parameters, and any path changed after the sender was configured.
Check for a path-and-method conflict. n8n permits only one registered webhook for each path and method combination.
Inspect the public base URL. Do this only for self-hosted n8n behind a reverse proxy or when the node displays an internal hostname, HTTP instead of HTTPS, or the wrong port.

Check the HTTP method before the payload

The Webhook node supports GET, POST, PUT, PATCH, DELETE, and HEAD. By default it accepts one method. The sender must use that exact method. Pasting a webhook URL into a browser sends GET, so a successful browser test does not prove that a service's POST request will match, and the reverse is also true.

Current n8n versions can allow multiple HTTP methods from the node's Settings. Use that only when the endpoint genuinely needs more than one method. A tighter single-method webhook is easier to reason about and reduces accidental calls.

Check the webhook path

n8n generates a random path by default, and you can replace it with a stable custom path. Once an external app stores the URL, changing the Path field changes the route it must call. Copy the complete URL after every path change instead of editing only the last segment by hand.

n8n also requires each registered path and HTTP method combination to be unique. If another published workflow already owns the same combination, unpublish the conflicting workflow or choose a different path or method. The Webhook common-issues page documents both method matching and route conflicts.

Send a minimal request

Remove the external app from the diagnosis. Copy the exact URL from the Webhook node and test it with a safe placeholder payload. The example below uses POST. Change the method if your node uses something else.

curl --request POST 'https://n8n.example.com/webhook/example-path' \
  --header 'Content-Type: application/json' \
  --data '{"event":"webhook-test","id":"demo-001"}'

Replace the example URL with the full Test or Production URL copied from your node. For a Test URL, select Listen for test event immediately before running the command. For a Production URL, publish first. If this request works, the remaining problem is in the external app's stored URL, method, headers, authentication, or network access.

Reverse proxy and public URL problems

Skip this section on n8n Cloud. It matters when a self-hosted instance runs internally on one address but a reverse proxy exposes a different public HTTPS address.

n8n normally builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a proxy, that can produce an internal port or the wrong scheme. The official reverse-proxy configuration says to set the public URL explicitly with WEBHOOK_URL, set N8N_PROXY_HOPS to the number of reverse proxies, and pass the forwarded host, protocol, and client information from the last proxy.

WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

Do not copy this blindly. Use your real public HTTPS base URL and the actual number of proxies in the request path. Restart or redeploy n8n after changing environment variables, then copy the regenerated webhook URL from the node.

What to log before handing the webhook into production

The final Production URL location and which external system owns it. Do not paste secret query parameters into a public document.
The expected HTTP method, content type, authentication method, and a sanitized example payload.
The workflow owner and where production executions are reviewed.
The expected success response and what the sender does when it receives a non-2xx response.
The alert channel and recovery owner for failures after the webhook starts the workflow.

Once the route works, broader failures belong in the n8n workflow debugging guide. Production ownership and notifications belong in the n8n error workflow alerts guide. Keeping those jobs separate makes the webhook checklist short enough to use during an incident.

The production handoff

Test with the Test URL and one sanitized payload.
Switch the node to Production URL and copy the full value.
Publish the workflow.
Update the external service with the Production URL and matching method.
Trigger one real but safe event.
Confirm the run in Executions and record who owns failures.

n8n autosaves edits, but saved draft changes are not the same as the published version used by production executions. The save and publish documentation explains that production runs continue to use the current published version until you publish newer changes.

Originally published on FloxoLab.

Self-hosting an AI agent is the easy part. The real work is limiting Telegram access and server permissions. I updated this case with a verified Hermes allowlist setup, DeepSeek V4 Pro config, and the sudo risk.

Stepan Nikonov — Sat, 18 Jul 2026 10:00:51 +0000

Stepan Nikonov

Jul 18

Hermes Agent: Self-Hosted AI Assistant with Persistent Memory and Telegram

#ai #selfhosted #automation #opensource

8 min read

Hermes Agent: Self-Hosted AI Assistant with Persistent Memory and Telegram

Stepan Nikonov — Sat, 18 Jul 2026 08:21:43 +0000

A real Hermes Agent setup on a VPS with Telegram allowlisting and persistent memory: installation, security, costs, failures, and daily use.

The problem

Claude Projects and ChatGPT Projects are useful, but they have a ceiling. Every session starts fresh unless you manually reload context. Claude Projects with a loaded .md file works, but you maintain that file manually. Hermes maintains its own memory autonomously. For a single question that is fine. For an assistant that handles recurring operational tasks across days and weeks, it means you spend time re-explaining the same things instead of just getting work done.

The other issue is availability. Managed tools run on someone else's schedule. Rate limits, outages, and interface changes are outside your control. If the assistant is part of your daily operations, that dependency matters.

An assistant that lives on your server remembers what it learns and works on your schedule, not a vendor's.

Hermes Agent is open source, MIT licensed, and runs on any VPS from about $5 per month.

Setup time	Monthly cost	License
About 15 minutes from curl to first Telegram message	$5-7 VPS + $2-5 LLM tokens	MIT, Nous Research, first released May 2026

What Hermes actually is

Hermes Agent is an open-source autonomous AI agent built by Nous Research. It is not a chatbot wrapper and not a simple Telegram bot. It is a long-running process that lives on your server, remembers what it learns, runs tasks on a schedule, and gets more capable the longer you use it.

The key difference from Claude Projects or ChatGPT Projects: Hermes maintains its own memory autonomously. After you give it your business context once, it carries that forward across every session. You do not re-explain who you are, what you build, or what your stack looks like every time you open a chat.

Persistent memory: Hermes writes structured memories after each session. Next time you start, it already knows your business, your tools, your clients, and your preferences.
Skills layer: After completing a complex task, Hermes writes a reusable skill so it can handle the same task faster next time. The longer it runs, the more capable it becomes at your specific workflows.
Scheduled tasks: Cron-based task runner built in. Set a morning digest, a weekly report, or a daily status check. It runs without any trigger from you.
Tools selected at setup: Web search, browser automation, file operations, code execution, image generation, and cross-platform messaging can be enabled during setup. Keep the Telegram toolset as small as the actual job allows.
Bring your own model: Hermes supports Anthropic, OpenAI, Google Gemini, DeepSeek, OpenRouter, Nous Portal, local endpoints, and other compatible providers. The model can change without reinstalling the agent.
Local state, external inference: Hermes stores its sessions, memory, and skills on your server and does not add its own telemetry. Prompts and relevant tool context still go to the LLM provider you configure unless you use a local model.

The setup

Installation runs through a single curl command. The installer auto-detects dependencies, installs Python 3.11 and supporting tools if they are missing, and walks through provider selection, platform configuration, and tool enablement via interactive menus.

The installer detects Ubuntu, installs missing dependencies automatically, and handles Python version management without manual setup.

Over 20 LLM providers available at setup. Nous Portal is the default, bundling 300+ models with tool use included.

Platform selection covers Telegram, Slack, Discord, WhatsApp, email, Signal, and more. Telegram was the choice here for daily operational use.

Tools enabled at setup: web search, file operations, code execution, persistent memory, cron jobs, cross-platform messaging, and task planning.

TTS is optional. Microsoft Edge TTS is free and needs no API key, a reasonable default for voice message support.

Installation complete. File paths are redacted. The next step is running hermes gateway install to set up the Telegram service.

The gateway runs as a systemd user service. Linger is enabled automatically so Hermes keeps running after SSH logout. No screen or tmux needed.

To lock Hermes to your account only, you need your Telegram user ID. @userinfobot gives it to you in one message.

Lock Telegram down before enabling server tools

The setup wizard asks for a numeric Telegram user ID. That value is the sender allowlist, and it is different from a chat or group allowlist. In current Hermes configuration, the important setting for a private bot is TELEGRAM_ALLOWED_USERS or its allow_from equivalent in the active profile.

TELEGRAM_ALLOWED_USERS=123456789

Use your own numeric ID from /whoami or @userinfobot, never the placeholder above. An empty allowed_chats field by itself does not prove that the bot is open because it controls a different scope. Verify the effective sender allowlist instead: it should contain your ID, no wildcard, and no group IDs unless group access is intentional.

Live verification: This deployment has exactly one sender in TELEGRAM_ALLOWED_USERS, with no wildcard, guest mode, group allowlist, profile override, or systemd override. Its empty allowed_chats value therefore does not let other Telegram users control Hermes. It only means the approved sender can reach the bot from any chat the bot has joined. Keep sensitive commands in the private DM because replies sent in a group remain visible to that group.

Back up ~/.hermes/.env and config.yaml before changing gateway access.
Keep the bot token and API keys out of screenshots, logs, shell history, and Git.
Restart the gateway after an allowlist change, then confirm the active profile and effective authorization mode.
Review gateway logs for unexpected sender or chat IDs. Rotate the bot token through BotFather if exposure is suspected.

Security warning: Do not combine an Internet-reachable messaging bot with unrestricted NOPASSWD: ALL sudo. Hermes documentation recommends passwordless sudo only for specific commands when messaging access genuinely needs it. A safer production layout runs the Telegram gateway as a dedicated non-root user or uses a sandboxed terminal backend, while full administration stays in an authenticated SSH or local CLI session.

The live setup in this case was rechecked on Hermes Agent v0.18.2 on July 18, 2026. See the official Telegram configuration guide for TELEGRAM_ALLOWED_USERS and the Hermes security and troubleshooting guide for the safer sudo pattern.

What it does in practice

After setup, Hermes is reachable on Telegram. The first interaction is straightforward: send it your business context and it saves it to persistent memory.

First response after gateway setup. Hermes confirms it is running on the machine and lists what it can do.

Business context saved to memory on first session: name, business, tech stack, infrastructure, and client profile. This persists across all future sessions.

After deleting the chat and switching to a different model, Hermes recalled the full business context from memory on the first message. This is the key difference from a managed AI tool.

The memory-context screenshot above is the most important one. The chat was deleted, the model was changed, and Hermes came back knowing who the user is and what they build. That is persistent memory working as intended.

What did not work

DeepSeek was the first provider selected because of the low cost. It failed immediately with a provider error on every message. The gateway logs showed the API was returning empty responses. The actual reason turned out to be simple: the DeepSeek account balance was below $0.01, not enough to process even a test request.

The current deployment now uses deepseek-v4-pro through the direct DeepSeek API. With provider deepseek, the clean model identifier is deepseek-v4-pro. Repeating the provider prefix as deepseek/deepseek-v4-pro can trigger a configuration warning even when requests still work.

Provider failure message in Telegram. The error handling is clean: Hermes surfaces the problem without exposing raw API details in the chat.

Root cause: less than $0.01 balance on the DeepSeek account. Switching to Google Gemini free tier resolved it immediately.

Two other things worth knowing before setup:

The full setup wizard can loop back to the beginning if you navigate past the last step. There is no need to run through it again. Ctrl+C after the first pass exits cleanly and the configuration is already saved.
A uv.lock warning appears during installation on some Ubuntu versions. It is not critical. The installer falls back automatically and everything continues.

Cost

Hermes Agent: Free. MIT license, no subscription, no per-seat fee.
VPS: About $5-7 per month on Contabo or a comparable provider. The same server can run n8n alongside Hermes without conflict.
LLM tokens: DeepSeek V4 Pro is usage-based. On July 18, 2026, the official direct API price was $0.003625 per million cached input tokens, $0.435 per million uncached input tokens, and $0.87 per million output tokens. Actual monthly cost depends on context size, tool output, and usage. Prices may change.

Model cost is not the only limit. Long conversations, repeated tool output, and large memory context can use more tokens than the visible Telegram message suggests. Check provider usage and keep only the tools and context the task needs. Confirm current prices on the official DeepSeek pricing page before choosing a model.

If you are still deciding whether an AI agent is the right fit for your situation, the AI agents for business guide covers the difference between chatbots, automation workflows, and agents, and when each one makes sense.

When this makes sense vs Claude Projects

Use Hermes when: You want the assistant to remember your business context permanently, run scheduled tasks automatically, stay available 24/7 on your own infrastructure, and work through Telegram without opening a browser.
Use Claude Projects when: You need a capable reasoning assistant for occasional deep work, research, or writing tasks. Claude Projects is faster to start, requires no server, and is better suited for tasks where raw model quality matters more than persistence.
Run both: Hermes handles daily operations and scheduled tasks through Telegram. Claude Projects handles heavier analysis and writing work in the browser. They cover different parts of the workflow and do not overlap.

Originally published on FloxoLab.

Last verified: July 18, 2026.

Protect Your Automated Business Processes with n8n Error Workflows

Stepan Nikonov — Mon, 13 Jul 2026 05:25:59 +0000

A simple 2-node n8n workflow can alert you in Telegram, Slack, Google Chat, email, or another team channel when an automation fails, so leads, reports, invoices, and AI workflows do not break silently.

Automation is useful only when someone knows it is working. A lead follow-up workflow can fail, a Google Sheets sync can stop, an AI email routing workflow can hit an API limit, a CRM update can break because one field changed. If the workflow fails quietly, the business process is no longer automated. It is just invisible.

This is why every serious n8n workflow should have basic error handling. Not a complicated observability stack. Not an expensive monitoring tool. Just one small error workflow that sends an alert to the channel your team already checks when something breaks.

The goal is simple: protect automated business processes by turning silent workflow failures into visible alerts.

For small businesses running automated operations, this is often the missing reliability layer. Teams build useful n8n workflows for leads, email, reports, bookings, invoices, and internal operations, but forget the one question that matters after launch: who knows when it fails?

The 2-node workflow

The basic setup is intentionally small:

Error Trigger
-> Telegram, Slack, Google Chat, email, or webhook alert

The simplest error handler is just two nodes: Error Trigger receives the failed execution data, then your chosen messaging node sends the alert.

The n8n Error Trigger starts an error workflow when another workflow fails. n8n passes useful error data into that workflow, including details about the failed workflow and execution. The next node sends the alert to the place where the responsible person will actually see it.

You do not need an Edit Fields or Set node if your alert node can use the Error Trigger data directly. That is the cleanest version: Error Trigger into the message app. A formatting node is only useful when you want to rename fields, build a cleaner message once, or reuse the same prepared text in several alert destinations.

Error Trigger is the start of the shared alert workflow. It receives the error context from another workflow when that workflow fails.

Choose the alert channel your team already uses

I use Telegram because it is my main messenger. That matters, but Telegram is not the only option. The same pattern can send alerts to Slack, Google Chat, email, Microsoft Teams through a webhook, or another internal notification channel.

n8n has built-in nodes for Telegram, Slack, and Google Chat. If the team uses something else, a webhook or email alert can still work. The important decision is not the app name. It is whether the alert lands where the owner, operator, or support person already pays attention.

Why error alerts matter for business automation

Workflow failures are not just technical events. They are operational events.

If a lead capture workflow fails, a customer may never get a reply. If an invoice workflow fails, finance may miss a record. If an AI workflow fails, someone may assume a task was completed when it never ran. If a daily reporting workflow fails, the team may make decisions from stale data.

That is the real risk of automation: not that it fails, but that it fails quietly.

A small n8n Error Workflow helps with:

n8n workflow monitoring without a paid monitoring platform.
Telegram, Slack, Google Chat, email, or webhook alerts for failed lead follow-up automations.
Faster debugging for AI automation workflows with API calls.
Visibility when Google Sheets, Airtable, Notion, CRM, Gmail, Slack, or webhook steps fail.
Basic protection for automated business processes after launch.

What the alert should include

The message does not need to be fancy. It needs to make the first response faster.

n8n workflow failed

Workflow: Lead Intake to Google Sheets
Failed node: HTTP Request - CRM update
Error: 401 Unauthorized
Execution: https://your-n8n-domain/workflow/...
Time: 2026-05-19 09:30 Asia/Manila

First check: credentials, API quota, or changed field mapping.

Good alerts reduce guessing. The best version includes the workflow name, failed node, error message, execution URL, and timestamp. If the workflow supports an important business process, add a short note about what to check first. Once an alert lands, the next step is finding the cause, which is the whole of how to debug failed n8n workflows.

This example uses Telegram because it is my main messenger, but the same alert text can be sent through Slack, Google Chat, email, or a webhook.

Where this helps most

This pattern is useful anywhere n8n is moving important information between tools.

Lead capture automation: form, Facebook lead, or website inquiry into Google Sheets, Airtable, Notion, or a CRM.
Email routing automation: Gmail or inbox classification that sends sales, support, admin, or invoice messages to the right place.
AI automation workflows: OpenAI, Claude, or other AI API calls that may fail from rate limits, invalid input, or service issues.
Reporting workflows: daily or weekly summaries sent to Telegram, Slack, Google Chat, email, or a dashboard.
Operations workflows: booking updates, payment checks, fulfillment steps, document generation, and internal handoffs.

In all of these cases, the error workflow does not fix the failed automation by itself. It does something more basic and usually more valuable: it tells the right person fast.

How to connect it in n8n

Create one workflow whose first node is Error Trigger. Connect it directly to Telegram, Slack, Google Chat, email, or your chosen alert destination. If the message expression becomes too messy, add an optional Edit Fields node between them to shape the alert text.

After that, open the workflow you want to protect and set its error workflow in the workflow settings. n8n documents this under error handling. Once configured, failed production executions can trigger the shared error handler.

The practical setup looks like this:

Create the shared alert workflow: Error Trigger -> your messaging or webhook node.
Save and activate the alert workflow.
Open another workflow, such as a lead capture, email routing, AI draft, or reporting automation.
Open that workflow's settings.
Find the Error Workflow setting and select the shared alert workflow.
Save the protected workflow.
Repeat the same setting on any other production workflow that should alert you when it fails.

Each production workflow can point to the same shared error handler from its workflow settings.

This is why the pattern scales well. The alert workflow stays in one place, while many different n8n workflows can point to it from their settings.

The result is intentionally simple: an alert in the place you already check. In my setup, that place is Telegram.

One shared error workflow can protect multiple automations. That is the nice part. You do not need to rebuild the same alert branch inside every workflow.

What this does not replace

Error alerts are not the same as backups, server monitoring, credential management, or security hardening.

An n8n Error Workflow tells you when an n8n workflow fails. It does not tell you that your VPS is down before n8n can run, that Cloudflare cannot reach the origin, or that your database backup failed. Those need separate checks.

The right reliability setup is layered:

Error Workflow for failed n8n executions.
Website uptime workflow for HTTP 500, 522, timeout, or missing page content.
Backups for n8n credentials, workflows, database, and environment configuration.
Basic server hardening and firewall rules for self-hosted automation stacks.

The small reliability habit

The best business automation is not the workflow with the most nodes. It is the workflow a team can trust, inspect, and recover when something goes wrong.

A 2-node n8n Error Workflow is a small habit, but it changes the operating model. Instead of hoping that lead follow-up, email routing, AI tasks, and reporting workflows are still running, you get a direct chat alert when they need attention.

That is enough to protect many automated business processes before they become silent operational problems.

I originally published this on my site, FloxoLab, where I document practical automation and technical SEO for small business in the Philippines. If a workflow here is useful for your team, get in touch.

Website Uptime Monitoring with n8n

Stepan Nikonov — Mon, 06 Jul 2026 01:21:10 +0000

A 4-node workflow checks your website every 5 minutes and sends a Telegram, Slack, or Google Chat alert the moment it goes down, so you find out before a customer does.

Most small business websites do not go down often. But when they do, the owner usually finds out the wrong way: a message from a customer saying the site is not loading, or a drop in bookings that only becomes obvious the next day.

A basic uptime monitoring workflow changes that. Instead of waiting for someone to notice, n8n checks your site on a schedule and sends a direct alert to the place you already look when something needs attention: Telegram, Slack, Google Chat, or email.

Trigger	Check	Alert
Every 5 minutes	HTTP GET + status code	Telegram (or Slack / Google Chat)

The workflow

The whole setup fits in four nodes:

Schedule Trigger (every 5 min)
-> HTTP Request (GET your site)
-> IF (status code not 200?)
  -> true: send alert
  -> false: do nothing, site is up

The false path connects to nothing. The workflow only acts when there is a problem. No alert means the check passed.

How each node is configured

The false path does nothing on purpose.

No alert means the site responded with 200. The workflow stays quiet until something actually breaks.

Schedule Trigger: set to every 5 minutes. That gives a maximum 5-minute window before an alert fires. A 1-minute interval would generate noise from transient blips that recover on their own.

HTTP Request: method GET, URL is the site homepage or a lightweight status endpoint. Set a Timeout of around 10 000 ms. If the server takes longer than 10 seconds to respond, it is effectively down for a real user. In Settings, enable Continue on Fail so a completely unreachable server does not stop the workflow before it reaches the IF node.

IF node: condition checks whether statusCode is not equal to 200. True path triggers the alert. False path is left unconnected.

Telegram node: sends the alert message. n8n has native nodes for Telegram, Slack, and Google Chat. The channel matters less than whether the responsible person will actually see the message when it arrives.

The alert message

The message uses node name referencing to pull the status code from the HTTP Request result:

🔴 Site Down Alert

Site: yoursite.com
Status: {{ $('Check Site').item.json.statusCode ?? 'offline' }}
Time: {{ $now.toISO() }}

Checked by n8n monitoring workflow.

The alert fires in Telegram when the site check fails. Same pattern works in Slack, Google Chat, or email.

What to check when the alert fires

Cloudflare dashboard first. Sometimes the origin is up but Cloudflare is returning a cached error or a 522. The dashboard shows recent errors and whether the issue is between Cloudflare and the origin.
Open the site from a different network. Rules out a local DNS or ISP issue.
Check the VPS or hosting control panel. A crashed process, full disk, or out-of-memory condition takes the site down without an application-level error.
Check the n8n execution log. The HTTP Request output shows the exact status code and response body.

Monitoring multiple sites

For several URLs, add a Loop Over Items node before the HTTP Request. Keep the URL list in a Code node or Google Sheets row, process each one at a time, and include the site URL in the alert message so you know which one triggered.

For two or three sites, duplicating the workflow per site is simpler and easier to debug than building a loop.

This workflow handles HTTP-level availability. It complements, but does not replace, n8n Error Workflow alerts, which protect your automations from failing silently. One watches the infrastructure, the other watches the workflows running on top of it.

How to Debug Failed n8n Workflows: Step-by-Step Guide

Stepan Nikonov — Sun, 28 Jun 2026 20:41:45 +0000

A workflow failed. The execution log shows a red node, but the error message is not obvious. This guide covers where to look first, how to reload real data and rerun, and the five errors that cause most n8n failures.

Most n8n failures are not mysterious. They repeat the same patterns: a credential expired, an expression pointed to the wrong field, a webhook URL was the test one instead of the production one. The hard part is knowing where to start when all you see is a red node and a generic error message.

This guide walks through the tools n8n gives you for debugging, the five errors that cover most real-world failures, and two nodes that help you handle failures more intentionally going forward.

1. Start with Execution History

Every time a workflow runs, n8n records the execution: what data came in, what each node did, and where it stopped. This is the first place to go after a failure.

Open the workflow and select the Executions tab at the top. You will see a list of past runs with their status: Success, Failed, or Waiting. Select a failed one to open it.

Inside the execution view you can see the canvas in its failed state: the node that caused the failure is marked in red, and the bottom panel shows the error message and the log. This tells you which node broke and what the error was, before you touch anything.

The Executions tab shows past runs with their status. Open a failed execution to see which node broke, read the error message in the log panel, and find the Debug in editor button in the top right corner.

Read the error message before doing anything else. Many failures explain themselves: "401 Unauthorized", "Cannot read properties of undefined", "The provided authorization grant is invalid". The node name plus the error text is usually enough to know what went wrong.

2. Debug in Editor: reload real data and rerun

Once you understand what failed, use the Debug in editor button. This loads the actual input data from the failed execution into your current canvas. You can then make changes to the broken node and rerun the workflow using the same real data, without needing to trigger a new event.

After clicking Debug in editor, the canvas loads the data from the failed execution. Fix the broken node and rerun with the same real input. No need to trigger a new event.

This is especially useful for workflows triggered by external events: a form submission, a webhook call, or an email. Reproducing that exact input manually takes time. Debug in Editor gives you the original payload immediately.

For successful executions, the same panel offers Copy to editor instead. That is useful when you want to test changes against a known-good input rather than a failed one.

3. Retry a past execution

If you only need to run the failed execution again, you do not have to open the editor at all. n8n can rerun a past execution directly from the Executions tab, reusing the exact input data from the original run.

Hover over a failed execution in the list, or open it, and use the retry option. n8n gives you two choices:

Retry with original workflow: runs the execution again using the workflow exactly as it was when it first ran. Use this when the failure was temporary, like a rate limit or a service that was briefly down, and the workflow itself did not need changing.
Retry with currently saved workflow: runs the same input data through the latest saved version of the workflow. Use this after you have fixed the broken node, to confirm the fix against the data that originally failed.

Both options reuse the original trigger data from that execution, so you do not need to resend the webhook, resubmit the form, or wait for the next scheduled run. The retry appears as a new entry in the Executions list.

Retry is the fastest way to rerun an execution when you already know the cause. Debug in Editor is the better choice when you still need to inspect the data and change a node before running it again.

4. The 5 most common errors

These five patterns account for most of the failures you will actually see in production n8n workflows.

Credential or auth error (401, 403)

The node could not authenticate with the external service. Common causes: the credential expired, the API key was regenerated, OAuth tokens were revoked, or the connected account lost the required permissions.

Fix: open the node settings and re-test the credential. If it fails the test, reconnect or regenerate it in the credentials panel. For OAuth-based services like Gmail or Google Sheets, you may need to re-authorize from scratch.

A 403 is slightly different: the credential is valid but the account does not have permission to perform that specific action. Check the API scopes or the account's role in the connected service.

Expression error (undefined, wrong syntax)

An expression in a field is referencing a value that does not exist. The result shows [undefined] or the workflow throws a "Cannot read properties of undefined" error.

The expression editor shows [undefined] when the referenced field path does not exist in the input data. Open the left panel to inspect what fields are actually available.

Fix: click on the broken field to open the expression editor. On the left panel, expand the input data from the previous node and check the actual field names and structure. A common mistake is using {{ $json.name }} when the real field is nested: {{ $json.contact.name }}. Use the field browser to drag the correct path into the expression.

Webhook not firing (test URL vs production URL)

The workflow is active, the external service is configured, but no data arrives. This is almost always a test URL vs production URL mismatch.

n8n gives each webhook two URLs: one for testing (only works while the workflow is open in the editor), and one for production (only works when the workflow is active). If you configured your external service with the test URL and then activated the workflow, nothing will arrive because the test URL stops listening once you close the editor.

Both URLs are visible directly inside the Webhook node settings. Many people only notice the first one. The test URL is shown at the top; the production URL is listed below it. Copy the production URL and update it in the external service, then test by triggering the actual event from that service.

API timeout or rate limit (429)

The HTTP Request node or an API-connected node stops responding. You may see a 429 Too Many Requests error, or the execution simply times out.

n8n's default HTTP Request node timeout is 5 minutes (300,000 ms), but many workflows hit limits earlier because the external API enforces its own rate limits or because a slow response blocks the execution. A 429 means you are sending too many requests too fast.

Fix for rate limits: add a Wait node between batched requests to slow down the pace. Fix for timeouts: check whether the external API is responding at all (test it directly in a browser or with a manual HTTP call), then increase the timeout in the HTTP Request node settings if the service is just slow.

Data type mismatch (array vs object, null values)

A node expects a single object but receives an array, or a field contains null and the next expression tries to read a property from it. This often surfaces as "Cannot read properties of null" or unexpected behavior where only the first item is processed.

Fix: use the Input panel to inspect what the previous node actually returned. If it returned an array when you expected an object, add a Split Out node to break it into individual items before processing. If null values cause crashes, add an IF node upstream to filter them out before they reach the sensitive step.

5. Enable debug logging (self-hosted only)

If you run n8n on a self-hosted VPS and the execution log does not give enough detail, you can turn on verbose logging by setting N8N_LOG_LEVEL=debug in your .env file and restarting the container.

N8N_LOG_LEVEL=debug

With debug logging active, the server logs include detailed HTTP request and response data, credential resolution steps, and node input/output at each stage. This is useful for intermittent failures that are hard to reproduce by opening the editor: connection timeouts, credential handshake errors, and SSL issues tend to surface in the logs before they appear clearly in the execution view.

Reset after debugging. Debug output is verbose and will fill disk space quickly on a small VPS. Set N8N_LOG_LEVEL=info or remove the variable once you have found what you needed.

6. The Debug Helper node

Most n8n users do not know this node exists. The Debug Helper is a built-in utility node that lets you deliberately trigger different error types or generate random test data inside a workflow.

The Debug Helper node has four modes. Throw Error is useful for testing your error workflow before real failures happen in production.

The four modes are:

Do Nothing: passes through without doing anything. Useful as a placeholder.
Throw Error: deliberately fails the workflow with a message you specify. Use this to test your error handling before a real failure happens.
Out Of Memory: generates a large memory allocation to simulate an out-of-memory error. Useful for stress-testing self-hosted setups.
Generate Random Data: produces random structured data. Useful when you need test input but do not have a real event to trigger the workflow.

The most practical use of Debug Helper for most workflows: add it temporarily before your error-handling path and set it to Throw Error. This lets you verify that your Error Workflow actually fires and sends the alert before you see a real failure in production.

7. Stop And Error: controlled failures with clear messages

Sometimes a workflow should stop not because something broke unexpectedly, but because the data does not meet a condition you care about. An empty response from an API, a missing required field, a contact that should not be there. Without explicit handling, the workflow either completes silently or fails with a confusing message.

Stop and Error lets you define exactly when and why a workflow should fail, with a message that makes the cause clear in the execution log and in any error alerts.

The Stop And Error node ends the workflow at that point and marks the execution as failed, with the message you provide. Two error types are available: Error Message (a plain text string) or Error Object (a JSON object with structured error properties).

Used with an IF node upstream, this gives you intentional failure points. The workflow says "no valid email found, stopping here" instead of crashing three nodes later with a cryptic null reference. When that controlled failure triggers your error alert, the message is already readable.

Stop And Error can only be placed as the last node in a workflow branch. It is not a mid-flow control node.

Connect failures to alerts

Debugging after a failure is reactive. The better habit is knowing about failures before someone else does.

n8n's Error Trigger runs a separate workflow when any production workflow fails. That separate workflow sends an alert to Telegram, Slack, Google Chat, email, or wherever your team already pays attention. For small businesses in the Philippines and anywhere else running automated operations, this is the layer that turns silent failures into visible ones. The execution log gives you the workflow name, failed node, error message, and a link back to the execution.

The full setup, including what the alert should contain and how to point multiple workflows at a single shared error handler, is covered in the n8n error workflow and chat alerts guide.

n8n rerun and retry: common questions

How do I rerun a failed execution in n8n?

Open the Executions tab, hover over the failed run, and choose a retry option. Retry with original workflow reruns it exactly as it was; Retry with currently saved workflow runs the same input through your latest saved version. Both reuse the original trigger data, so you do not need to trigger the workflow again.

What is the difference between Retry with original workflow and Retry with currently saved workflow?

Retry with original workflow runs the execution using the workflow exactly as it was when it first ran, which suits temporary failures like rate limits or a service that was briefly down. Retry with currently saved workflow runs the same input through the latest saved version, which is what you want after fixing the broken node.

Does retrying an n8n execution reuse the original data?

Yes. Both retry options replay the original trigger and input data from the failed execution. You do not need to resend a webhook, resubmit a form, or wait for the next scheduled run.

Can I rerun an n8n workflow from a specific node?

Use Debug in editor to load the failed execution's data onto the canvas, then run a single node or the steps after it without retriggering the whole workflow. This is the better option when you need to change a node before running it again.

Self-hosted n8n Deployment with Docker, Cloudflare, and PostgreSQL

Stepan Nikonov — Mon, 22 Jun 2026 21:02:12 +0000

A private automation server setup for real workflows: domain, Cloudflare proxy, VPS, Docker, n8n, PostgreSQL, HTTPS, and basic hardening.

This setup gives n8n a private place to run real automations: a domain behind Cloudflare, a VPS running Docker, PostgreSQL for workflow data, HTTPS for the editor, and backups to Google Drive. It is the infrastructure layer behind form workflows, chatbots, API jobs, and internal tools.

Domain to Cloudflare to VPS to Docker to n8n.
Public traffic, containers, workflow logic, and storage are separated into clear layers so the automation workspace is easier to inspect, restart, and maintain.

Layer	Detail
Public layer	Domain, Cloudflare proxy, HTTPS
Runtime	VPS at about $7/mo, around PHP 430
Workflow layer	30+ workflows in the workspace

Why this setup

A default n8n install can be useful for testing, but a real automation workspace needs a little more structure. The goal here was to make the server usable for private workflows, webhooks, form automations, API jobs, and internal bots while keeping the public surface understandable.

Cloudflare sits in front of the domain, HTTPS is enforced in the browser, Docker keeps services isolated and restartable, and PostgreSQL gives n8n a proper database layer instead of treating the server as a disposable demo.

This setup runs on a VPS that costs about $7 per month, roughly PHP 430, which is enough for a focused workspace with dozens of small workflows.

Proof screenshots

Cloudflare DNS proxy is enabled so the public entry point is not a raw VPS port. IP values are hidden.

n8n and PostgreSQL run as Docker services with multi-day uptime. PostgreSQL was added later, so its uptime can be newer than other services.

A private n8n workspace with 30+ workflows across drafts, prototypes, and live automations.

HTTPS is active for the n8n domain. The admin path is hidden in the screenshot.

What was configured

Domain and proxy — Cloudflare DNS and proxy are used in front of the VPS, with sensitive origin details hidden from public screenshots.
Docker runtime — n8n and supporting services run as containers so the stack can be restarted, inspected, and extended without mixing every service directly into the host.
PostgreSQL — added as the database layer for n8n. The container is newer because it was introduced as a setup refinement.
HTTPS — the workflow UI loads over HTTPS, so operators are not using the admin surface over plain HTTP.
Basic hardening — small-business practical hardening: Cloudflare in front, HTTPS enforced, firewall rules for required access, and backups rather than an open default install.

This is not described as enterprise infrastructure. It is a practical self-hosted automation foundation for small workflows and internal tools, with the sensitive details removed from public screenshots.

Good fits

Owner-run operations — a small business that wants leads, forms, email drafts, and internal alerts running from one private n8n workspace instead of scattered one-off tools.
VA and service teams — a VA agency or ops team running several client intake workflows from one server, with separate workflows for forms, CRM updates, reports, and review queues.
Webhook-heavy tools — teams that need stable public endpoints for website forms, chatbots, payment events, WooCommerce actions, Airtable updates, or Google Workspace jobs.
Zapier-style migration — teams moving recurring automations into a private workflow engine where the logic is visible, documented, and easier to inspect before scaling further.

Backup and maintenance layer

The server and n8n setup already have backups going to Google Drive. That matters because a self-hosted automation server is not only about getting n8n online. It also needs a way to recover workflows, credentials, and service data if an update, server issue, or configuration mistake breaks something.

The maintenance plan is simple: keep restore steps, update notes, and basic monitoring close to the deployment so the setup is easier to maintain over time.

Related guide

Self-hosting changes the cost math against managed tools. For a side-by-side on what each option actually costs, read Zapier vs Make vs n8n Pricing: A Real Lead Form Example.

I originally published this on my site, FloxoLab, where I document practical automation and technical SEO for small business in the Philippines. If you already have a VPS and need n8n configured properly (domain, Cloudflare, Docker, HTTPS, PostgreSQL, backups, handover notes), get in touch.