Run the same task code locally in your Python process, or remotely on a devbox or a deployed cluster.
Run modes
A run is either local or remote. The same task code runs unchanged either way, so you can choose the right trade-off between speed and fidelity at each stage of development.
Local and remote
- Local runs the task in-process, directly in your Python interpreter. There is no cluster and no container. Select it with
flyte run --localorflyte.with_runcontext(mode="local"). - Remote runs the task on a Flyte backend, inside a container that a cluster schedules. It is the default for
flyte run, and you can select it explicitly withmode="remote". Your configuration decides which backend.
A remote backend is either a devbox on your own machine or a deployed cluster in the cloud or on-premises. “Remote” describes how the run executes, not where the machine is: a devbox run is remote even though the devbox runs on your laptop. This is how the CLI and SDK use the word throughout.
| Mode | How the task runs | Backend |
|---|---|---|
Local (--local) |
In-process | None |
| Remote | In a container, on a cluster | A devbox on your machine |
| Remote | In a container, on a cluster | A deployed cluster, in the cloud or on-premises |
| Aspect | Local (--local) |
Remote: devbox | Remote: deployed cluster |
|---|---|---|---|
| ⚡️ Execution | In-process Python | On-cluster, local Docker | On-cluster, your Flyte cluster |
| 🐳 Docker required | No | Yes | Yes (local image build) |
| 💻 Flyte UI | No (TUI only) | Yes (localhost:30080) |
Yes |
| 📦 Container images | Ignored | Built locally | Built locally, pushed to a registry |
| 🔀 Parallelism | Sequential | Cluster-level | Cluster-level |
| ⭐️ Best for | Fast iteration, debugging | Testing container builds, full Flyte features | Production, GPUs, scale |
The same task code runs unchanged on all three. Start with local execution for fast feedback, move to the Devbox to validate on-cluster execution, then deploy to your Flyte cluster for production.