Store and retrieve JSON data using Redis

Store a JSON document in Redis under a chosen key and read it back, all from a declarative Kestra workflow. This blueprint shows the round trip every Redis-backed pipeline relies on: write a value, then fetch it, with the key and payload supplied as runtime inputs so the same flow can manage cache entries, feature flags, session state, or shared data between tasks without code changes. Kestra handles JSON serialization on the way in and deserialization on the way out, so you work with structured objects instead of raw strings.

How it works

The flow accepts two inputs: a key (STRING, defaulting to johndoe) and a value (JSON, defaulting to a sample user profile object).

1. The set task (io.kestra.plugin.redis.string.Set) connects to Redis at the configured url and writes inputs.value under inputs.key. With serdeType: JSON, the structured input is serialized into the stored value automatically.
2. The get task (io.kestra.plugin.redis.string.Get) reads the same inputs.key back from Redis. Again serdeType: JSON is set, so the stored string is deserialized into a JSON object available to downstream tasks and the execution outputs.

What you get

• A working write-then-read pattern against any Redis instance.
• Automatic JSON serialization and deserialization via serdeType: JSON.
• Parameterized key and value, so the flow is reusable across many records.
• Retrieved data exposed as execution outputs for chaining into later tasks.

Who it's for

• Data and platform engineers using Redis as a cache or shared key-value store.
• Backend developers who need workflows to read and write application state.
• Teams coordinating data hand-off between pipeline steps through Redis.

Why orchestrate this with Kestra

Redis has no built-in scheduler or workflow engine: it stores data but cannot decide when to write, react to upstream events, or retry on failure. Kestra fills that gap. Define the logic as declarative YAML, drive writes from event triggers or schedules, attach retries so a transient connection blip does not lose a write, and capture full execution lineage so every read and write is auditable. The parameterized inputs let one flow serve many keys, and the retrieved value flows directly into downstream tasks.

Prerequisites

• A reachable Redis instance. The tasks point at redis://host.docker.internal:6379/0; adjust the url for your environment.
• The Kestra Redis plugin (bundled in standard distributions).

Secrets

This blueprint references no secrets: the connection url is set inline on the tasks. For production, move the connection string to a secret or environment variable and reference it with {{ secret('REDIS_URL') }}.

Quick start

1. Start a local Redis instance for testing: docker run --name myredis -p 6379:6379 -d redis.
2. Add this flow to your Kestra instance and confirm the url matches your Redis host.
3. Execute the flow with the default key and value, or supply your own at runtime.
4. Inspect the get task output to confirm the JSON value was written and read back.

How to extend

• Add a TTL or expiration policy to make entries self-clean as a cache.
• Replace the inline url with a {{ secret('REDIS_URL') }} reference for secure, environment-specific connections.
• Add a trigger so writes happen on a schedule or in response to an upstream event.
• Chain additional tasks that consume the retrieved JSON, for example enriching it or pushing it to another system.
• Loop over a list of records to populate many keys in a single execution.

Links

• Redis plugin documentation
• Orchestrate Redis with Kestra