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:
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.
While Kestra validates flow syntax, it does not detect logical or runtime errors. Always test flows thoroughly before promoting them 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.
Note: If a flow contains invalid syntax, the Deploy Action will fail.
Was this page helpful?