​Moving from ​Development to ​Production

Common patterns for deploying flows from development to production environments.

Development environment

A best practice with Kestra is to maintain a dedicated development instance where users can create and test flows safely. This environment acts as a sandbox, allowing experimentation without impacting production or critical business operations.

You can set up a development environment in one of the following ways:

• Install Kestra locally using Docker Compose
• Deploy Kestra on a Kubernetes cluster accessible to users and isolated from production workloads

Production environment

The production instance should be secured and tightly controlled, as it runs critical workflows that directly impact end users.

A common best practice is to limit access to production systems. Two areas should be considered:

• User access
• Flow deployments

User access

In Kestra Enterprise, user management is streamlined through RBAC and SSO.
Administrators can define fine-grained access using role policies such as Admin or Viewer, ensuring proper access control across all resources. Learn more in the Enterprise documentation.

For open-source users, it’s recommended to run a restricted production instance, accessible only to administrators and your CI/CD system.

Flow deployments

Kestra supports several deployment strategies:

• Via the UI
• Git synchronization
• CI/CD pipelines
• Terraform
• API

Choose a method that aligns with your organization’s existing deployment processes.

A common approach is to move flows from development to production using a version control system (such as Git) combined with CI/CD automation.

In this pattern, developers commit flow changes to Git. Once the pull request is approved, the CI/CD system deploys the updated flows to the production instance.

Flows can be committed to Git using:

• Manual export or copy-paste from the UI
• The git.PushFlows task

CI/CD deployment to production can be automated with:

• GitHub Actions, GitLab CI/CD, Jenkins, or Azure DevOps
• Terraform
• The Kestra CLI

For more details on CI/CD automation, refer to the CI/CD guide.

Git example

You can use the git.SyncFlows task together with a trigger to automatically pull flows from the main branch of your Git repository.

This enables Kestra to manage the synchronization process directly, minimizing the need for external tools.

You can schedule synchronization using:

• A Schedule trigger to pull flows at regular intervals (e.g., nightly)
• A Webhook trigger to pull updates whenever new commits are pushed to main

See the dedicated SyncFlows guide for details.

To push flows from development to Git, use the git.PushFlows task.
This ensures flows are validated before being saved—Kestra will reject invalid flows automatically.

You can also automate pull requests with the create.Pulls task, which creates a PR to main for review before deploying to production.

CI/CD example

CI/CD pipelines can automatically deploy flows from Git to your Kestra production instance when changes are merged into the main branch.

For GitHub, Kestra provides an official Deploy Action that uses the Kestra Server CLI behind the scenes to perform deployments.
You can pair this with the Validate Action, which checks that flows are valid before merging.

By enforcing required status checks on pull requests, you can prevent invalid flows from being merged and deployed to production.