Not your typical self-hosted kind of project, but useful for other self-hosted projects
For myself, I had been storing critical values like passwords and tokens in my .env file and just loading them up with load_dotenv()
I got frustrated that I couldn’t find a relatively native python library that didn’t require calling restful APIs and wasn’t just reading from plaintext, so finally decided to put on that gauntlet and say “Fine, I’ll do it myself”
Please feel free to use or fork for your own needs :) And let me know if this is a silly endeavour or you see any major issues! It’s very barebones and simple (hence the name)
So I like the idea. The main “problem” I see is that it/you assume that I have access to the code and can modify at will. lol to leverage this. If I have a database container but I don’t want to hard code the secret in a .env, how do I leverage your code/app/library? Another thing is, most of the time these type of secret managers require a password… to retrieve … a password. What’s the benefit in that? What other authentication methods can you provide to authenticate and retrieve the secret I want (without running into the chicken or egg problem). Two example that comes to mind right now are certificate based authentication and IP restrictions.
I do understand that the scenarios I’m describing above may not be the goal of your code. I self host a lot of stuff (10-15 services) that all requires credential but only one app is custom written (so I have access to the source code and can make use of your code) BUT I still need to centrally manage credentials for it all.
I do like the idea of having a single file with the creds. Especially for a small environment, databases are just overkill for this use case (in most cases) and it makes it really easy to backup your creds since it’s just one file.
Perhaps writing up some documentation on ideas and examples for backing up the credentials (rsync, simple copy/paste, etc) would help new comers.
P.S. Bonus points if you can make your code rotate said credentials on a schedule so they are never static.
Thanks for the comment! Yes this is meant more for your personal projects than for using in existing projects
The idea behind needing a password to get a password, totally understand, my main goal was to have local encrypted storage, the nice thing about this implementation is that you can have all your env files saved and shared in your git repo for all devs to have access to, but only can decrypt it if given the master password shared elsewhere (keeper, vault etc) so you don’t have to load all values from a vault, just the master
100% though this doesn’t cover a large range of usage, hence the name “simple” haha, wouldn’t be opposed to expanding but I think it covers my proposed use cases as-is
I certainly understand the main purpose and honestly you have a good point about git.
Let’s say that I can utilize your code within my personal app, but my personal app leverages a database (postgres). How would I integrate my app, the database and your library? Unless I’m missing something, I would still need a .env for the database since I don’t have access to the source code of the database.