I’m working on multiple backend services and need a way to expose service information like name, version, build time, git branch, and commit hash through REST endpoints. I want internal developers to easily access this metadata without having to check Docker or Kubernetes details.
Some of my services run with docker-compose while others are deployed on Kubernetes. I’m looking for a standardized way to implement this kind of service introspection.
I’ve come across the Server header as one option, but I’m wondering if there are established patterns or specifications for creating dedicated endpoints that return this type of service information. What would be the best practice for implementing this across different services?
this sounds cool! are you thinking about using an /health or /info endpoint? i’ve seen teams use /actuator/info, but what’s your specific use case? is it for monitoring dashboards or debugging? also, how do you plan to get build metadata into containers during ci/cd?
Most people use a /actuator/info endpoint that returns JSON metadata. Just inject environment variables or config files with your service metadata during the build process. For Docker, use build arguments to pass git commit info and timestamps. With Kubernetes, ConfigMaps work great for storing and injecting this data. Keep things consistent by standardizing your JSON response structure across all services. I’d include service name, version, build timestamp, git branch, commit hash, and deployment environment. This works whether you’re running docker-compose locally or deploying to production K8s clusters, and keeps it separate from your health checks.
for sure! the /info is pretty standard now. spring boot actuator does make it easy, but ya can totally create it urself. just make a get endpoint to return json with service info like version and build time. set them as env vars during build, it’s simple!