Is there an tool or app I can use share env and configurations locally?
Currently I built a Java Spring Boot service to manage my own stack of apps I use at home. Its been a hobby project for a while but I am thinking of maturing it into something more workable for other people. The Spring Boot service essentially does…
Currently I built a Java Spring Boot service to manage my own stack of apps I use at home. Its been a hobby project for a while but I am thinking of maturing it into something more workable for other people. The Spring Boot service essentially does dashboarding, app management and some other local stuff. I try to not re-invent the wheel and use other tools were possible e.g. Caddy avahi Wireguard Docker Compose Authelia I am using Authelia to manage user accounts However the thing I am struggling with is config value sharing. Currently I am storing things in an SQLite DB and access them that way. e.g. I create a container for SilverNotes, the Java service accesses the DB to find the default admin username. After creating Silvernotes it then updates the config DB with the Vhosts name e.g. notes.myhost.local and any other useful information. This config DB is then access by Caddy to update any routing for this new service created. The problem is, if someone makes any config changes to Silvernotes or something else, the Java management app won't detect that. If this was on the cloud I would use a secrets manager and have environment variables injected into the container when its created. Is there something similar for local cloud? (I don't want to re-invent the wheel)
Collected discussion
Expand the replies to this comment to learn how AI was used in this post/project.
You've built half of a control plane, and the part that hurts — config sharing — is the part where direction matters more than storage. The pattern that stays sane: your DB holds INTENT only (what should exist, with which settings). At apply time you render that intent into artifacts containers natively consume — .env files, compose fragments, labels. Containers never reach back into your DB. Anything that's current state (vhosts, ports, container ids) you read live from the Docker API instead of writing back. The moment state flows both ways you get drift — and drift is exactly what the "after creating X, update the config DB with vhosts" dance turns into. Since Caddy is already in your stack: look at the caddy-docker-proxy pattern. Vhosts live as labels on the containers themselves and get discovered automatically — that deletes the vhost-bookkeeping step entirely. The label IS the config, attached to the thing it configures, and it dies with the container. And keep secrets out of the rendered .env world: sops+age or docker secrets, referenced at render time. An SQLite full of admin passwords is the part future-you regrets first.