ForEach icon
Set icon

Add multiple Redis keys in parallel from JSON input

Fan out a JSON array into parallel Redis SET operations with Kestra. Declarative YAML, configurable concurrency, retries, and full run lineage.

Categories
CoreData

Loading many keys into Redis one request at a time is slow, and hand-writing a loop with connection handling, error checking, and concurrency control is tedious. This blueprint takes a JSON array supplied at runtime and fans it out into parallel Redis SET operations, writing one key per array entry against your Redis data store. It is a clean pattern for warming caches, seeding lookup tables, or bulk-populating feature flags and configuration keys.

How it works

  • The values input accepts a JSON array, where each element is an object whose key becomes the Redis key and whose value list seeds the Redis value.
  • The parallel task (io.kestra.plugin.core.flow.ForEach) iterates over {{ inputs.values }} with concurrencyLimit: 0, so every entry runs at the same time instead of sequentially.
  • For each item, the set task (io.kestra.plugin.redis.string.Set) connects to Redis over url and writes a key derived from {{ json(taskrun.value) | keys | first }} with serdeType: STRING.
  • The value is extracted from the entry with a jq expression ({{ taskrun.value | jq('.[]') | first }}), taking the first element of the nested list.

What you get

  • Parallel writes that scale with input size rather than running key by key.
  • A single declarative file you can version, review, and replay.
  • Per-iteration task runs, each visible and independently retryable.
  • A reusable template for any bulk key-loading job into Redis.

Who it's for

  • Platform and backend engineers seeding caches or configuration stores.
  • Data engineers populating Redis lookup tables from upstream pipelines.
  • SRE and DevOps teams managing feature flags and runtime settings.

Why orchestrate this with Kestra

Redis itself has no scheduler, no retry policy, and no run history. Kestra adds event and schedule triggers, automatic retries on transient connection failures, and full execution lineage so you can see exactly which keys were written and when. The whole job is declarative YAML, so the fan-out logic and concurrency control live in source control instead of a one-off script.

Prerequisites

  • A running Redis instance reachable from Kestra at the configured url.
  • The Redis plugin available in your Kestra installation.

Secrets

This flow connects to Redis with an unauthenticated url and references no secrets. If your Redis requires credentials, store them with {{ secret('REDIS_URL') }} and reference that in the url property.

Quick start

  1. Start a local Redis to test against: docker run --name myredis -p 6379:6379 -d redis.
  2. Add this blueprint to your Kestra instance.
  3. Adjust the url in the set task to point at your Redis host.
  4. Execute the flow, accepting the default values array or pasting your own.
  5. Inspect the keys in Redis (for example with redis-cli KEYS '*').

How to extend

  • Swap serdeType to JSON to store structured values instead of strings.
  • Cap parallelism by setting concurrencyLimit to a positive number.
  • Add a Schedule or event trigger to refresh keys on a cadence.
  • Chain a downstream task to validate or read back the keys after writing.

Links

Orchestrate with Kestra
Orchestrate Redis with Kestra
Share this Blueprint
See How

New to Kestra?

Use blueprints to kickstart your first workflows.