mirror of
https://github.com/pocket-id/pocket-id.git
synced 2026-02-28 03:13:38 +03:00
🚀 Feature: Improvements for declarative installations #573
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ayles on GitHub (Dec 24, 2025).
Feature description
Pitch
I like the idea of Pocket ID being simple, but I struggle with setting it up in my NixOS installation. A common pattern in NixOS is to generate and encrypt secrets with something like age and store them in the same repo as the configuration. On service start, secrets are decrypted and fed into environment variables or as file paths.
For example, I use this pattern with Authelia and Immich. I can store a secret once and refer to it from both configurations, as they can pick up secrets from config files or environment variables. This also works well with tools like agenix-rekey, which makes it easy to regenerate all secrets with one command and then deploy.
Although Pocket ID's API can be used in scripts to manage entities declaratively, it's hard to use right now. My current method is ugly: on service start, a script requests a one-time access token via the pocket-id CLI, parses it from the human-readable text, and then exchanges it for a cookie to make API calls. This is fragile because the CLI output may change, and it requires creating an admin user first.
Several related issues exist (e.g., #83, #586), but they don't fully explain the use case for declarative setups.
@jasonboukheir commented on GitHub (Dec 26, 2025):
I've been wanting to do this myself since I have an ever growing list of clients that I manage client secrets for. I think it might be easier to implement this as additional CLI cobra commands. We just need to expose some CLI commands for
ensureUsersorensureClientsWay simpler than trying to use the API.
Though I could be wrong--could you show me how you're doing it @ayles ?EDIT: just reread your post and that's what I figured
Anyway, I was planning on forking and adding a feature like this to get it working.
@coffe-cafe-zed commented on GitHub (Jan 6, 2026):
I added a draft PR here https://github.com/pocket-id/pocket-id/pull/1205. I will test it and improve it further if it look good to maintainers
@ayles commented on GitHub (Jan 18, 2026):
Appreciate the work, @stonith404! Regarding custom client secrets: is this currently supported, or should we look into adding that as a feature?
@kmendell commented on GitHub (Jan 19, 2026):
@ayles I believe Elias and I discussed this before I can not find the issue though, but I believe we decided against allowing secrets to be defined
@ayles commented on GitHub (Jan 19, 2026):
But why? Of course, I don't want them to be defined as envs, but a simple additional endpoint to be able to specify them directly with POST/PUT will be enough. I don't believe that will add such maintenance cost, but it will 'unblock' fully declarative scenarios. Otherwise, allowing a global API key to be specified as an env doesn't make much sense, I believe.
@aclerici38 commented on GitHub (Jan 19, 2026):
IIRC the client secret is not returned when the client is initially created but is returned on
/api/oidc/clients/{id}/secret. So it's not fully a blocker for a declarative install if I understand correctly as you can re-gen the client secret and get it in the response@kmendell commented on GitHub (Jan 19, 2026):
I dont remember the full reason why, im trying to find the conversation I could be misremembering as this was awhile ago around the time of 1.8.0, but either way Elias is gone for a few months, so I won't be able to ask him till he gets back.
@ayles commented on GitHub (Jan 19, 2026):
Okay. Ping me please when some new info will come up. Thanks in advance!
@ayles commented on GitHub (Jan 19, 2026):
I deploy multiple clients inside containers on multiple hosts over a private network. Pre-encrypted static configuration helps a lot here. In theory, I could just share the API key with each container and they will be able to re-request, cache and use secrets. But that would be ugly, wouldn't it?
@jasonboukheir commented on GitHub (Jan 22, 2026):
I got it kinda-sorta working in NixOS here: https://github.com/jasonboukheir/dotfiles/pull/5
I didn't do a pretty job, but maybe it will inspire y'all. When I have some more time, I could put it upstream in nixpkgs.
@aclerici38 commented on GitHub (Jan 22, 2026):
If anyone wants a declarative solution for k8s I put together this https://github.com/aclerici38/pocket-id-operator