<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Configuration on Devops Monk</title><link>https://devops-monk.com/tags/configuration/</link><description>Recent content in Configuration on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 03 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://devops-monk.com/tags/configuration/index.xml" rel="self" type="application/rss+xml"/><item><title>Application Configuration: Properties, YAML, and Profiles</title><link>https://devops-monk.com/tutorials/spring-boot/spring-boot-configuration-profiles/</link><pubDate>Sun, 03 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/spring-boot/spring-boot-configuration-profiles/</guid><description>Every real application needs different configuration for different environments — a local database for dev, a connection pool for staging, a secret manager for prod. This article covers everything Spring Boot gives you to handle this cleanly.
application.properties vs application.yml Spring Boot reads configuration from src/main/resources/application.properties (or .yml) by default. Both formats express the same thing:
application.properties:
server.port=8080 spring.datasource.url=jdbc:postgresql://localhost:5432/orders spring.datasource.username=app spring.datasource.password=secret spring.jpa.show-sql=false application.yml:
server: port: 8080 spring: datasource: url: jdbc:postgresql://localhost:5432/orders username: app password: secret jpa: show-sql: false YAML is generally preferred for nested properties — it&amp;rsquo;s less repetitive.</description></item><item><title>Externalized Configuration with @ConfigurationProperties</title><link>https://devops-monk.com/tutorials/spring-boot/spring-boot-configuration-properties/</link><pubDate>Sun, 03 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/spring-boot/spring-boot-configuration-properties/</guid><description>@ConfigurationProperties binds external configuration to a typed Java class — replacing scattered @Value annotations with a single, validated, testable object.
Why @ConfigurationProperties Over @Value // @Value — scattered, no type safety, no validation @Service public class PaymentService { @Value(&amp;#34;${payment.gateway.url}&amp;#34;) private String gatewayUrl; @Value(&amp;#34;${payment.gateway.timeout:5000}&amp;#34;) private int timeoutMs; @Value(&amp;#34;${payment.gateway.api-key}&amp;#34;) private String apiKey; @Value(&amp;#34;${payment.gateway.max-retries:3}&amp;#34;) private int maxRetries; } // @ConfigurationProperties — one place, typed, validated @Service public class PaymentService { private final PaymentProperties properties; // all config in one place, injected as a single object } @ConfigurationProperties gives you:</description></item></channel></rss>