ESC
Ask Kestra AI
ESC
Kestra AI

Hi! I'm your Kestra AI assistant.
Ask me anything about workflows.

EXAMPLE QUESTIONS

How to write expression for previous tasks outputs?
How to prevent concurrent execution of the same flow?
What are main differences between Open Source and Enterprise?

Security and
compliance at Kestra

For self-hosted deployments, your workflows and data stay in your infrastructure, under your control. This page covers our compliance posture as a company, the controls available in each edition, and what your security team needs for its review.

Visit the Trust Center

Compliance and certifications

Available from the Trust Center. Each copy is issued to the requester.

What the audit covers

The SOC 2 report examines Kestra Technologies and our managed service: how we build the software, and how we operate as a vendor. That includes secure development, code review, vulnerability management, access control, incident response and change management.

If you self-host, your deployment runs in your infrastructure and stays under your control. The hardening guide and the deployment architecture documentation cover that side.

The Trust Center also publishes live control monitoring, our subprocessor list, and downloadable policies:

  • Information Security
  • Vulnerability Management
  • System Access Control
  • Risk Assessment
  • Incident Response Plan
  • Encryption
  • Data Protection
  • Data Classification
  • Privacy
  • Data Retention
  • Asset Management
  • Business Continuity Plan
  • Software Development Life Cycle
  • Code of Conduct

Choose your deployment

Where Kestra runs decides who holds the data and who holds the operational burden.

Open source

Self-managed

Where it runs
Your infrastructure. Docker, Kubernetes or directly on a VM.
Who operates it
You. Patching, upgrades and infrastructure hardening are yours.
Where your data sits
Your database, your object storage, your network.
SOC 2 coverage
Covers how the software is built, not your deployment.

Enterprise Edition

Self-managed · air-gap capable

Where it runs
Your infrastructure, including on-prem and fully air-gapped environments.
Who operates it
You, with Kestra support. Patching and upgrades are yours.
Where your data sits
Your database, your object storage, your network. Kestra has no access.
SOC 2 coverage
Covers how the software is built, not your deployment.

Kestra Cloud

Fully managed

Where it runs
Managed by Kestra on Google Cloud.
Who operates it
Kestra.
Where your data sits
Your workflow data stays in the EU or US region you choose.
SOC 2 coverage
Covers the service end to end.

Multi-tenant deployments are supported through Kestra’s native multi-tenancy model, which enforces tenant and namespace isolation at the data and access layer.

Security controls

ControlDescriptionOSSEnterpriseCloud
SSOOIDC with Google, Microsoft Entra ID, Okta, Keycloak and authentik, plus LDAP.OIDC with Google, Microsoft Entra ID, Okta, Keycloak and authentik, plus LDAP.
SCIM directory syncSCIM 2.0 provisioning, deprovisioning and group sync from Okta, Entra ID, Keycloak and authentik.SCIM 2.0 provisioning, deprovisioning and group sync from Okta, Entra ID, Keycloak and authentik.
RBACRoles bound to users, groups and service accounts, scoped per namespace and inherited by child namespaces.Roles bound to users, groups and service accounts, scoped per namespace and inherited by child namespaces.
Service accounts and API tokensMachine-to-machine access, separate from user accounts.Machine-to-machine access, separate from user accounts.
Failed login lockoutAccounts lock after repeated failed attempts. Configurable threshold, window and duration. Applies to basic auth and LDAP users.Accounts lock after repeated failed attempts. Configurable threshold, window and duration. Applies to basic auth and LDAP users.
Built-in secrets managementCredentials never sit in flow definitions. Flows reference a key and the value resolves at runtime.Credentials never sit in flow definitions. Flows reference a key and the value resolves at runtime.
External secrets managersHashiCorp Vault, CyberArk, Delinea, BeyondTrust, AWS Secrets Manager, AWS SSM Parameter Store, Azure Key Vault, Google Secret Manager, 1Password, Bitwarden and Doppler.HashiCorp Vault, CyberArk, Delinea, BeyondTrust, AWS Secrets Manager, AWS SSM Parameter Store, Azure Key Vault, Google Secret Manager, 1Password, Bitwarden and Doppler.
Read-only vault accessYour vault stays the source of truth. Kestra reads but cannot create, edit or delete. Set globally, per tenant or per namespace.Your vault stays the source of truth. Kestra reads but cannot create, edit or delete. Set globally, per tenant or per namespace.
Encryption at rest (secret inputs and outputs)Secret-typed inputs and outputs are encrypted at rest with a key you configure.Secret-typed inputs and outputs are encrypted at rest with a key you configure.
Encryption in transit (UI and API)TLS on the UI and API.TLS on the UI and API.
Encryption in transit (workers)One-way or mutual TLS between the control plane and workers.One-way or mutual TLS between the control plane and workers.
Audit logsEvery create, update and delete by users and service accounts, with actor, timestamp and a before-and-after diff.Every create, update and delete by users and service accounts, with actor, timestamp and a before-and-after diff.
SIEM exportShip audit logs to Datadog, Elastic, New Relic, OpenTelemetry, AWS CloudWatch, Google Operations, Azure Monitor or Syslog CEF.Ship audit logs to Datadog, Elastic, New Relic, OpenTelemetry, AWS CloudWatch, Google Operations, Azure Monitor or Syslog CEF.
Tenant and namespace isolationSeparation of flows, secrets, files and access between teams and tenants.Separation of flows, secrets, files and access between teams and tenants.
Worker isolationForbidden file-system paths and a per-plugin allow-list for thread creation, so teams sharing a worker cannot read each other’s temporary files.Forbidden file-system paths and a per-plugin allow-list for thread creation, so teams sharing a worker cannot read each other’s temporary files.
Script execution isolationPolicies force script tasks into container isolation across every tenant, with no namespace override.Policies force script tasks into container isolation across every tenant, with no namespace override.
Allowed and restricted pluginsAllow-list or block-list plugins by prefix or regex.Allow-list or block-list plugins by prefix or regex.
Version controlEvery flow is versioned YAML with Git as the source of truth, plus full execution history with inputs, outputs and logs.Every flow is versioned YAML with Git as the source of truth, plus full execution history with inputs, outputs and logs.
Outbound request controlsAllow-lists and deny-lists on HTTP tasks, to block reach into cloud metadata endpoints or private services.Allow-lists and deny-lists on HTTP tasks, to block reach into cloud metadata endpoints or private services.

