[GH-ISSUE #1492] Allow loading WebPush secrets from private file #1053

New issue

Closed

opened 2026-05-07 00:29:52 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:29:52 +02:00

Owner

Originally created by @ntninja on GitHub (Nov 20, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1492

💡 Idea
Similar to #590, it would be nice to have to ability to load WebPush secrects from file (preferable the file generated by ntfy webpush keys). When using NTFY on NixOS there is otherwise no way to not make these keys world-readable.

💻 Target components
ntfy server

Originally created by @ntninja on GitHub (Nov 20, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1492 :bulb: **Idea** Similar to #590, it would be nice to have to ability to load WebPush secrects from file (preferable the file generated by `ntfy webpush keys`). When using NTFY on NixOS there is otherwise no way to *not* make these keys world-readable. :computer: **Target components** ntfy server

BreizhHardware

2026-05-07 00:29:52 +02:00

closed this issue
added the
enhancement

server
labels

BreizhHardware commented

2026-05-07 00:29:53 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 1, 2026):

I don't think I would want to implement this. The server.yml file can be easily made read-only by only the user that runs ntfy. There are many other secrets in the config file that would also need special handling.

@binwiederhier commented on GitHub (Feb 1, 2026): I don't think I would want to implement this. The server.yml file can be easily made read-only by only the user that runs ntfy. There are many other secrets in the config file that would also need special handling.

BreizhHardware commented

2026-05-07 00:29:54 +02:00

Author

Owner

@ntninja commented on GitHub (Feb 2, 2026):

With closing this, your saying that you won’t implement this or that you don't want anyone to implement this?

The server.yml file can be easily made read-only by only the user that runs ntfy.

I was specifically talking about NixOS where the server configuration file is not managed by any user that run ntfy, it is managed by the Nix configuration system and that means, since it is stored as a build result in the local Nix store, it will always be world-readable.

There are many other secrets in the config file that would also need special handling.

Given this, may I instead propose adding “YAML includes” (not really a YAML thing) like GitLab CI/CD does: https://docs.gitlab.com/ci/yaml/includes/#include-a-single-configuration-file

That is: A top-level list key named include that will cause the referenced file paths to be read as YAML file and merged on top of the main configuration file.

Conveniently, that than also happens to match the output of ntfy webpush keys -f …, meaning you then just need to add the path of the generated web-push secrets file to the includes list.

@ntninja commented on GitHub (Feb 2, 2026): With closing this, your saying that *you* won’t implement this or that you don't want *anyone* to implement this? > The server.yml file can be easily made read-only by only the user that runs ntfy. I was specifically talking about NixOS where the server configuration file is not managed by any *user that run ntfy*, it is managed by the Nix configuration system and that means, since it is stored as a build result in the local Nix store, it will always be world-readable. > There are many other secrets in the config file that would also need special handling. Given this, may I instead propose adding “YAML includes” (not really a YAML thing) like GitLab CI/CD does: https://docs.gitlab.com/ci/yaml/includes/#include-a-single-configuration-file That is: A top-level list key named `include` that will cause the referenced file paths to be read as YAML file and merged on top of the main configuration file. Conveniently, that than also happens to match the output of `ntfy webpush keys -f …`, meaning you then just need to add the path of the generated web-push secrets file to the includes list.

BreizhHardware commented

2026-05-07 00:29:54 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 2, 2026):

ntfy uses a CLI library that does not support this. And the entire thing also has to be supported for env variables. I wouldn't know how to. If you have a great idea how, supply a PR and it works for ALL the secrets, then I'll absolutely merge it if it isn't too hacky.

@binwiederhier commented on GitHub (Feb 2, 2026): ntfy uses a CLI library that does not support this. And the entire thing also has to be supported for env variables. I wouldn't know how to. If you have a great idea how, supply a PR and it works for ALL the secrets, then I'll absolutely merge it if it isn't too hacky.

BreizhHardware commented

2026-05-07 00:29:54 +02:00

Author

Owner

@ntninja commented on GitHub (Feb 2, 2026):

Ok, I just looked and the code to adapt for this right here:
github.com/binwiederhier/ntfy@68e22ebe7d/cmd/config_loader.go (L42-L60)

Your loading the YAML file using a YAML parser, then match reach CLI flag to an option in the parsed YAML file.

Adaption would be to first check for item named include, then open each path specified therein and also parse them as YAML, then perform the flag search for each opened YAML file in order.

@ntninja commented on GitHub (Feb 2, 2026): Ok, I just looked and the code to adapt for this right here: https://github.com/binwiederhier/ntfy/blob/68e22ebe7d83e6fe9c6aafd99c1bdaa8fcd14272/cmd/config_loader.go#L42-L60 Your loading the YAML file using a YAML parser, *then* match reach CLI flag to an option in the parsed YAML file. Adaption would be to first check for item named `include`, then open each path specified therein and also parse them as YAML, then perform the flag search for each opened YAML file in order.