Feature Summary
Add a supported, non-interactive way to provision API keys declaratively
What problem does this feature solve?
Miniflux API keys currently have to be created after the application is running, either through the UI or via POST /v1/api-keys. This makes fully declarative deployments unnecessarily difficult.
For example, on NixOS I would like to deploy Miniflux together with another service that consumes the Miniflux API (I use it to enable homepage widget).
As far as I can tell, there is currently:
- no configuration/environment option for defining an API key;
- no
*_FILE option for reading an API key from a secret file;
As a result, configuration-management systems such as NixOS, need an additional imperative bootstrap step:
- Start Miniflux.
- Authenticate using the user's password.
- Query existing API keys.
- Determine whether the desired key already exists.
- Create it if necessary.
- Extract the generated token.
- Store the token somewhere outside Miniflux.
- Start the dependent service.
This works, but requires custom logic for something that could be handled directly by Miniflux.
Proposed Solution
Add a supported mechanism for non-interactive and idempotent API key provisioning.
I don't have a strong preference for the exact interface. Any of the following would solve the problem.
CLI
For example:
miniflux -create-api-key \
-username admin \
-description homepage \
-token-file /run/secrets/miniflux-homepage-api-key
Ideally the command would be idempotent.
Configuration / environment
Another possibility would be a file-based configuration option, for example:
API_KEY_DESCRIPTION=homepage
API_KEY_FILE=/run/secrets/miniflux-homepage-api-key
Using a file rather than passing the secret directly through an environment variable or command-line argument would work well with secret-management tools.
API
Alternatively, POST /v1/api-keys could optionally accept a caller-provided token instead of always generating one.
Alternatives Considered
The existing REST API can be used as a workaround. A provisioning service/script can authenticate to Miniflux using the user's username/password, call /v1/api-keys, look for a key with a particular description, create one if it does not exist, and then save the generated token to a local secret/state file.
This is workable, but every deployment system then has to implement and maintain its own bootstrap logic. For declarative systems such as NixOS this also introduces mutable state outside the normal configuration flow.
Another option is to create the API key manually in the UI, but that prevents a deployment from being reproduced automatically.
Additional Context
My immediate use case is NixOS, where Miniflux and services consuming its API are configured declaratively.
NixOS already supports supplying the initial Miniflux admin credentials from a file, so a similar mechanism for API credentials would fit well with secret-management tools such as sops-nix.
This is not specifically a NixOS request, though. The same functionality would be useful for Kubernetes, Ansible, Terraform, container-based deployments, and other automated configuration-management systems.
Checklist
Feature Summary
Add a supported, non-interactive way to provision API keys declaratively
What problem does this feature solve?
Miniflux API keys currently have to be created after the application is running, either through the UI or via
POST /v1/api-keys. This makes fully declarative deployments unnecessarily difficult.For example, on NixOS I would like to deploy Miniflux together with another service that consumes the Miniflux API (I use it to enable homepage widget).
As far as I can tell, there is currently:
*_FILEoption for reading an API key from a secret file;As a result, configuration-management systems such as NixOS, need an additional imperative bootstrap step:
This works, but requires custom logic for something that could be handled directly by Miniflux.
Proposed Solution
Add a supported mechanism for non-interactive and idempotent API key provisioning.
I don't have a strong preference for the exact interface. Any of the following would solve the problem.
CLI
For example:
Ideally the command would be idempotent.
Configuration / environment
Another possibility would be a file-based configuration option, for example:
Using a file rather than passing the secret directly through an environment variable or command-line argument would work well with secret-management tools.
API
Alternatively,
POST /v1/api-keyscould optionally accept a caller-provided token instead of always generating one.Alternatives Considered
The existing REST API can be used as a workaround. A provisioning service/script can authenticate to Miniflux using the user's username/password, call
/v1/api-keys, look for a key with a particular description, create one if it does not exist, and then save the generated token to a local secret/state file.This is workable, but every deployment system then has to implement and maintain its own bootstrap logic. For declarative systems such as NixOS this also introduces mutable state outside the normal configuration flow.
Another option is to create the API key manually in the UI, but that prevents a deployment from being reproduced automatically.
Additional Context
My immediate use case is NixOS, where Miniflux and services consuming its API are configured declaratively.
NixOS already supports supplying the initial Miniflux admin credentials from a file, so a similar mechanism for API credentials would fit well with secret-management tools such as sops-nix.
This is not specifically a NixOS request, though. The same functionality would be useful for Kubernetes, Ansible, Terraform, container-based deployments, and other automated configuration-management systems.
Checklist