Skip to main content

About blocks

Prefect blocks store configuration and provide an interface for interacting with external systems. Blocks expose methods that provide functionality specific to these systems. For example, you can use blocks to:
  • Download data from, or upload data to, an S3 bucket
  • Query data from, or write data to, a database
  • Send a message to a Slack channel.
Block types are Python classes with a UI webform for configuration. Blocks are instantiation of these classes with specific values. Configure blocks through Python code or through the UI. Access blocks for use in Python code. Block values are stored in Prefect Cloud or your self-hosted Prefect server instance. You can share blocks with other users in your Prefect Cloud workspace. To see block types available for configuration, use prefect block type ls from the CLI or navigate to the Blocks page in the UI and click +. The block catalogue in the UI
Blocks and parametersBlocks are useful for sharing configuration across flow runs and between flows.For configuration that will change between flow runs, we recommend using parameters.

Prefect built-in blocks

Commonly used block types come built-in with Prefect. You can create and use these block types through the UI and without installing any additional packages.
The S3, Azure, GCS, and GitHub blocks are deprecated in favor of the the corresponding S3Bucket, AzureBlobStorageCredentials, GCSBucket, and GitHubRepository blocks found in the Prefect integration libraries. The JSON, DateTime, and String blocks are deprecated in favor of Variables.

Blocks in Prefect integration libraries

Some block types that appear in the UI can be created immediately, with the corresponding integration library installed for use. For example, an AWS Secret block can be created, but not used until the prefect-aws library is installed. Anyone can create block types and optionally share them with the community. Find available block types in many of the published Prefect integrations libraries. If a block type is not available in the UI, you can register it through the CLI.

Use existing block types

Blocks are classes that subclass the Block base class. You can instantiate and use them like normal classes.

Instantiate blocks

To instantiate a block that stores an S3 bucket value, use the S3Bucket block:

Save blocks

To retrieve this saved value use the .save() method:
To update saved block value stored for a given block, overwrite the existing block by passing overwrite=True:
Create a new S3Bucket by setting the name parameter to a new value:

Load blocks

You can use the block name to load the block:
Alternatively, load a block with the unique slug that is a combination of the block type slug and the block name. To load the S3Bucket block from above, run the following:

Delete blocks

Delete a block with the .delete() method:
Alternatively, use the CLI to delete specific blocks with a given slug or id:

Create a new block type

To create a custom block type, define a class that subclasses Block. The Block base class builds on Pydantic’s BaseModel, so you can declare custom blocks just like a Pydantic model. Here’s a block that represents a cube and holds information about the length of each edge in inches:
You can include methods on a block to provide functionality. Here’s the same cube block with methods to calculate the volume and surface area of the cube:
Use the new Cube block type in a flow:

Secret fields

All block values are encrypted before being stored. If you have values that you would not like visible in the UI or in logs, use the SecretStr field type provided by Pydantic to automatically obfuscate those values. You can use this functionality for fields that store credentials such as passwords and API tokens. Here’s an example of an AWSCredentials block that uses SecretStr:
Since aws_secret_access_key has the SecretStr type hint assigned to it, the value of that field is not exposed if the object is logged:
Prefect’s SecretDict field type allows you to add a dictionary field to your block that automatically obfuscates values at all levels in the UI or in logs. This functionality is useful for blocks where typing or structure of secret fields is not known until configuration time. Here’s an example of a block that uses SecretDict:
system_secrets is obfuscated when system_configuration_block is displayed, but system_variables show up in plain-text:

Block type metadata

Set metadata fields on a block type’s subclass to control how a block displays. Available metadata fields include:

Nested blocks

Blocks are composable: a block can be used within other blocks. You can create a block type that uses functionality from another block type by declaring it as an attribute. Nestable blocks are loosely coupled, and configuration can be changed for each block independently. This allows sharing configuration across multiple use cases. For example, here’s an expanded AWSCredentials block that enables an authenticated session through the boto3 library:
You can use the AWSCredentials block within an S3Bucket block to provide authentication when interacting with an S3 bucket:
You can use this S3Bucket block with previously saved AWSCredentials block values in order to interact with the configured S3 bucket:
This creates a reference from the AWSCredentials block my_aws_credentials to the S3Bucket block my_s3_bucket, so that changes to the values in my_aws_credentials propogate to my_s3_bucket. Values for nested blocks can also be specified in place:
In the above example, the values for AWSCredentials are saved with my_s3_bucket and are not usable with any other blocks.

Update custom Block types

Here’s an example of how to add a bucket_folder field to your custom S3Bucket block; it represents the default path to read and write objects from (this field exists on our implementation). Add the new field to the class definition:
Then register the updated block type with either Prefect Cloud or your self-hosted Prefect server instance. If you have any existing blocks of this type that were created before the update and you’d prefer to not re-create them, migrate them to the new version of your block type by adding the missing values:

Register blocks

Prefect comes with many blocks pre-registered and ready to use. If you do not have a block available for use, you can register it. Register blocks from a Python module available in the current environment with a CLI command:
This command is useful for registering all blocks found within a module in a Prefect Integration library. Alternatively, if a custom block was created in a .py file, you can register the block with the CLI command:
The registered block is now available for configuration.