Studio

Develop tasks and views in your browser.

Airplane Studio provides a rich development experience that allows you to quickly iterate on Tasks and Views in your currently selected environment. Studio is functionally divided into three parts:

Left sidebar that lists tasks and views and allows the user to view and edit resources and configs.
Code editor that allows the user to quickly edit task and view definitions, as well as any other files in the project.
Main panel that allows the user to perform operations like executing tasks, previewing views, making configuration changes, etc.

Workspaces

When creating a task or view within Studio, you can choose where it is managed.

Cloud workspaces allow you to build tasks directly within your Library, without setting up a local development environment.
Local workspaces allow you to manage the code for your tasks and views on your machine. Local workspaces require installing the Airplane CLI and running airplane dev to start the local dev server.

The Library explorer tab of the left sidebar will show all tasks and views in both cloud and local workspaces (if the dev server is running). Tasks in the local workspace will be demarcated by in the Library. If a task in the local workspace is discovered with the same slug as a task that already exists in the app, edits to the task will be applied locally.

	Cloud workspace	Local workspace
Create and edit non-code tasks (SQL, REST, GraphQL, Docker)	✔	✔
Create and edit code tasks (JavaScript, Python, Shell)	Coming soon	✔
Execute tasks	Coming soon	✔
Create, edit, and load views	Coming soon	✔
Create and edit remote configs and resources	✔	✔
Create and edit local configs and resources	N/A	✔

Cloud workspaces are great for getting started quickly and for making edits without running the local dev server. If you're using Airplane on a team, we recommend using local workspaces in order to integrate Airplane into your existing development flow (e.g. using version control, IDEs, etc.).

Starting the dev server

In order to develop in a local workspace, you must have the Airplane CLI installed. Local workspaces in Studio work 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
Watching for changes in: /home/bob/my-airplane-tasks
5
Changes to tasks and views will be applied automatically.
6

7
Started studio session at https://app.airplane.dev/studio (^C to quit)
8
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 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 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, 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 Studio to execute tasks, load views, etc.
Outputs a URL from which you can access 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!

Creating new tasks or views

Creating new tasks or views is easy in Studio. Click the New button in the upper right corner to create a new task or view, or to initialize a view from an existing template.

Editing existing tasks and views

The Configure panel is used to edit task and view configuration, such as parameters and resource attachments.

Edits to tasks managed in a cloud workspace will be in "draft" mode until the changes are saved. For tasks managed in a local workspace, changes are immediately reflected in code and will be visible in the app once deployed.

When developing locally, Airplane Studio also includes a full-featured code editor for tasks, views, or any other files in your project. Changes are immediately saved to disk and reflected in Studio in real time.

The code editor can be used to edit more complex task or view configurations that aren't supported by the Configure panel—for example, configurations that utilize conditional logic or variable references.

To quickly open a file in your local editor, click the Open in editor button in the bottom right corner of the Studio code editor.

Executing tasks

Task execution is not currently supported in cloud workspaces.

Execution of Docker tasks is not currently supported.

You can execute tasks locally from 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 set up local configurations.

Child runs

If you are developing a task that executes another task, the task being called should be registered locally with Studio. To execute a remote task when no local task is present, see the docs on enabling fallback.

Loading views

Views are not currently supported in cloud workspaces.

To load a view into 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 Studio—try it out!

Tasks in views

If you reference a task in your view, that task must be registered locally unless fallback is enabled, similar to child runs.

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.