Skip to content
Nappai Documentation

In-Memory Store

The In-Memory Store component serves as a temporary “brain” for your data within a specific automation flow. Think of it as a digital sticky note or a scratchpad that exists only while your workflow is running.

Its primary purpose is to store data in your computer’s RAM (Random Access Memory) rather than on a hard drive or in a database. This makes it extremely fast for retrieving information, but the data will disappear once the workflow finishes or the application closes. It is ideal for storing intermediate results, caching information for quick access during a single process, or passing data between steps without saving it permanently.

How it Works

This component works by creating a temporary container in your system’s memory. When you provide data to it, it places that data in a “dictionary” structure, allowing for instant retrieval later in the same workflow.

Because it uses RAM, the access speed is nearly instantaneous compared to writing data to a disk. However, this comes with a key limitation: it is not persistent. If you close the workflow, restart the application, or encounter an error that stops the process, all stored data will be lost.

The component is designed for development and testing environments (is_development = True), meaning it is optimized for speed and flexibility rather than strict long-term data security. It does not connect to external servers or databases; all processing happens locally within the Nappai environment.

Connection & Credentials

This component does not require any external API keys, passwords, or credential configuration. It operates entirely within the local environment of your Nappai workflow. You can use it immediately without setting up any authentication details.

Operations

This component is a single-action node focused on managing data in memory. You do not need to select specific “operations” like Save or Load; the component handles the storage and retrieval logic automatically based on the inputs you provide.

Inputs

The following fields are available to configure this component.

  • Key: A unique identifier (text string) for the data you are storing. You can think of this as the “name” or “label” for the data you are saving so you can find it again later in the workflow. This is required for storing or retrieving specific items.
  • Value: The actual data you want to store. This can be text, numbers, lists, or other data structures. This input allows you to put information into the store.
  • Embedding: A required connection to an Embedding Model component. This field is used to convert text data into numerical vectors for semantic search. Connect a component such as OpenAI, HuggingFace, or a local model here to enable the component to understand and process the meaning of the text you are storing.

Visible in: Standard Workflow Execution

Outputs

The component produces the following outputs when executed:

  • Checkpointer: This output serves as a checkpoint in your workflow. It outputs the stored data (or a reference to it) so that subsequent components in your workflow can use the information you just saved. This allows you to chain actions together, ensuring that data flows smoothly from one step to the next.

Output Data Example (JSON)

The Checkpointer output will typically return the data you stored, structured as follows: json { “checkpointer_data”: { “status”: “success”, “stored_items”: { “key_1”: “This is the value associated with key_1”, “key_2”: [“Item A”, “Item B”] }, “timestamp”: “2023-10-27T10:00:00Z” } }

Connectivity

In a typical Nappai workflow, the In-Memory Store acts as a bridge between data-producing components and data-consuming components.

  1. Connect From: It typically receives data from components that generate information, such as Text Processors, Data Extractors, or LLM (AI) responses. You will connect the output of these components to the Value or Embedding inputs of the In-Memory Store.
  2. Connect To: Its Checkpointer output is usually connected to downstream components that need to access that stored data. For example, you might connect it to a “Data Aggregator” or a “Report Generator” that needs to read the information saved in memory.

This connection pattern ensures that complex data can be stored temporarily and then retrieved exactly when needed, keeping your workflow organized and efficient.

Usage Example

Imagine you are building an automation that analyzes customer feedback emails.

  1. You use an LLM Component to summarize each email.
  2. You connect the summary to the Value input of the In-Memory Store, using the email ID as the Key. This saves each summary in memory.
  3. You also connect an Embedding Model to the Embedding input to ensure the text is processed correctly.
  4. Finally, you connect the Checkpointer output to a Dashboard Component that displays all the saved summaries at the end of the workflow.

This allows you to gather individual summaries and then view them all together, without needing a permanent database.

Tips and Best Practices

  • Keep Keys Unique: Use distinct keys for different pieces of data to avoid accidentally overwriting information. For example, use the item ID or email address as the key.
  • Best for Small Data: Since this stores data in RAM, it is best suited for small to medium-sized datasets. Avoid storing massive files or huge lists, as this might slow down your workflow.
  • Test Your Flows: Since data is lost when the workflow stops, always test your workflow from start to finish to ensure data flows correctly from the store to the next component.

Security Considerations

  • Data Disappears on Restart: Remember that data stored in this component is not saved permanently. Do not use this component to store sensitive information (like passwords or credit card numbers) that needs to be saved for future use.
  • Local Environment Only: All data stays within the local Nappai environment. However, since it is a development-mode component, be mindful of what you store if you are sharing workflows with other users.
  • Embedding Security: Ensure that the Embedding Model you connect to complies with your organization’s data privacy policies, as text data will be sent to that model for processing.