Choose between secrets and providers
Where: the sidebar's Secrets, Providers, and Sources areas. These are different resources; creating one does not configure every consumer automatically.
Secrets stores named credentials for explicit runtime consumers.
Secrets stores named credentials for explicit runtime consumers.
Secrets stores named credentials for explicit runtime consumers.
| Need | Configure it here |
|---|---|
| Connect Platform to a database/service | Sources connection form |
| Supply an API key/token to function code | Secrets, then the function's Configuration bindings |
| Let Chat or AI logic use a model service | AI Providers, then select/bind it in the consumer |
| Publish/read OpenLineage events | Lineage Providers |
Configure the resource and its consumer#
Create the resource in the correct workspace, then open the consumer's configuration. A secret needs an alias binding; a function provider needs its provider/model configuration; an AI pipeline node needs a selected Provider and Model. A source needs credentials capable of the actual external operation.
Provider creation starts by choosing the AI service configuration.
Provider creation starts by choosing the AI service configuration.
Provider creation starts by choosing the AI service configuration.
Test one operation that exercises the binding and verify the returned record or service result. Avoid printing credential values while testing. Resource names and aliases are safe labels; actual tokens/passwords should remain in the credential fields.
Rotation and sharing#
Update the credential through its own edit flow, then run a small consumer test. Sharing the consumer does not automatically grant arbitrary access to every credential resource. For packaged workflows, the destination supplies its own secret/provider/source bindings when requirements request them.
Was this page helpful?