How to define deployments with YAML

The prefect.yaml file is a YAML file describing base settings for your deployments, procedural steps for preparing deployments, and instructions for preparing the execution environment for a deployment run. Initialize your deployment configuration, which creates the prefect.yaml file, with the CLI command prefect init in any directory or repository that stores your flow code.

Deployment configuration recipesPrefect ships with many off-the-shelf “recipes” that allow you to get started with more structure within your prefect.yaml file. Run prefect init to be prompted with available recipes in your installation. You can provide a recipe name in your initialization command with the --recipe flag, otherwise Prefect will attempt to guess an appropriate recipe based on the structure of your working directory (for example if you initialize within a git repository, Prefect will use the git recipe).

The prefect.yaml file contains:

deployment configuration for deployments created from this file
default instructions for how to build and push any necessary code artifacts (such as Docker images)
default instructions for pulling a deployment in remote execution environments (for example, cloning a GitHub repository).

You can override any deployment configuration through options available on the prefect deploy CLI command when creating a deployment.

prefect.yaml file flexibilityIn older versions of Prefect, this file must be in the root of your repository or project directory and named prefect.yaml. With Prefect 3, this file can be located in a directory outside the project or a subdirectory inside the project. It can be named differently if the filename ends in .yaml. You can have multiple prefect.yaml files with the same name in different directories.By default, prefect deploy uses a prefect.yaml file in the project’s root directory. To use a custom deployment configuration file, supply the new --prefect-file CLI argument when running the deploy command from the root of your project directory:prefect deploy --prefect-file path/to/my_file.yaml

The base structure for prefect.yaml looks like this:

# generic metadata
prefect-version: null
name: null

# preparation steps
build: null
push: null

# runtime steps
pull: null

# deployment configurations
deployments:
- # base metadata
  name: null
  version: null
  tags: []
  description: null

  # flow-specific fields
  entrypoint: null
  parameters: {}

  # infra-specific fields
  work_pool:
    name: null
    work_queue_name: null
    job_variables: {}

The metadata fields are always pre-populated for you. These fields are for bookkeeping purposes only. The other sections are pre-populated based on recipe; if no recipe is provided, Prefect attempts to guess an appropriate one based on local configuration. You can create deployments with the CLI command prefect deploy without altering the deployments section of your prefect.yaml file. The prefect deploy command helps in deployment creation through interactive prompts. The prefect.yaml file facilitates version-controlling your deployment configuration and managing multiple deployments.

Deployment actions

Deployment actions defined in your prefect.yaml file control the lifecycle of the creation and execution of your deployments. The three actions available are build, push, and pull. pull is the only required deployment action. It defines how Prefect pulls your deployment in remote execution environments. Each action is defined as a list of steps executed in sequence. Each step has the following format:

section:
- prefect_package.path.to.importable.step:
  id: "step-id" # optional
  requires: "pip-installable-package-spec" # optional
  kwarg1: value
  kwarg2: more-values

Every step optionally provides a requires field. Prefect uses this to auto-install if the step is not found in the current environment. Each step can specify an id to reference outputs in future steps. The additional fields map directly to Python keyword arguments to the step function. Within a given section, steps always run in their order within the prefect.yaml file.

Deployment instruction overridesYou can override build, push, and pull sections on a per-deployment basis; define build, push, and pull fields within a deployment definition in the prefect.yaml file.The prefect deploy command uses any build, push, or pull instructions from the deployment’s definition in the prefect.yaml file.This capability is useful for multiple deployments that require different deployment instructions.

The build action

Use the build section of prefect.yaml to specify setup steps or dependencies, (like creating a Docker image), required to run your deployments. If you initialize with the Docker recipe, you are prompted to provide required information, such as image name and tag:

prefect init --recipe docker
>> image_name: < insert image name here >
>> tag: < insert image tag here >

Use --field to avoid the interactive experienceWe recommend that you only initialize a recipe when first creating your deployment structure. Then store your configuration files within version control. Sometimes you may need to initialize programmatically and avoid the interactive prompts. To do this, provide all required fields for your recipe using the --field flag:

prefect init --recipe docker \
    --field image_name=my-repo/my-image \
    --field tag=my-tag

build:
- prefect_docker.deployments.steps.build_docker_image:
  requires: prefect-docker>=0.3.0
  image_name: my-repo/my-image
  tag: my-tag
  dockerfile: auto

