Migrating from Amazon Services 3.x to 4.0.0

Previously, a parameter named /myapp/prod/db/url was exposed as myapp.prod.db.url, including when loaded through quarkus.ssm.config.path=/myapp/prod. Path selections now expose db.url by default. As with the other providers, selecting a remote location does not implicitly add that location to application property names.

Either update consumers to use the relative keys, or preserve the previous keys:

full remains supported. Alternatively, use an explicit prefix with relative naming:

Only relative path naming converts complete index segments such as _0_ to [0]. Explicit names and key-naming=full retain literal index segments and full normalized names.

For parameter /myapp/prod/servers/_0_/name, the exposed key depends on the selection:

Previously, AppConfig Data parsed non-JSON documents as Java properties, even when AWS returned a YAML content type. Automatic decoding now uses a YAML decoder for YAML documents, including application/x-yaml.

If the document is YAML, add io.quarkus:quarkus-config-yaml to your application. If it intentionally relies on the previous Java properties interpretation, preserve that interpretation explicitly:

An entry-specific format can override this default. Missing YAML support is a load failure, not a reason to silently reinterpret a document as another format.

Previously, enabling the ConfigSource without a secrets mapping listed all accessible secrets and loaded them under their names. Implicit listing is no longer supported. It made the loaded configuration depend on every accessible secret rather than an explicit selection.

Declare the required secrets and their target property prefixes:

For a JSON secret containing {"username":"app","password":"example"}, this exposes database.username and database.password. Choose the mapping prefix to match the keys your application expects. Named entries are also supported. Setting fail-on-missing-config=false does not restore discovery; an empty selection skips the source instead.

Configuration sources now fail startup by default if the selected configuration cannot be loaded completely, including missing resources, access failures and invalid content. Previously, failures could leave an application running with missing or partial remote configuration.

If the remote source is optional and local configuration is sufficient, opt out explicitly under the relevant service prefix:

This setting makes the entire source optional; it does not enable partial publication. If any selected resource fails during the initial load, none of that source’s remote properties are published. If polling is disabled, retry requires an application restart. To allow later recovery, configure polling explicitly, for example quarkus.ssm.config.update-interval=30S.

During polling, a failed refresh keeps the previous complete snapshot. Publication is atomic per provider, not across AWS services. This prevents publishing incompatible subsets of related configuration values.

Distinct selections in the same provider that expose the same property key are rejected rather than silently overwriting one another, even when the values match. Give them separate prefixes or remove the overlapping selections. This does not change precedence between separate ConfigSources.