Why orchestrate the sync
Files arrive unpredictably and formats vary. You want a pipeline that reacts to new files automatically, converts whatever format they’re in, indexes them reliably, and, crucially, processes each file exactly once. Kestra gives you a bucket trigger, format converters, and the Meilisearch task, wired together declaratively with full logging and retries.Prerequisites
A running Kestra with three plugins (Meilisearch, AWS, and the serdes plugin for CSV/JSON conversion), plus a Meilisearch Cloud project. Only Kestra runs locally, since Meilisearch is managed:Get your Cloud credentials. In the Meilisearch Cloud dashboard, create a project and copy its Project URL (the
url in the flows below) and its Default Admin API Key (Settings, then API Keys). Store both AWS and Meilisearch credentials as Kestra secrets. This guide shows an S3-compatible endpoint (MinIO) with inline keys for clarity. For real AWS S3, drop endpointOverride / compatibilityMode / forcePathStyle and supply accessKeyId / secretKeyId (or an IAM role) via secrets.games.csv file with columns id,title,platform,genre,rating.
Step 1: The first load (backfill)
Three steps: download the object, convert CSV to Kestra’s ION format, and index it. The serdes plugin bridges the format gap:DocumentAdd speaks ION, and CsvToIon produces exactly that.
CsvToIon for JsonToIon or AvroToIon if your files arrive in those formats. The rest of the pipeline is identical.
One thing to know about CSV: CsvToIon emits every column as a string ("rating":"96"). If you want to filter or sort numerically in Meilisearch, either cast the values in a transform step, or configure the attribute accordingly and rely on Meilisearch’s numeric handling.
Step 2: Event-driven sync (files as they arrive)
The backfill indexes a file you name explicitly. The real workflow is: a new file lands in the bucket and gets indexed on its own. Kestra’s S3Trigger polls a prefix and starts an execution whenever new objects appear, and it can move or delete each object after it’s handed off, giving you exactly-once processing.
Put incoming files under an incoming/ prefix and let the trigger drain it:
incoming/ every ten seconds. When a file appears, it downloads it into Kestra’s internal storage (available as {{ trigger.objects[0].uri }}), fires the flow, and then deletes the object from the bucket per action: DELETE. The flow converts and indexes it. Drop a CSV, and its rows are searchable seconds later, hands-off.
Prefer to keep an audit trail of processed files? Use action: MOVE with a moveTo destination to archive each object into a processed/ prefix instead of deleting it.
Handling updates and deletes
Object drops are naturally an upsert stream: becauseDocumentAdd is add-or-replace, a file re-exported with corrected rows overwrites the matching documents by primary key when it’s dropped again. No special handling needed for updates.
Deletes are the one case files don’t express well: a file that simply stops appearing can’t tell Meilisearch to remove anything. Two options:
- Include a
deletedmarker column in your exports and add a branch that calls Meilisearch’sdocuments/delete-batchendpoint for those ids (the pattern is shown in Connect PostgreSQL to Meilisearch with Kestra). - For full-snapshot files, periodically re-index into a fresh index and swap it in with an index alias, so removed rows disappear.
Going to production
- Real AWS S3: remove
endpointOverride,compatibilityMode, andforcePathStyle. Authenticate with an IAM role or withaccessKeyId/secretKeyIdpulled from Kestra secrets. - Large files:
CsvToIonandDocumentAddstream through internal storage and batch automatically, so multi-gigabyte files work without tuning. RaiseDocumentAdd’sbatchSizeif you want fewer, larger indexing tasks. - Multiple files at once: the trigger surfaces every matched object in
{{ trigger.objects }}. Loop over them with anEachSequential/ForEachtask if a poll can pick up more than one file. - Retries: add a
retryblock so a transient S3 or Meilisearch hiccup self-heals rather than failing the execution.