Once you confirm that these fields are set to their desired values, this step automatically builds a Docker image with the provided name and tag. To publish the image to a registry, use a separate prefect_docker.deployments.steps.push_docker_image step. This step produces optional fields for future steps, or within prefect.yaml as template values. We recommend using a templated {{ image }} within prefect.yaml (specifically in the work pool’s job_variables section). By avoiding hardcoded values, the build step and deployment specification won’t have mismatched values.

Some steps require Prefect integrationsIn the build step example above, you relied on the prefect-docker package; in cases that deal with external services, additional required packages are auto-installed for you.

Passing Docker build argumentsThe build_docker_image step accepts any keyword arguments supported by the Docker Python SDK’s build method. This allows you to customize the Docker build process beyond the explicitly documented parameters.Common examples:

build:
  - prefect_docker.deployments.steps.build_docker_image:
      image_name: my-repo/my-image
      tag: my-tag
      dockerfile: auto
      nocache: true           # Disable Docker layer caching (--no-cache)
      pull: true              # Always pull the latest base image
      platform: linux/amd64   # Specify target platform
      buildargs:              # Pass build-time variables
        MY_ARG: value

Note: ignore_cache is a separate parameter that controls Prefect’s step-level caching (whether to reuse the entire build step result across prefect deploy --all runs), not Docker’s layer caching.

Pass output to downstream steps Each deployment action can be composed of multiple steps. For example, to build a Docker image tagged with the current commit hash, use the run_shell_script step and feed the output into the build_docker_image step:

build:
- prefect.deployments.steps.run_shell_script:
    id: get-commit-hash
    script: git rev-parse --short HEAD
    stream_output: false
- prefect_docker.deployments.steps.build_docker_image:
    requires: prefect-docker
    image_name: my-image
    tag: "{{ get-commit-hash.stdout }}"
    dockerfile: auto

The id field is used in the run_shell_script step to reference its output in the next step.

The push action

The push section is most critical for situations where code is not stored on persistent filesystems or in version control. In this scenario, code is often pushed and pulled from a Cloud storage bucket (for example, S3, GCS, Azure Blobs). The push section allows users to specify and customize the logic for pushing this code repository to arbitrary remote locations. For example, a user who stores their code in an S3 bucket and relies on default worker settings for its runtime environment could use the s3 recipe:

prefect init --recipe s3
>> bucket: < insert bucket name here >

In your newly createdprefect.yaml file, you should find that the push and pull sections have been templated out as follows:

push:
- prefect_aws.deployments.steps.push_to_s3:
    id: push-code
    requires: prefect-aws>=0.3.0
    bucket: my-bucket
    folder: project-name
    credentials: null

pull:
- prefect_aws.deployments.steps.pull_from_s3:
    requires: prefect-aws>=0.3.0
    bucket: my-bucket
    folder: "{{ push-code.folder }}"
    credentials: null

The bucket is populated with the provided value (which also could have been provided with the --field flag); note that the folder property of the pull step is a template - the push_to_s3 step outputs both a bucket value as well as a folder value for the template downstream steps. This helps you keep your steps consistent across edits. As discussed above, if you use blocks, you can template the credentials section with a block reference for secure and dynamic credentials access:

push:
- prefect_aws.deployments.steps.push_to_s3:
    requires: prefect-aws>=0.3.0
    bucket: my-bucket
    folder: project-name
    credentials: "{{ prefect.blocks.aws-credentials.dev-credentials }}"

Anytime you run prefect deploy, this push section executes upon successful completion of your build section.

The pull action

The pull section is the most important section within the prefect.yaml file. It contains instructions for preparing your flows for a deployment run. These instructions execute each time a deployment in this folder is run through a worker. There are three main types of steps that typically show up in a pull section:

set_working_directory: this step sets the working directory for the process prior to importing your flow
git_clone: this step clones the provided repository on the provided branch
pull_from_{cloud}: this step pulls the working directory from a Cloud storage location (for example, S3)

Omitted pull versus empty pullAn omitted or null pull section causes prefect deploy to auto-generate a default pull action (a set_working_directory step pointing at the deploying machine’s current working directory). If your worker prepares the flow’s code itself (for example, a custom job command that clones code at runtime), set pull: [] to explicitly disable pull steps so no set_working_directory step is generated.

