Execute rules & constraints
Configure the execution behavior for a task or runbook.
Execute rules allow you to control task or runbook execution. For example, you can require
executions to go through requests or re-authentication, or constrain runs to specific agents.
Requests
By default, tasks and runbooks do not require requests and allow self-approvals. You can turn on
these options in the Advanced section of the task or runbook editor:

Requiring requests will disable schedules. Any existing schedules will be paused on the next
attempted execution.
Session and task behavior
If a task is run in a session, then it also considers the request on the session (if it exists) when
determining if the execute rules have been satisfied. In other words, if a session contains a task
that requires requests, and that session was requested, this satisfies the request requirement for
the task, and the task is executed as normal. Similarly, if the task disallows self-approvals and
the session request was not self-approved, the task is executed automatically.
However, if the request on the session does not satisfy the task's execute rules, or the session was
executed directly, then a request for that task will be automatically opened instead.
Re-authentication
Configuring a runbook or task to require re-authentication will prompt the user executing a runbook
or task or approving a request to authenticate again by signing in through Google or SSO. You can
turn on this option in the Advanced section of the task or runbook editor, under Execute Rules.

Require re-authentication is only enabled upon request. Please email us at
support@airplane.dev if you'd like access.
Requiring re-authentication will disable requests and task and runbook execution outside of the
Airplane UI. It will also disable schedules. Any existing schedules will be paused on the next
attempted execution.
Run constraints
If you're self-hosting Airplane agents, you may want to control which agents
a run can be scheduled on. For example, you might have agents with different network configurations,
and a certain task must execute in a specific network.
With label constraints, runs will be scheduled only on agents with matching labels. Label
constraints can be specified on both tasks and runbooks.
When executing built-ins from tasks (or
runbooks), the built-in run will inherit the constraints of
the task run (or session) that called it. In the case of overlapping labels, the child run's
constraints will take precedence over its inherited constraints.

If a runbook includes a task with conflicting constraints, the task block will fail to start.
Setting labels on self-hosted agents
Agent labels can be set with the
AP_LABELS
environment variable. Labels are key:value
string
pairs separated by spaces.Example:
AP_LABELS="aws-region:us-west-2 environment:prod"
To require that only runs with a specific constraint value run on a particular agent, prefix the
label with
required:
, e.g.: required:aws-region:us-west2
. Otherwise, unconstrained runs could
also be scheduled on the agent.For details on configuring agent labels for your specific environment, see
Agents.