Fallback environment

Reference remote tasks and resources from the local studio
By default, any task referenced from a View or Workflow must be registered when the studio starts up. Additionally, any resource utilized by a task or built-in must also exist locally in the dev config file.
However, there are scenarios where you may not want to use local tasks or resources. For example, you may want to:
  • Execute a task or built-in against a real database.
  • More quickly test changes by not needing to boot local versions of your resources.
  • Locally test a workflow or view without having to configure the tasks they rely on.
In these cases, you can use a fallback environment to indicate that you'd like to execute a task or reference a resource in a remote environment.
Local tasks and resources will always take precedence over remote ones, even if a fallback environment has been set.

Specifying a fallback environment

To use a fallback environment, specify an --env flag to the airplane dev command:
$ airplane dev --env production
Discovering tasks, workflows, and views...registered 2 tasks, 1 workflow, and 1 views.
Your fallback environment is set to Production.
- Any task not registered locally will execute in Production.
- Any resource not declared in your dev config will be loaded from Production.
Started studio session at https://app.airplane.dev/studio?host=http://localhost:4000&__env=prod (^C to quit)
Press ENTER to open the studio in the browser.

Default environment

You may also set your fallback environment to your default remote environment by passing an empty string to the --env flag. For example, if your default environment is production, the following commands would be equivalent:
airplane dev --env production

Remote tasks

Tasks can be referenced from both Views and Workflows. If a fallback environment has been specified and a task has not been registered with the studio locally, then that task will be executed remotely in that remote environment.
Any tasks executed remotely will have an indicator next to them:
Note that local workflows can execute tasks and workflows remotely, but not the other way around. Once a workflow has been executed remotely, any other tasks it executes will also be executed remotely even if those tasks have been registered locally.
For example, consider the following scenario:
  • A fallback environment production has been declared.
  • Workflow A and task C are registered locally.
  • Workflow B and task C are deployed remotely in production.
  • A executes B, and B executes C.
When A runs, the studio will detect that B is not registered locally, and attempt to execute B remotely. When B runs, C will also execute remotely, even though it was registered locally with the studio, since remote executions are not aware of any local tasks.

Remote resources

If executing a built-in or a task that uses a resource (e.g. a SQL or REST task), by default the studio will look for those resource credentials in the dev config file. If a fallback environment is specified, the studio will look in that remote environment if it doesn't find the given resource in the dev config file.
Remote resources will be show alongside local resources in the resource tab of the studio:
Any built-ins that have been executed remotely will have an indicator, similar to remote tasks: