Create a Python subflow, acting like an abstracted component

Turn a Python script into a reusable, parameterized building block. This blueprint packages a Python script as a Kestra subflow that accepts typed inputs, executes inside an isolated Docker container, and returns a structured output. Parent flows call it like a function: pass arguments in, get results back, without duplicating logic or worrying about the implementation details. This is the foundation for modular, DRY orchestration where complex logic stays encapsulated behind a simple interface.

How it works

• The flow declares two typed inputs, arg1 and arg2, both INT with defaults of 1 and 2.
• A single python task of type io.kestra.plugin.scripts.python.Commands runs the script.
• The task uses the io.kestra.plugin.scripts.runner.docker.Docker task runner for isolated, reproducible execution, and declares the kestra pip dependency.
• An inline main.py is provided via inputFiles. It parses --arg1 and --arg2 with argparse, multiplies them, prints the result, and emits it with Kestra.outputs({'result': result}).
• The commands block invokes python main.py --arg1 {{ inputs.arg1 }} --arg2 {{ inputs.arg2 }}, wiring the flow inputs into the script.
• A parent flow calls this subflow with io.kestra.plugin.core.flow.Subflow, sets wait: true, passes inputs, and maps result from {{ outputs.python.vars.result }}.

What you get

• A callable, version-controlled component with a documented inputs and outputs contract.
• Container-isolated Python execution with pinned dependencies.
• Structured outputs that downstream tasks can consume directly.
• Less duplication: write the logic once, reuse it across many flows.

Who it's for

• Data engineers who want modular pipelines instead of copy-pasted scripts.
• Platform teams building shared, reusable flow libraries for their organization.
• Python developers exposing logic to non-Python users behind a simple interface.

Why orchestrate this with Kestra

Plain scripts have no contract, no isolation, and no reuse story. Kestra wraps your Python in declarative YAML with typed inputs, container execution, and explicit outputs. Subflows give you composition the way functions do in code, while event triggers, automatic retries, and built-in execution lineage handle the operational concerns a standalone script or a bare cron job cannot: you get observability, replay, and parent-child traceability across every call.

Prerequisites

• A running Kestra instance.
• Docker available to the worker for the Docker task runner.

Secrets

• None. This flow references no {{ secret('NAME') }} values.

Quick start

1. Add this flow to your Kestra instance and run it from the UI, overriding arg1 and arg2 if you like.
2. Confirm the printed product and the result output in the execution view.
3. Create a parent flow with an io.kestra.plugin.core.flow.Subflow task pointing at this flowId.
4. Pass inputs and read {{ outputs.<taskId>.vars.result }} downstream.

How to extend

• Replace main.py with your own logic and add inputs to match.
• Add output keys via Kestra.outputs({...}) for richer return values.
• Pin a specific image or extra dependencies for heavier workloads.
• Chain several subflow components together to compose larger pipelines.

Links

• https://kestra.io/plugins/plugin-script-python