Multi-Tenant CI/CD, Promote Kestra Flows Across Environments and Tenants Automatically

Keeping development, QA, and staging tenants in sync by hand is slow and error prone. This system blueprint automates multi-tenant CI/CD for Kestra itself: it exports every flow from a source tenant and imports them into a target tenant on a daily schedule, using only the Kestra REST API. No external CI/CD tooling, manual ZIP downloads, or copy-paste promotion required, just a declarative flow that keeps environments aligned and repeatable.

How it works

1. The daily_at_5_pm trigger (io.kestra.plugin.core.trigger.Schedule, cron 0 17 * * *) starts the promotion run once per day.
2. The dev_flows task (io.kestra.plugin.core.http.Download) calls the Kestra API endpoint /api/v1/{tenantId}/flows/export/by-query with a Bearer token and downloads all source-tenant flows as a ZIP archive.
3. The import_to_staging task (io.kestra.plugin.core.http.Request) POSTs that archive as multipart/form-data to /api/v1/{newTenant}/flows/import, loading every flow into the target tenant.
4. A pluginDefaults entry forces a constant retry (3 attempts, PT1S interval) on all io.kestra.plugin.core.http tasks so transient API or network errors do not break the run.

What you get

• Hands-off promotion of all flows from one tenant to another.
• A single declarative YAML flow instead of bespoke scripts.
• Built-in resilience to flaky API calls via forced retries.
• A daily cadence that keeps non-production environments current.

Who it's for

• Platform and DevOps teams operating multi-tenant Kestra deployments.
• Enterprise organizations promoting flows through dev, QA, and staging.
• Anyone standing up a new tenant who needs to seed it with existing flows.

Why orchestrate this with Kestra

The Kestra API can export and import flows, but it cannot schedule, retry, or track the promotion for you. Kestra adds the orchestration layer: an event-driven Schedule trigger, automatic retry on HTTP failures, full execution lineage and logs for every promotion, and a declarative YAML definition you can version and review. The promotion pipeline itself becomes a governed, observable Kestra flow.

Prerequisites

• Two Kestra tenants (source and target) reachable over HTTP.
• A service account with permission to export and import flows.

Secrets

• API_TOKEN: a Kestra API token (Bearer) with rights to export from the source tenant and import into the target tenant.

Quick start

1. Store your token as the API_TOKEN secret in the system namespace.
2. Set the host variable to your Kestra instance hostname.
3. Set the newTenant variable to your target tenant id.
4. Add the blueprint and let the daily trigger run, or execute it manually to test.

How to extend

• Add an export/by-query filter to promote only flows from a given namespace or labels.
• Promote into multiple target tenants by adding more Request tasks.
• Replace the Schedule trigger with a webhook or a Git push to make promotion event-driven.
• Chain a notification task to report success or failure after each promotion.

Links

• plugin-core docs
• API tokens
• Secrets
• Plugin defaults
• Retries