Blocks are a powerful abstraction that allow you to compose and re-use multi-environment slices of configuration. They're like mixins or modules for your config. With blocks, you can avoid duplication, streamline updates, and automatically maintain least-privilege access control for values that are needed in more than one place by your systems.
Blocks are similar to apps. They have multiple environments like development, staging, and production. They can have branches and local overrides. You can customize their environments, rollback to previous versions, and check audit logs.
Unlike apps, you don't load the variables set in a block environment directly with
envkey-source, and you can't generate a server
ENVKEY for a block environment. Instead, to use the values set within a block, you first connect it to an app. A block can be connected to multiple apps.
Access control also works differently for blocks than it does for apps. While access to apps is assigned directly, block access is resolved automatically based on a user's access to the apps a block is connected to. If a user has been given read access to an environment in any connected app, they'll also have read access to the block's environment. But for write access to an environment, the user must have write access to that environment in all connected apps.
The order of the blocks that are connected to an app is significant. In the UI, use the re-order button to drag and re-order an app's blocks:
If multiple blocks have the same variable defined, later blocks will overwrite the values of earlier blocks.
Be careful when updating blocks
If a block is connected to many apps, an update might have large effects throughout your systems. Make sure you keep in mind all the apps a block is connected to when making changes.
Updated over 1 year ago