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:

bash
Copied
1
$ airplane dev
2
Discovering tasks and views...registered 2 tasks and 1 view.
3

4
Started studio session at https://app.airplane.dev/studio?host=http://localhost:4000 (^C to quit)
5
Press 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:

bash
Copied
1
$ 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.