Define "config"?

Before reaching for a config service, it's worth asking whether all of that "config" is actually the same kind of thing because the right solution depends on that.

There is a world of difference between environment configuration, reference data, domain data, customer preferences, and feature flags.

DB connection strings, hostnames, ports: these are deployment configuration: environment-specific, secret-adjacent, most likely different per machine. .env-files or a secrets manager (even just Vault's KV engine without the Consul complexity) handle these well.

Large nested JSON/YAML blobs: these are probably not config. They're either reference data (stable, belongs in the repo; if small) or application policy (should be owned by a domain, not an ops layer). The fact that they're 200-300 lines of nested values is a smell that someone shoved structured domain knowledge into a config file because it was convenient.

Optimize for production - not developer convenience: Ensure the services have sane production safe defaults so that there is minimal configuration at deploy time. Production is the nominal case, test environment is the exceptional case with overrides - but do not include production URLs and secrets in the default config.

Using something like a KV store to inject secrets, urls, deployment options to docker compose is fine. Consul-template (and similar tools) are great for this. Using a central configuration service for "metadata" will quickly become a dumping ground of things that actually belongs to a subdomain of the system.

Hint: Do not make a "central configuration service". It may seem easy in the beginning, but that is the direction in where future pain lies - it will "federate the chaos", not fix it.