Using system readOnly label to disable editing the flow from UI

Protect critical Kestra workflows from accidental UI changes by setting the built-in system.readOnly system label to true. Once applied, the flow can still execute, be triggered, and emit logs, but the editor in the Kestra UI blocks any modification. This is essential for production pipelines deployed through GitOps, CI/CD, or Terraform, where the source of truth lives in a Git repository and ad hoc UI edits would silently drift from version control.

How it works

This is a minimal example flow that demonstrates the read only behavior:

1. The flow declares the system label system.readOnly: "true" at the top level. Kestra recognizes the system. label prefix as a reserved namespace for platform behaviors.
2. A single io.kestra.plugin.core.log.Log task prints Hello from a read-only flow! so you can confirm execution still works after the lock is applied.
3. When you open the flow in the Kestra UI, the source editor and the visual editor are disabled. You can read the YAML, view executions, and trigger runs, but the Save button is removed.

To unlock the flow, remove the system.readOnly label from the YAML in your Git repository and redeploy.

What you get

• UI-level write protection for any flow you want to manage as code.
• Clear signal to engineers and operators that the flow is owned by a pipeline, not by the UI.
• No impact on executions, triggers, schedules, or webhooks: the flow runs exactly as before.
• A pattern you can apply across hundreds of flows by adding the label in your CI/CD templates.

Who it's for

• Platform and DevOps teams enforcing GitOps for Kestra.
• SREs protecting production orchestration from drift.
• Data engineering leads who deploy flows from a monorepo and need guardrails for less senior users with edit permissions.
• Anyone running Kestra in a regulated environment where change control requires every flow edit to go through review.

Why orchestrate this with Kestra

System labels like system.readOnly are a Kestra-native feature that no external scheduler offers, because the lock lives inside the flow definition itself rather than in a separate access control layer. Combined with Kestra's declarative YAML, event triggers, automatic retries, and full execution lineage, you get a single source of truth in Git plus runtime safety in the UI. RBAC controls who can deploy; the system.readOnly label controls what can be edited in place, even by users with broad permissions.

Prerequisites

• A running Kestra instance (OSS or Enterprise).
• Permission to deploy flows to your target namespace.

Secrets

This blueprint uses no secrets. The system.readOnly label is a flow-level setting, not a credential.

Quick start

1. Copy this blueprint into your Kestra instance or your Git repository.
2. Update the namespace to match your environment, for example company.production.
3. Deploy the flow through the UI, the CLI, or your CI/CD pipeline.
4. Open the flow in the Kestra UI and confirm the editor is locked.
5. Trigger an execution to confirm the log task still runs.

How to extend

• Combine system.readOnly with other system labels such as system.disabled to fully pause a flow.
• Add this label to a shared CI/CD template so every production flow is locked by default.
• Pair with RBAC to allow only a service account to push changes through Git, while human users see a read only view.
• Use the label as a marker for audit tooling that inventories which flows are GitOps-managed.

Links

• Kestra core plugin: https://kestra.io/plugins/core