Centralized Configuration Management
What would you like to Propose?
Problem: Each module may have its own .env or application.properties, creating inconsistencies.
Feature Request: Implement a shared configuration module (e.g., via Spring Cloud Config or simple YAML config repo) that defines:
- Common environment variables(DB URL, JWT secret, Vault key)
- Per-service overrides
Benefit: Easier maintenance and secure key rotation
Issue details
Problem: Each module may have its own .env or application.properties, creating inconsistencies.
Additional Information
I’d like to suggest moving away from maintaining separate .env or application.properties files for each microservice, which often leads to inconsistencies and makes configuration management more complex. Instead, adopting a centralized configuration system—such as Spring Cloud Config or a shared YAML-based repository—can help define common environment variables (like DB URLs, JWT secrets, Vault keys) in one place, while still allowing service-specific overrides. This approach not only simplifies maintenance and improves visibility, but also enhances security through easier key rotation and streamlines deployment for DevOps teams by making configuration access and updates more efficient.
This proposal aims to improve maintainability and security by consolidating configuration management. Please share feedback on preferred implementation — Spring Cloud Config vs. a lightweight shared YAML repo.
I prefer starting with a lightweight shared YAML repository. It keeps onboarding simple, fits the current project scale and self-hosting focus, and avoids extra infrastructure overhead. We can migrate to Spring Cloud Config later when more services and dynamic config updates are needed. Reasons: 1.Faster to adopt and onboard new contributors 2.Lower Complexity - ideal at the current project stage 3.Keeps things transparent and easy to customize for self-hosted environments 4.Works well for early modularization before introducing additional infra