Use block and variable referencesAll block and variable references within your pull step will remain unresolved until runtime and are pulled each time your deployment runs. This avoids storing sensitive information insecurely; it also allows you to manage certain types of configuration from the API and UI without having to rebuild your deployment every time.

Below is an example of how to use an existing GitHubCredentials block to clone a private GitHub repository:

pull:
- prefect.deployments.steps.git_clone:
    repository: https://github.com/org/repo.git
    credentials: "{{ prefect.blocks.github-credentials.my-credentials }}"

Alternatively, you can specify a BitBucketCredentials or GitLabCredentials block to clone from Bitbucket or GitLab. In lieu of a credentials block, you can also provide a GitHub, GitLab, or Bitbucket token directly to the ‘access_token` field. Use a Secret block to do this securely:

pull:
- prefect.deployments.steps.git_clone:
    repository: https://bitbucket.org/org/repo.git
    access_token: "{{ prefect.blocks.secret.bitbucket-token }}"

Utility steps

Use utility steps within a build, push, or pull action to assist in managing the deployment lifecycle:

run_shell_script allows for the execution of one or more shell commands in a subprocess, and returns the standard output and standard error of the script. This step is useful for scripts that require execution in a specific environment, or those which have specific input and output requirements. Note that setting stream_output: true for run_shell_script writes the output and error to stdout in the execution environment, which will not be sent to the Prefect API.

Here is an example of retrieving the short Git commit hash of the current repository to use as a Docker image tag:

build:
- prefect.deployments.steps.run_shell_script:
    id: get-commit-hash
    script: git rev-parse --short HEAD
    stream_output: false
- prefect_docker.deployments.steps.build_docker_image:
    requires: prefect-docker>=0.3.0
    image_name: my-image
    tag: "{{ get-commit-hash.stdout }}"
    dockerfile: auto

Provided environment variables are not expanded by defaultTo expand environment variables in your shell script, set expand_env_vars: true in your run_shell_script step. For example:

- prefect.deployments.steps.run_shell_script:
    id: get-user
    script: echo $USER
    stream_output: true
    expand_env_vars: true

Without expand_env_vars: true, the above step returns a literal string $USER instead of the current user.

Shell operators require shell: trueBy default, run_shell_script does not interpret shell operators like pipes (|), redirects (>), or logical operators (&&, ||). To use these operators, set shell: true:

push:
- prefect.deployments.steps.run_shell_script:
    script: aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456.dkr.ecr.us-east-1.amazonaws.com
    shell: true

Only set shell: true when you need shell features, as it has security implications similar to subprocess.run(shell=True).

pip_install_requirements installs dependencies from a requirements.txt file within a specified directory.

Here is an example of installing dependencies from a requirements.txt file after cloning:

pull:
- prefect.deployments.steps.git_clone:
    id: clone-step # needed to be referenced in subsequent steps
    repository: https://github.com/org/repo.git
- prefect.deployments.steps.pip_install_requirements:
    directory: "{{ clone-step.directory }}" # `clone-step` is a user-provided `id` field
    requirements_file: requirements.txt

Here is an example that retrieves an access token from a third party key vault and uses it in a private clone step:

pull:
- prefect.deployments.steps.run_shell_script:
    id: get-access-token
    script: az keyvault secret show --name <secret name> --vault-name <secret vault> --query "value" --output tsv
    stream_output: false
- prefect.deployments.steps.git_clone:
    repository: https://bitbucket.org/samples/deployments.git
    branch: master
    access_token: "{{ get-access-token.stdout }}"

You can also run custom steps by packaging them. In the example below, retrieve_secrets is a custom python module packaged into the default working directory of a Docker image (which is /opt/prefect by default). main is the function entry point, which returns an access token (for example, return {"access_token": access_token}) like the preceding example, but utilizing the Azure Python SDK for retrieval.

- retrieve_secrets.main:
    id: get-access-token
- prefect.deployments.steps.git_clone:
    repository: https://bitbucket.org/samples/deployments.git
    branch: master
    access_token: '{{ get-access-token.access_token }}'

Custom deployment steps

Deployment steps in prefect.yaml are not limited to built-in Prefect utilities. Every step is simply a reference to a Python function, specified by its fully-qualified name. This means you can write your own custom step functions and use them in any build, push, or pull section.

How steps work

When Prefect encounters a step like my_module.my_function, it imports and calls that function with the provided keyword arguments. As long as the function is importable in the execution environment, it works as a deployment step. Custom step functions should accept keyword arguments and return a dictionary (which can be empty) so that their outputs are available to subsequent steps through templating.

Writing a custom step function

Here is an example of a custom step that loads environment variables from a .env file before a flow run executes:

my_steps.py

def load_dotenv(dotenv_path: str = ".env") -> dict[str, str]:
    """Custom deployment step to load environment variables from a .env file."""
    from dotenv import load_dotenv as _load_dotenv

    _load_dotenv(dotenv_path)
    return {"dotenv_path": dotenv_path}

Reference it in your prefect.yaml like any other step:

pull:
  - my_steps.load_dotenv:
      dotenv_path: .env.custom

Step function requirementsCustom step functions must:

Be importable in the execution environment (the module must be installed or available on sys.path where the worker runs).
Accept their configuration as keyword arguments.
Return a dictionary. The returned key-value pairs become available as template variables for subsequent steps (for example, "{{ step-id.key }}"). Return an empty dictionary if no output is needed.

Practical examples

Run a database migration before each deployment run:

pull:
  - prefect.deployments.steps.git_clone:
      id: clone-step
      repository: https://github.com/org/repo.git
  - prefect.deployments.steps.pip_install_requirements:
      directory: "{{ clone-step.directory }}"
  - my_project.steps.run_migrations:
      requires: alembic
      direction: upgrade
      revision: head

Set custom environment variables at runtime:

pull:
  - prefect.deployments.steps.set_working_directory:
      directory: /opt/prefect
  - my_config.steps.set_env_vars:
      env:
        APP_ENV: production
        LOG_LEVEL: info

The corresponding step function:

my_config/steps.py

import os
from typing import Any


def set_env_vars(env: dict[str, str] | None = None) -> dict[str, Any]:
    """Set environment variables for the flow run."""
    env = env or {}
    for key, value in env.items():
        os.environ[key] = value
    return {"env_vars_set": list(env.keys())}

Use the requires keyword for third-party dependenciesIf your custom step depends on a package that may not be installed in the execution environment, use the requires keyword to have Prefect auto-install it:

pull:
  - my_steps.load_dotenv:
      requires: python-dotenv
      dotenv_path: .env.custom

Templating options

Values that you place within your prefect.yaml file can reference dynamic values in several different ways:

step outputs: every step of both build and push produce named fields such as image_name; you can reference these fields within prefect.yaml and prefect deploy will populate them with each call. References must be enclosed in double brackets and in "{{ field_name }}" format
blocks: you can reference Prefect blocks with the {{ prefect.blocks.block_type.block_slug }} syntax. It is highly recommended that you use block references for any sensitive information (such as a GitHub access token or any credentials) to avoid hardcoding these values in plaintext. Block references can also be embedded inline within a larger string value, for example: "{{ prefect.blocks.secret.my-registry }}/my-image". The resolved block value is coerced to a string; non-scalar values such as dicts and lists cannot be used for inline substitution
variables: you can reference Prefect variables with the {{ prefect.variables.variable_name }} syntax. Use variables to reference non-sensitive, reusable pieces of information such as a default image name or a default work pool name.
environment variables: you can also reference environment variables with the special syntax {{ $MY_ENV_VAR }}. This is especially useful for referencing environment variables that are set at runtime.

Here’s a prefect.yaml file as an example:

build:
- prefect_docker.deployments.steps.build_docker_image:
    id: build-image
    requires: prefect-docker>=0.6.0
    image_name: my-repo/my-image
    tag: my-tag
    dockerfile: auto

push:
- prefect_docker.deployments.steps.push_docker_image:
    requires: prefect-docker>=0.6.0
    image_name: my-repo/my-image
    tag: my-tag
    credentials: "{{ prefect.blocks.docker-registry-credentials.dev-registry }}"

deployments:
- # base metadata
  name: null
  version: "{{ build-image.tag }}"
  tags:
  - "{{ $my_deployment_tag }}"
  - "{{ prefect.variables.some_common_tag }}"
  description: null
  concurrency_limit: null

  # flow-specific fields
  entrypoint: null
  parameters: {}

  # infra-specific fields
  work_pool:
    name: "my-k8s-work-pool"
    work_queue_name: null
    job_variables:
      image: "{{ build-image.image }}"
      cluster_config: "{{ prefect.blocks.kubernetes-cluster-config.my-favorite-config }}"

So long as your build steps produce fields called image_name and tag, every time you deploy a new version of our deployment, the {{ build-image.image }} variable is dynamically populated with the relevant values.

Docker stepThe most commonly used build step is prefect_docker.deployments.steps.build_docker_image which produces both the image_name and tag fields.

A prefect.yaml file can have multiple deployment configurations that control the behavior of several deployments. You can manage these deployments independently of one another, allowing you to deploy the same flow with different configurations in the same codebase.

Work with multiple deployments with prefect.yaml

Prefect supports multiple deployment declarations within the prefect.yaml file. This method of declaring multiple deployments supports version control for all deployments through a single command. Add new deployment declarations to the prefect.yaml file with a new entry to the deployments list. Each deployment declaration must have a unique name field to select deployment declarations when using the prefect deploy command.

When using a prefect.yaml file that is in another directory or differently named, the value for the deployment entrypoint must be relative to the root directory of the project.

For example, consider the following prefect.yaml file:

build: ...
push: ...
pull: ...

deployments:
  - name: deployment-1
    entrypoint: flows/hello.py:my_flow
    parameters:
        number: 42,
        message: Don't panic!
    work_pool:
        name: my-process-work-pool
        work_queue_name: primary-queue

  - name: deployment-2
    entrypoint: flows/goodbye.py:my_other_flow
    work_pool:
        name: my-process-work-pool
        work_queue_name: secondary-queue

  - name: deployment-3
    entrypoint: flows/hello.py:yet_another_flow
    work_pool:
        name: my-docker-work-pool
        work_queue_name: tertiary-queue

You can also use Python module paths as entrypoints instead of file paths:

deployments:
  - name: deployment-with-module-path
    entrypoint: my_package.flows.my_flow_func
    work_pool:
        name: my-process-work-pool

When using a module path, the module must be importable in the execution environment. Pull steps run before Prefect imports the module, so you can use pull steps such as git_clone to clone your repository and make the package importable. This is also useful when your flow is part of a package pre-installed in the execution environment. This file has three deployment declarations, each referencing a different flow. Each deployment declaration has a unique name field and can be deployed individually with the --name flag when deploying. For example, to deploy deployment-1, run:

prefect deploy --name deployment-1

To deploy multiple deployments, provide multiple --name flags:

prefect deploy --name deployment-1 --name deployment-2

To deploy multiple deployments with the same name, prefix the deployment name with its flow name:

prefect deploy --name my_flow/deployment-1 --name my_other_flow/deployment-1

To deploy all deployments, use the --all flag:

prefect deploy --all

To deploy deployments that match a pattern, run:

prefect deploy -n my-flow/* -n *dev/my-deployment -n dep*prod

The above command deploys:

all deployments from the flow my-flow
all flows ending in dev with a deployment named my-deployment
all deployments starting with dep and ending in prod.

Non-interactive deployment

For CI/CD pipelines and automated environments, use the --no-prompt flag to skip interactive prompts:

prefect --no-prompt deploy --name my-deployment

This prevents the command from hanging on prompts and will fail clearly if required information is missing.

CLI options when deploying multiple deploymentsWhen prefect deploy targets multiple entries in a prefect.yaml file, explicit CLI options are ignored. To apply CLI overrides, target a single entry.However, the default work pool environment variable, PREFECT_DEFAULT_WORK_POOL_NAME, is still applied to deployments whose prefect.yaml entry does not set work_pool.name, even when multiple entries are targeted.

Reuse configuration across deployments

Because a prefect.yaml file is a standard YAML file, you can use YAML aliases to reuse configuration across deployments. This capability allows multiple deployments to share the work pool configuration, deployment actions, or other configurations. Declare a YAML alias with the &{alias_name} syntax and insert that alias elsewhere in the file with the *{alias_name} syntax. When aliasing YAML maps, you can override specific fields of the aliased map with the <<: *{alias_name} syntax and adding additional fields below. We recommend adding a definitions section to your prefect.yaml file at the same level as the deployments section to store your aliases. For example:

build: ...
push: ...
pull: ...

definitions:
    work_pools:
        my_docker_work_pool: &my_docker_work_pool
            name: my-docker-work-pool
            work_queue_name: default
            job_variables:
                image: "{{ build-image.image }}"
    schedules:
        every_ten_minutes: &every_10_minutes
            - interval: 600
    actions:
        docker_build: &docker_build
            - prefect_docker.deployments.steps.build_docker_image: &docker_build_config
                id: build-image
                requires: prefect-docker>=0.3.0
                image_name: my-example-image
                tag: dev
                dockerfile: auto

        docker_push: &docker_push
            - prefect_docker.deployments.steps.push_docker_image: &docker_push_config
                requires: prefect-docker>=0.6.0
                image_name: my-example-image
                tag: dev
                credentials: "{{ prefect.blocks.docker-registry-credentials.dev-registry }}"

deployments:
  - name: deployment-1
    entrypoint: flows/hello.py:my_flow
    schedules: *every_10_minutes
    parameters:
        number: 42,
        message: Don't panic!
    work_pool: *my_docker_work_pool
    build: *docker_build # Uses the full docker_build action with no overrides
    push: *docker_push

  - name: deployment-2
    entrypoint: flows/goodbye.py:my_other_flow
    work_pool: *my_docker_work_pool
    build:
        - prefect_docker.deployments.steps.build_docker_image:
            <<: *docker_build_config # Uses the docker_build_config alias and overrides the dockerfile field
            dockerfile: Dockerfile.custom
    push: *docker_push

  - name: deployment-3
    entrypoint: flows/hello.py:yet_another_flow
    schedules: *every_10_minutes
    work_pool:
        name: my-process-work-pool
        work_queue_name: primary-queue

In the above example, YAML aliases reuse work pool, schedules, and build configuration across multiple deployments:

deployment-1 and deployment-2 use the same work pool configuration
deployment-1 and deployment-3 use the same schedules
deployment-1 and deployment-2 use the same build deployment action, but deployment-2 overrides the dockerfile field to use a custom Dockerfile

Deployment declaration reference

Deployment fields

These are fields you can add to each deployment declaration.

Property	Description
`name`	The name to give to the created deployment. Used with the `prefect deploy` command to create or update specific deployments.
`version`	An optional version for the deployment.
`tags`	A list of strings to assign to the deployment as tags.
`description`	An optional description for the deployment.
`schedules`	An optional list of schedules to assign to the deployment. Fields for each schedule are documented in the Schedule Fields section.
`concurrency_limit`	An optional deployment concurrency limit. Set to an integer for a simple limit, or use the Concurrency Limit Fields for additional options like collision strategy and grace period.
`triggers`	An optional array of triggers to assign to the deployment
`entrypoint`	Required reference to the flow function to deploy. Supports two formats: a file path with function name separated by a colon (for example, `path/to/file.py:flow_function_name`), or a Python module path (for example, `my_module.my_flow.my_func`). File paths are relative to the root directory of your development folder. Module paths must be importable in the execution environment.
`parameters`	Optional default values to provide for the parameters of the deployed flow. Should be an object with key/value pairs.
`enforce_parameter_schema`	Boolean flag that determines whether the API should validate the parameters passed to a flow run against the parameter schema generated for the deployed flow.
`work_pool`	Information of where to schedule flow runs for the deployment. Fields for this section are documented in the Work Pool Fields section.

Schedule fields

These are fields you can add to each entry in a deployment declaration’s schedules list.

Property	Description
`interval`	Time between flow runs. Accepts an integer (seconds), ISO 8601 duration string (e.g., `PT10M`, `PT1H30M`, `P1D`), or time format string (e.g., `1:30:00`). Cannot use in conjunction with `cron` or `rrule`.
`anchor_date`	Datetime string indicating the starting or “anchor” date to begin the schedule. If no `anchor_date` is supplied, the current UTC time is used. Can only use with `interval`.
`timezone`	String name of a time zone, used to enforce localization behaviors like DST boundaries. See the IANA Time Zone Database for valid time zones.
`cron`	A valid cron string. Cannot use in conjunction with `interval` or `rrule`.
`day_or`	Boolean indicating how croniter handles day and day_of_week entries. Must use with `cron`. Defaults to `True`.
`rrule`	String representation of an RRule schedule. See the `rrulestr` examples for syntax. Cannot used them in conjunction with `interval` or `cron`.

Removing schedules from a deploymentRemoving the schedules key from your prefect.yaml file, or setting schedules: null or schedules: [], does not remove existing schedules from a deployment when you run prefect deploy. Prefect treats the absence of schedule configuration as “no change” rather than “delete all schedules.”To explicitly remove schedules from an existing deployment, use the CLI:

# Remove all schedules from a deployment
prefect deployment schedule clear <flow-name>/<deployment-name> -y

# Remove a specific schedule by ID
prefect deployment schedule delete <flow-name>/<deployment-name> <schedule-id> -y

Concurrency limit fields

The concurrency_limit field accepts either a simple integer or a section with additional options:

deployments:
  # Simple integer form:
  - name: my-deployment
    concurrency_limit: 5
    ...

  # Detailed form with collision strategy and grace period:
  - name: my-other-deployment
    concurrency_limit:
      limit: 5
      collision_strategy: CANCEL_NEW
      grace_period_seconds: 120
    ...

When using the detailed form, these are the available fields:

Property	Description
`limit`	The maximum number of concurrent flow runs for the deployment.
`collision_strategy`	Configure the behavior for runs once the concurrency limit is reached. Options are `ENQUEUE` and `CANCEL_NEW`. Defaults to `ENQUEUE`.
`grace_period_seconds`	The time in seconds to allow infrastructure to start before the concurrency slot is released. Must be between 60 and 86400 seconds. If not set, falls back to the server setting (default 300 seconds / 5 minutes).

Work pool fields

These are fields you can add to a deployment declaration’s work_pool section.

Property	Description
`name`	The name of the work pool to schedule flow runs in for the deployment.
`work_queue_name`	The name of the work queue within the specified work pool to schedule flow runs in for the deployment. If not provided, the default queue for the specified work pool is used.
`job_variables`	Values used to override the default values in the specified work pool’s base job template. Maps directly to a created deployments `infra_overrides` attribute.

Deployment mechanics

Anytime you run prefect deploy in a directory that contains a prefect.yaml file, the following actions take place in order:

The prefect.yaml file load. First, the build section loads and all variable and block references resolve. The steps then run in the order provided.
Next, the push section loads and all variable and block references resolve; the steps within this section then run in the order provided.
Next, the pull section is templated with any step outputs but is not run. Block references are not hydrated for security purposes: they are always resolved at runtime.
Next, all variable and block references resolve with the deployment declaration. All flags provided through the prefect deploy CLI are then overlaid on the values loaded from the file.
The final step occurs when the fully realized deployment specification is registered with the Prefect API.

Deployment instruction overridesThe build, push, and pull sections in deployment definitions take precedence over the corresponding sections above them in prefect.yaml.

Each time a step runs, the following actions take place in order:

The step’s inputs and block / variable references resolve.
The step’s function is imported; if it cannot be found, the special requires keyword installs the necessary packages.
The step’s function is called with the resolved inputs.
The step’s output is returned and used to resolve inputs for subsequent steps.

Update a deployment

To update a deployment, make any desired changes to the prefect.yaml file, and run prefect deploy. Running just this command will prompt you to select a deployment interactively, or you may specify the deployment to update with --name your-deployment.

Workflows

Deployments

Configuration

Automations

Workflow Infrastructure

Prefect Cloud

Prefect Self-hosted

AI

Migrate

How to define deployments with YAML

Deployment actions

The build action

The push action

The pull action

Utility steps

Custom deployment steps

How steps work

Writing a custom step function

Practical examples

Templating options

Work with multiple deployments with prefect.yaml

Non-interactive deployment

Reuse configuration across deployments

Deployment declaration reference

Deployment fields

Schedule fields

Concurrency limit fields

Work pool fields

Deployment mechanics

Update a deployment

Further reading

​Deployment actions

​The build action

​The push action

​The pull action

​Utility steps

​Custom deployment steps

​How steps work

​Writing a custom step function

​Practical examples

​Templating options

​Work with multiple deployments with prefect.yaml

​Non-interactive deployment

​Reuse configuration across deployments

​Deployment declaration reference

​Deployment fields

​Schedule fields

​Concurrency limit fields

​Work pool fields

​Deployment mechanics

​Update a deployment

​Further reading

Deployment actions

The build action

The push action

The pull action

Utility steps

Custom deployment steps

How steps work

Writing a custom step function

Practical examples

Templating options

Work with multiple deployments with prefect.yaml

Non-interactive deployment

Reuse configuration across deployments

Deployment declaration reference

Deployment fields

Schedule fields

Concurrency limit fields

Work pool fields

Deployment mechanics

Update a deployment

Further reading