Problem
One of the use cases for automations is implementing integrations. Some integrations are stateless—webhook responders that receive an event, do work, and complete. But other jobs require small amounts of data storage to work effectively.
For example, an automation that summarizes Slack messages might store the last processed timestamp, then on the next run fetch only items since that date. But where should it store this data?
A GitHub repo isn't the right tool. External services (JSONBin, Redis Cloud, etc.) work but require users to provision and manage infrastructure. If external systems are required for such a common use case, that erodes the simplicity of a batteries-included platform.
Solution
A built-in key-value store API scoped per-automation:
- Easy — simple GET/SET, familiar Redis-like semantics
- Flexible — JSON values, counters, lists, nested paths
- Secure — application-level encryption, strict isolation between automations
We don't need high performance—just simplicity and security for occasional state persistence.
Implementation
See design document in PR #68.
This issue was created by an AI agent (OpenHands) on behalf of the user.
Problem
One of the use cases for automations is implementing integrations. Some integrations are stateless—webhook responders that receive an event, do work, and complete. But other jobs require small amounts of data storage to work effectively.
For example, an automation that summarizes Slack messages might store the last processed timestamp, then on the next run fetch only items since that date. But where should it store this data?
A GitHub repo isn't the right tool. External services (JSONBin, Redis Cloud, etc.) work but require users to provision and manage infrastructure. If external systems are required for such a common use case, that erodes the simplicity of a batteries-included platform.
Solution
A built-in key-value store API scoped per-automation:
We don't need high performance—just simplicity and security for occasional state persistence.
Implementation
See design document in PR #68.
This issue was created by an AI agent (OpenHands) on behalf of the user.