Patterns for Storing Data for Cortex Plugins

Environment-specific config via build/deploy-time variables

When to use:
You want configuration to differ by environment/workspace (e.g., prod vs sandbox) and you’re already building or deploying the plugin separately for each environment.

How it works:

• Inject configuration values as environment variables at build or deploy time for each workspace.
• The plugin reads these environment variables at runtime and adjusts behavior accordingly.

Plugin configuration entity with x-cortex-custom-metadata

When to use:
You want configuration to be data-driven inside Cortex, editable without changing the plugin code or build, and potentially different per environment/workspace.

Core idea:

• Create a dedicated configuration entity for each plugin, typically named:<plugin-tag>-config
• On that entity, store configuration data under x-cortex-custom-metadata. 
• In each environment/workspace, you have a corresponding <plugin-tag>-config entity with environment‑specific values (e.g., tenant-name: org-prod and prod URLs in your prod workspace, and then corresponding sandbox alternatives).