Skip to main content
Flyte is an open-source project maintained by a community of engineers and researchers. Contributions of all kinds are welcome: bug fixes, new features, documentation, plugins, and tooling improvements.

​
Before you start

1

Read the docs and run examples

Before diving into code, run at least 5 examples from the Flyte User Guide and Flytesnacks. Pay close attention to the generated graph view, task logs, and execution outputs.
2

Understand the architecture

Read through the Core Concepts, Control Plane, and Component Architecture sections.
3

Pick a good first issue

Browse good first issues on GitHub. Plugin and flytekit issues (labeled both plugins and flytekit) are client-side and are the fastest to contribute to.

​
Component reference

With the exception of flytekit, all components are maintained in the flyteorg/flyte monorepo.
Purpose: Flyte’s workflow specification. All communication between Flyte components uses these Protobuf messages as the contract.Language: Protocol BuffersMonorepo path: flyteidl/After modifying .proto files, run:
# From the monorepo root
make generate
Generated Go code lives in flyteidl/gen/pb-go/. Python generated code is published as the flyteidl PyPI package.
Purpose: gRPC + REST control plane. Stores workflow definitions, manages executions, and exposes the AdminService API.Language: GoMonorepo path: flyteadmin/Development commands:
cd flyteadmin
make compile          # Build the binary
make server           # Run locally
make seed_projects    # Seed test data
make migrate          # Run database migrations
make integration      # Run integration tests
make k8s_integration  # Run integration tests in dockernetes
Purpose: The workflow execution engine. A Kubernetes operator (controller) that reconciles FlyteWorkflow CRD objects and drives node execution.Language: GoMonorepo path: flytepropeller/Development commands:
cd flytepropeller
make generate    # Regenerate mocks and generated code
make test_unit   # Run unit tests
make lint        # Run linters
make compile     # Build the binary
Purpose: The primary Python SDK for writing tasks and workflows.Language: PythonRepository: flyteorg/flytekit (separate repo)Setup:
git clone https://github.com/flyteorg/flytekit.git
cd flytekit
virtualenv ~/.virtualenvs/flytekit
source ~/.virtualenvs/flytekit/bin/activate
make setup
pip install -e .
Refer to the Flytekit Contribution Guide for full instructions.
Purpose: The Flyte web console for monitoring workflows, executions, and artifacts.Language: TypeScriptMonorepo path: flyteconsole/Setup:
git clone https://github.com/flyteorg/flyteconsole.git
cd flyteconsole
# Install Node.js 18 and yarn, then:
export BASE_URL=/console
export ADMIN_API_URL=http://localhost:30080
export DISABLE_AUTH=1
yarn install
yarn build:types
yarn run build:prod
yarn start
Refer to the README for full setup.
Purpose: Manages input/output artifacts and task output memoization.Language: GoMonorepo path: datacatalog/
Purpose: Backend plugins for external services (Spark, Ray, PyTorch, etc.).Language: GoMonorepo path: flyteplugins/
cd flyteplugins
make generate
make test_unit
make lint
Purpose: The standalone Flyte CLI for managing resources and running sandboxes.Language: GoMonorepo path: flytectl/Refer to the FlyteCTL Contribution Guide.

​
Setting up the development environment

​
Requirements

This guide has been tested on AWS EC2 with Ubuntu 22.04, but works on any Linux system and macOS.

​
Step 1: Install flytectl

curl -sL https://ctl.flyte.org/install | bash
export PATH=$PATH:/home/ubuntu/bin  # adjust to your install path

​
Step 2: Start a k3s cluster with Minio and Postgres

# Starts a k3s cluster with Minio (object store) and Postgres (metadata store)
# Does NOT start the Flyte services yet
flytectl demo start --dev

# Export the sandbox config
export FLYTECTL_CONFIG=/home/ubuntu/.flyte/config-sandbox.yaml

# Verify Minio and Postgres are running
kubectl get pod -n flyte

​
Step 3: Build and run Flyte as a single binary

The monorepo builds all Flyte components (flyteadmin, flytepropeller, datacatalog, flyteconsole) into a single binary: 
git clone https://github.com/flyteorg/flyte.git
cd flyte

# Build dependencies
sudo apt-get -y install jq
make go-tidy
make compile

# Create namespace templates for the cluster resource controller
mkdir -p $HOME/.flyte/sandbox/cluster-resource-templates/
cat > $HOME/.flyte/sandbox/cluster-resource-templates/namespace.yaml <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: '{{ namespace }}'
EOF

# Start the single binary (all Flyte components)
POD_NAMESPACE=flyte flyte start --config flyte-single-binary-local.yaml

​
Step 4: Build with custom component code

To develop against a modified component (e.g. flyteadmin): 
# Modify code in flyte/flyteadmin/
cd flyte/flyteadmin
# ... make your changes ...

# Rebuild the single binary from the monorepo root
cd ..
make go-tidy
make compile

# Restart
POD_NAMESPACE=flyte flyte start --config flyte-single-binary-local.yaml
You can substitute flyteadmin for any other component: flyteidl, flyteplugins, flytepropeller, datacatalog, or flytestdlib.

​
Step 5: Run a hello world workflow

# Install flytekit
pip install flytekit
export PATH=$PATH:$HOME/.local/bin

# Run the hello world example against your local cluster
pyflyte run --remote \
  https://raw.githubusercontent.com/flyteorg/flytesnacks/master/examples/basics/basics/hello_world.py \
  hello_world_wf

​
Tear down

flytectl demo teardown
unset FLYTECTL_CONFIG

​
Accessing local services

ServiceURLCredentials
Flyte UIhttp://localhost:30080/consoleNone (auth disabled)
Minio consolehttp://localhost:30080/minio/loginminio / miniostorage
Postgreslocalhost:30001postgres / postgres
k3s dashboardhttp://localhost:30080/kubernetes-dashboardNone
Docker registrylocalhost:30000None

​
Submitting a pull request

1

Fork and branch

Fork the flyteorg/flyte repository and create a feature branch.
git checkout -b feat/my-feature
2

Make your changes

Follow the code style for the component you are modifying. For Go components, run linters and tests:
make lint
make test_unit
For flytekit (Python):
make lint
make test
3

Sign your commits

Flyte requires all commits to be signed (Developer Certificate of Origin). Use -s when committing:
git commit -s -m "feat: describe your change"
4

Open a pull request

Push your branch and open a PR against the master branch. Fill in the PR template with:
  • What changed and why
  • Link to the related issue (every PR should have an associated issue)
  • Test plan
5

Respond to review feedback

A maintainer will review your PR. Address any feedback, push new commits, and request re-review when ready.

​
Change management principles

  • Every PR must be associated with a GitHub issue.
  • Large changes should be preceded by a design proposal (RFC).
  • Every major change should include documentation updates.
  • Owner files (OWNERS) exist in all repositories and define who reviews what.

​
Code of conduct

Flyte follows the CNCF Code of Conduct. Be respectful and constructive in all community interactions.

Build docs developers (and LLMs) love

Get started for freeTalk to us