Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
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.