Enterprise and air-gapped deployments

Enterprise Edition runs entirely inside your infrastructure. Workers run inside air-gapped zones, never reaching the internet. The control plane usually sits outside that zone with internet egress, since it never touches the systems inside it and upgrades and plugin installs stay simple. Where policy requires it, the control plane can also run inside the air-gapped environment, installed from a private registry and with the configuration mode that removes external dependencies from the UI.

Workflow definitions, execution history, logs and secrets stay in your database, your object storage and your network. Kestra has no access to your environment. Anonymous usage reporting, in-product documentation and hosted blueprints are the only components that call out to Kestra, and air-gapped mode disables them.

Workers are the only component that reaches your private systems: hypervisors and vCenter, on-prem databases, ITSM, internal APIs, and equipment inside restricted OT environments. They connect outbound to the control plane over a single authenticated channel, hold no database credentials, and need no inbound firewall rule where they run.

Control Plane
Platform
Executor
Scheduler
Webserver
Databasereachable only from the platform
HTTPSTLS - mTLS
Data Planes
Workers
eu-westgpua100
on-prem VPCpcirestricted
air-gapped siteno database route
Download the security overview

How we build the software

  • Source code in version control with a documented code review process, covered by our SOC 2 Type 2 audit.
  • Vulnerability scanning across code and container images with GitHub Security, SonarCloud and Trivy.
  • A documented vulnerability management policy that defines how vulnerabilities are identified from external sources, risk-ranked, and resolved. Downloadable from the Trust Center.
  • Continuous control monitoring through Drata, with live status published on the Trust Center.

Supported versions

Security fixes ship to the latest release and to all active LTS versions. We release a new LTS every six months and support each for one year, with at most two active at any time. For production, pin an exact version number on an LTS line. The latest-lts tag points to the current LTS if you need to check which one that is.

Fixes for known CVEs are backported to all active LTS versions. If you are running an unsupported version, upgrade to latest or the current LTS to receive security fixes.

Infrastructure hardening

For self-hosted deployments, Kestra publishes guidance for hardening the underlying infrastructure: network isolation for link-local metadata services, container sandboxes and ephemeral task runners, minimum host permissions, plugin restriction, upload protections and CI/CD flow validation. See the security hardening guide.

Reporting a vulnerability

If you discover a security vulnerability in Kestra, report it privately to
security@kestra.io so we can follow a responsible disclosure process.

When you report

  • Describe the issue in detail, including steps to reproduce it where possible.
  • Flag it if you believe the severity is critical, so we can prioritize.
  • Hold public disclosure until we have confirmed and patched the issue.

What we do

  • Acknowledge your report within two business days.
  • Verify and address the issue, then notify you when it is fixed.
  • Credit you in the release notes unless you prefer to stay anonymous.

Published advisories are available at github.com/kestra-io/kestra/security/advisories.

Resources

Trust Center
kestra.io/trust
Security and secrets configuration
kestra.io/docs/configuration/security-and-secrets
Kestra Cloud Terms of Service
kestra.io/kestra-cloud-terms-of-service
Report a vulnerability
security@kestra.io
Security overview (2-page PDF)
Download
Kestra Cloud Privacy Policy
kestra.io/kestra-cloud-privacy-policy

Frequently Asked Questions

Find answers to your questions right here, and don't hesitate to contact us if you couldn't find what you're looking for.