Local development with Studio
Develop tasks, views, and workflows locally in your browser.

The Airplane Studio provides a rich local development experience that allows you to quickly iterate
on Tasks and Views, even before they've been deployed. The
studio is functionally divided into two parts:
- Left sidebar that lists out local tasks and views, in addition to any additional configuration required by them, such as resources and configs.
- Main pane that allows the user to perform operations like executing tasks, modifying local resources, etc.
Local execution of Docker tasks is not currently supported.
Starting the studio
If you haven't installed the Airplane CLI, do that before continuing. The
studio works by making requests to a local dev server, a trimmed-down version of the Airplane
API server used to facilitate local development. To start up the local dev server, run
airplane dev
:bashCopied1$ airplane dev2Discovering tasks and views...registered 2 tasks and 1 view.34Started studio session at https://app.airplane.dev/studio?host=http://localhost:4000 (^C to quit)5Press ENTER to open the studio in the browser.
This command does a few things:
- Discovers local task and view definitions to load into the local dev server, which subsequently
get displayed in the studio.
airplane dev
takes in a single, optional, positional argument that indicates which directory to discover tasks and views from, e.g.airplane dev ~/my_apps
—this is known as the development root. Any task or view that has been discovered is said to be registered with the studio. By default, if no argument is passed, the CLI will attempt to discover definitions in the current directory and all nested subdirectories. It's also possible to pass in a filename as an argument, e.g.airplane dev my_task.task.yaml
—in this case, the studio will be used for the local development of a singular task or view. - Starts up an HTTP server that will respond to requests from the studio to execute tasks, load views, etc.
- Outputs a URL from which you can access the studio. Note that although the studio UI is part of our production web app, any tasks and views are actually running locally on your machine!
Executing tasks
You can execute task locally from the studio—to do so, select the task from the left sidebar, fill
in any relevant parameters, and click
Execute
:
You'll then be redirected to a page for the run, which shows real-time logs for the execution in a
UI similar to what you might see in your production environment:

If your task requires config variables or resource configuration, you can include them in a
dev config file. By default, the CLI will look for a file called
airplane.dev.yaml
in the development root, and traverse upwards through any parent directories
until it finds one. You can override this with --config-path
if your dev config file is stored
elsewhere:bashCopied1$ airplane dev --config-path my-airplane-config.dev.yaml
Child runs
If you are developing a task that executes another task, the task being
called should be registered locally with the studio. To execute a remote task when no local task is
present, see the docs on setting a fallback environment.
Loading views
To load a view into the studio, simply select a view from the left sidebar (it may take a few
seconds to initially load the view):

Because the local dev server is handling the loading of the view, any edits you make to your view
will show up instantly in the studio—try it out!
Tasks in views
If you reference a task in your view, that task must be registered
locally unless a fallback environment has been specified,
similar to child runs.
Setting local configuration
Through the CLI, you can configure local resources and config variables. For more information, check
out the docs on the Dev config file.

Distinguishing studio runs
When you execute a task from Studio, the run's environment variables will be populated with
AIRPLANE_ENV_ID
and AIRPLANE_ENV_SLUG
, both of which will be set to studio
. This can be useful
for distinguishing between runs that were executed from Studio and those that were executed from
Airplane. For more information, see the runtime environment variables
docs.