A filesystem-based key-value store node for n8n

Feedback
1

I built this node end-to-end with Hermes Agent acting as the orchestrator. It took the initial specifications and guided the whole process, from implementation to publishing on npm. The node can store, retrieve, list and delete key-value pairs using plain directories and text files.

~/.n8n-keyvalue/          ← your store root
├── customers/            ← a directory
│   ├── alice             ← a record (text file)
│   └── bob
└── orders/
    ├── order_001
    └── order_002

The whole process requires methodology, clear specs and a lot of trial and error. It is not an easy process at all, but what a nice surprise when you see your own node running on the canva, doing exactly what was designed and expected :wink:

n8n_node
n8n_node2354×832 62.5 KB

1 Like
2
3

Nice execution on this - the directory-per-namespace approach keeps things tidy without needing a schema. One addition worth considering: a TTL (expiry) option per key, stored as a small metadata file (e.g., _ttl) in the same directory. That would make it useful for temporary session data, deduplication windows, and rate-limit tracking without needing a manual cleanup workflow. I’ve built similar things on top of static workflow data but the filesystem approach is much more persistent and inspectable.

4

No schema, very simple to implement. And content can be used outside of n8n (grep, cat, …)
TTL is a good idea.
I’m thinking about adding a counter/increment.
Right now, value is a string only. Maybe I should add Json as well so KeyValue can be used as a MongoDB-like system.

5

The n8n-nodes-keyvalue node just grew from a simple filesystem key-value store into a full Knowledge Management engine directly inside #n8n workflows. Three new resources were added alongside YAML frontmatter support across all existing Record operations.

Search brings full-text querying across every file in the store, both keys and content are indexed, with AND logic, occurrence scoring and context snippets around matches. You can find a convention buried in a hundred files with a single word. Combined with Tag Filter, search narrows to specific categories without touching irrelevant data.

Vault gives you cross-directory navigation that did not exist before. Tree renders the entire store structure as an ASCII diagram. Stats aggregates file counts, total size, unique tags and the last modified path in a single call. Recent surfaces recently changed files sorted by modification time, optionally filtered by tag. Backlinks detects cross-references between files, wiki links, exact paths, or bare filenames, so you can trace which documents reference a given rule or decision.

Tag aggregates all unique frontmatter tags across the vault with per-file counts, giving you a taxonomy overview without manual scanning.

Record operations gained YAML frontmatter awareness. Write accepts a Tags, Description and Updated (date) collection that gets serialized as a YAML block at the top of the file. Read offers three modes, Full returns everything including the parsed frontmatter, Frontmatter Only skips the content entirely, and Body Only preserves backward compatibility with existing workflows. List and Count and Delete all support Tag Filter for category-scoped operations, and List can optionally include frontmatter metadata per result.

:backhand_index_pointing_right: The immediate use case is an external memory system for Hermes Agent from Nous Research or any other AI agent. A single flat directory under the KeyValue store holds conventions, pitfalls, project context and user preferences as structured markdown files. One search call finds anything matching a keyword regardless of whether it lives in a coding rule, a project overview or a preference file, the taxonomy is in the tags, not the directory structure. Because the store is plain files on disk, any agent that can read and write text files can use it as persistent memory. But the same capabilities apply to any workflow that needs persistent, searchable, cross-referenced knowledge that survives restarts without a database. And because the access layer is an n8n node, workflows can inject, update and enrich that knowledge in context, a detection workflow can write a new convention, a monitoring workflow can append to a log, and the agent picks it up on the next search.

6

Hi @hsteph,

This is a great implementation. The directory-per-namespace approach is clean, especially since it avoids the overhead of managing a formal schema or a full SQL database for simple persistent storage.

To build on what you’ve already shipped, have you considered adding a TTL (Time-to-Live) mechanism?

If you store a small hidden metadata file (e.g., _ttl) alongside the record, you could implement an auto-expiry feature. It would be a significant value-add for use cases like:

  • Deduplication windows: Keeping track of processed IDs for a specific duration.

  • Rate-limit tracking: Preventing workflow over-execution.

  • Temporary session state: Cleaning up session data without requiring a manual maintenance workflow.

It’s definitely more “inspectable” and persistent than using Static Data in n8n, which can be tricky to debug at scale. Nice work getting this published to npm!