skip to content

What backends can a Config Server use to store configuration, and how do you configure git vs native?

level: middleimportance: should knowfreq 58%

answer

  1. backend = an EnvironmentRepository impl
  2. git = default, JGit, versioned, git.uri
  3. native = classpath/file, no versioning, 'native' profile
  4. vault = secrets; jdbc/redis also exist
  5. composite = ordered list of multiple backends

basics

~10 s

Common backends are git (default, versioned), native (files on the classpath or filesystem, handy for local dev), and Vault (secrets). Git needs spring.cloud.config.server.git.uri; native is enabled with the 'native' profile and search-locations.

solid answer

~40 s

The Config Server reads config from a pluggable EnvironmentRepository backend. Git is the default and most common: set spring.cloud.config.server.git.uri to a repo, plus optional searchPaths, default-label, and credentials; JGit clones the repo and checks out the requested label per request. The native backend serves from the classpath or filesystem — enabled by activating the 'native' Spring profile on the server and setting spring.cloud.config.server.native.search-locations (file:, classpath:); it has no versioning, so it's mainly for local dev and tests. Vault (spring.profiles.active=vault) reads secrets from HashiCorp Vault. There are also jdbc and redis backends. You can combine several with the composite configuration, listing repositories under spring.cloud.config.server.composite so one server draws from, say, git plus Vault. Each backend still answers the same /{application}/{profile}/{label} contract.

code

java · 33 lines
java
// --- Git backend (production default) ---
// application.yml
// spring:
//   cloud:
//     config:
//       server:
//         git:
//           uri: [email protected]:acme/config-repo.git
//           default-label: main
//           search-paths: '{application}'   # per-app subfolders
//           clone-on-start: true

// --- Native backend (local dev) ---
// spring:
//   profiles:
//     active: native
//   cloud:
//     config:
//       server:
//         native:
//           search-locations: file:./config-repo

// --- Composite: git + vault ---
// spring:
//   cloud:
//     config:
//       server:
//         composite:
//           - type: git
//             uri: https://github.com/acme/config-repo
//           - type: vault
//             host: vault.internal
//             port: 8200

go deeper

for a junior

Know git is the default and native serves local files; git needs a uri.

for a middle

Configure both git (uri, search-paths, default-label) and native (native profile + search-locations); know Vault exists for secrets.

for a senior

Explain each backend is an EnvironmentRepository, the composite option, and the versioning/auditability tradeoffs.

for a principal

Design a backend topology (git for config, Vault for secrets, composite ordering), and account for auth, HA, and accidental-native-in-prod risks.

**Backend = EnvironmentRepository.** Every backend is an implementation of the `EnvironmentRepository` interface. `@EnableConfigServer` picks one based on your properties/active profiles. The client contract (`/{application}/{profile}/{label}`) is identical regardless of backend. **Git (default, JGit).** - Enabled by `spring.cloud.config.server.git.uri` (http(s), ssh, or a local `file:` URI). - Backed by `JGitEnvironmentRepository`. On each request it ensures a local clone exists, fetches, checks out the requested `{label}` (branch/tag/commit), and reads the matching files. - Useful knobs: `search-paths` (subdirectories to scan, supports `{application}` placeholders), `default-label`, `clone-on-start`, `force-pull`, `timeout`, and auth (`username`/`password`, `private-key`, `host-key`). - Strength: full version history, branching per environment, PR-based change control. This is the production default. **Native (filesystem/classpath).** - Backed by `NativeEnvironmentRepository`. Activated by running the server with the `native` Spring profile (`spring.profiles.active=native`). - Set `spring.cloud.config.server.native.search-locations`, e.g. `file:./config-repo`, `classpath:/config/`, or a `${user.home}` path. - No git, so **no versioning or labels in the git sense** — great for local development, demos, and integration tests, poor for auditability. Beware serving from the classpath of the server jar (values get baked in at build time). **Vault.** - `spring.profiles.active=vault`, plus host/port/scheme/token. Backed by `VaultEnvironmentRepository`. Designed for secrets; keys live under a Vault path per application. **Others.** `JdbcEnvironmentRepository` (a `PROPERTIES` table), `RedisEnvironmentRepository`, and AWS/Consul/etc. via community modules. **Composite backends.** You can serve from multiple sources at once by configuring `spring.cloud.config.server.composite` as an ordered list, each with its own `type` and settings (e.g. a git repo for general config plus Vault for secrets). Results are aggregated into one `Environment`; order in the list drives precedence. When you use composite you must give each entry a `type` and, importantly, you cannot also use the top-level single-repo shorthand for those. **Choosing.** - Local dev / tests → native. - Production, shared, audited config → git. - Secrets → Vault (often composed with git). **Gotchas.** - Activating `native` accidentally in production silently switches you off git. - The native classpath location bakes files into the jar; prefer a `file:` location you can change without rebuilding. - Git auth for private repos is a frequent stumbling block (host-key verification, token vs ssh key).

  • Why is the native backend discouraged for production?
    It reads from the filesystem/classpath with no git versioning, history, or branch-based labels, so you lose auditability and rollback; classpath locations even bake values into the server jar at build time.
  • How would you serve general config from git but secrets from Vault on one server?
    Use the composite backend: configure spring.cloud.config.server.composite as an ordered list with a git entry and a vault entry; the server aggregates both into one Environment response.

saying these in an interview costs you the question

  • Thinking native supports git-style labels/versioning.
  • Assuming only git is possible.
  • Not realizing composite lets multiple backends coexist.

context

resolving links…