Fallback environment

Reference remote tasks and resources from the local studio.
By default, any task referenced by a view or another task must be registered when the studio starts up. Additionally, any resource or config variable 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 task 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, resources, and configs 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:
bash
Copied
1
$ airplane dev --env production
2
Discovering tasks and and views...registered 2 tasks and 1 view.
3


4
Your fallback environment is set to Production.
5
- Any task not registered locally will execute in Production.
6
- Any resource or config not declared in your dev config will be loaded from Production.
7


8
Started studio session at https://app.airplane.dev/studio?host=http://localhost:4000&__env=prod (^C to quit)
9
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 default to the --env flag. For example, if your default environment is production, the following commands would be equivalent:
bash
Copied
1
airplane dev --env production

Remote tasks
Tasks can be referenced from both Views and other tasks. 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 the fallback environment.
Any tasks executed remotely will have an indicator next to them:
Note that local tasks can execute remote tasks, but not the other way around. Once a task 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.
  • Tasks A and C are registered locally.
  • Tasks B and 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 shown 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:

Remote config variables
If executing a task that uses config variables, the studio will look for those configs variables 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 config variable in the dev config file.
Remote config variables will be shown alongside local config variables in the config variables tab of the studio:
PrivacyTermsSupport