[🐛 Bug]: Bump to v0.46.0 issue with Jira povider provisioning

[piekarski-mateusz]

Describe the bug
The previous release I was using was v0.45.15
I have recently updated my Keep to v0.46.0.
Ever since the update my provisioned Jira provider is not visible in Providers.
I'm getting the following error log:
Configuration problem while trying to initialize the provider jira. Probably missing provider config, please check the provider configuration.
I suspect it may have to do with this PR #5157
To Reproduce
Steps to reproduce the behavior:

1. Have a provisioned Jira provider through a file
2. The provider will be visible in Providers tab and workflows will work
3. Update to v0.46.0.
4. The provider will not be present in Providers tab, workflows will not work
5. The error log will be present

Expected behavior
I'd like to still be able to have a provisioned Jira provider

Screenshots

[dosubot]

The error and disappearance of your Jira provider after upgrading to v0.46.0 is due to stricter config validation and a change in supported provisioning methods. File-based provisioning is not currently supported; only environment variable provisioning (KEEP_PROVIDERS as a JSON string) is supported in v0.46.0. If the environment variable is missing or misconfigured, Keep will remove all provisioned providers on startup, which explains why your provider vanished after the upgrade [source].

Your Jira provider config must include all required fields in the authentication block: email, api_token, and host (must be an https URL). Here’s a minimal valid example for KEEP_PROVIDERS:

{
  "jira-provider-name": {
    "type": "jira",
    "authentication": {
      "email": "your-email@example.com",
      "api_token": "your-api-token",
      "host": "https://your-domain.atlassian.net"
    }
  }
}

Checklist:

• Make sure you are using the KEEP_PROVIDERS environment variable with a valid JSON config (as above).
• Double-check that all required fields are present and correctly named.
• If running in Kubernetes or with multiple backend replicas, set SECRET_MANAGER_TYPE=k8s to avoid provider disappearance due to local file storage [source].
• If you see tenant-related errors, ensure the tenant table is initialized (sometimes a backend restart after first login helps) [source].

If you’re still having trouble, feel free to share your (redacted) config and provisioning method for more targeted help.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[piekarski-mateusz]

@dosu

The documentation mentions a support for provisioning providers by .yaml files in a directory:
KEEP_PROVIDERS_DIRECTORY
My jira.yaml file looks okay and worked fine before the bump.
$ cat jira.yaml

authentication:
    api_token: some_token
    email: some@email.com
    host: https://some.atlassian.net
type: jira

It also works after a revert

[dosubot]

YAML-based provider provisioning via KEEP_PROVIDERS_DIRECTORY is still fully supported and recommended in v0.46.0, but the validation is now stricter: your YAML must include a top-level name field. Without it, the provider will be silently skipped and not appear in the UI or logs as an error (docs).

To fix this, update your jira.yaml to:

name: my-jira-provider
type: jira
authentication:
  api_token: some_token
  email: some@email.com
  host: https://some.atlassian.net

Make sure you are not setting both KEEP_PROVIDERS and KEEP_PROVIDERS_DIRECTORY at the same time, and restart the backend after making changes. If you’re running in Kubernetes or with multiple replicas, set SECRET_MANAGER_TYPE=k8s to avoid provider disappearance issues (details). If the provider still doesn’t show up, check backend logs for YAML parsing or validation errors.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}