Local development with Studio
Develop tasks, views, and workflows locally in your browser of choice.
The Airplane Studio provides a rich local development experience that allows you to quickly iterate on Tasks, Views, and Workflows, even before they've been deployed. The studio is functionally divided into two parts:
- Left sidebar that serves as an Airplane explorer—it lists out local tasks, views, workflows, and resources that have been discovered.
- Main pane that allows the user to perform operations like executing tasks, modifying local resources, etc.
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
bashCopied1$ airplane dev2Discovering tasks, workflows, and views...registered 2 tasks, 1 workflow, and 1 views.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, view, and workflow definitions to load into the local dev server, which
subsequently get displayed in the studio.
airplane devtakes in a single, optional, positional argument that indicates which directory to discover tasks, views, and workflows from, e.g. something like
airplane dev ~/my_apps. Any task, view, or workflow 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, view, or workflow.
- 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 and workflows
You can execute task and workflows locally from the studio—to do so, select the task or workflow from the left sidebar, fill in any relevant parameters, and click
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.yamlin the current directory, and traverse upwards through any parent directories until it finds one. You can override this with
--config-pathif your dev config file is stored elsewhere.
bashCopied1$ airplane dev --config-path my-airplane-config.dev.yaml
If you are developing a workflow 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.
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.