🍃 Spring Boot Config Generator

Generate Spring Boot configs
instantly — all profiles, all tools

.properties / YAML · Dev + Staging + Prod profiles · Maven + Gradle · Docker Compose · ENV vars table

Quick Presets
Spring Boot
Build Tool
📄 application.properties
# Base configuration

server.port=8080

About Spring Boot Config Generator

Spring Boot uses application.properties or application.yml files to externalise configuration — database URLs, server ports, logging levels, security settings, caching, and more. Managing these files manually across multiple environments (dev, staging, production) leads to inconsistencies and errors. This generator creates ready-to-use Spring Boot configuration files for common components with best-practice defaults, and generates the corresponding environment variable mappings for Kubernetes, Docker, and ECS deployments.

Select the components your application uses — JPA, Redis, Kafka, security, logging, and others — fill in the values, and get a complete, well-structured application.yml with per-profile variants (base, dev, staging, prod) plus a table of environment variables that override each property at deployment time.

Features

🌱 application.yml

Generates clean, well-commented YAML with proper Spring Boot property hierarchy and profile-specific overrides.

📄 application.properties

Also outputs flat .properties format for teams that prefer it or are using older Spring Boot versions.

🔧 Multi-profile

Generates separate config sections for base, dev, staging, and production with appropriate defaults for each environment.

🌍 Env var mapping

Shows the SCREAMING_SNAKE_CASE environment variable that overrides each property — ready to paste into Docker, Kubernetes, or ECS configs.

☕ Common components

Covers JPA/Hibernate, DataSource, Redis, Kafka, RabbitMQ, logging, server, security, actuator, and more.

📋 Copy & Download

Copy the generated config or download it as a file ready to drop into your Spring Boot project's resources folder.

Frequently Asked Questions

When should I use application.yml vs application.properties?

Both formats are functionally equivalent in Spring Boot. YAML is preferred for hierarchical configurations because nested properties are represented as indented blocks rather than dot-separated keys — making complex configs like JPA settings and Kafka producer/consumer configurations much more readable. Use .properties if your team prefers it or if you are using a framework that does not support YAML.

How do Spring Boot profiles work?

Spring Boot profiles let you maintain environment-specific configuration. The application.yml (or application.properties) file is always loaded first as the base. Files named application-dev.yml, application-staging.yml, and application-prod.yml are then loaded and merged, with the profile-specific values overriding the base. Activate a profile with the SPRING_PROFILES_ACTIVE environment variable.

How do environment variables override application.properties?

Spring Boot automatically maps environment variables to properties using a relaxed binding convention. A property named spring.datasource.url is overridden by the environment variable SPRING_DATASOURCE_URL. Dots and hyphens become underscores, and the whole name is uppercased. This allows you to keep sensitive values (passwords, API keys) out of your config files and inject them at deployment time.

How do I connect Spring Boot to a PostgreSQL database?

Set spring.datasource.url=jdbc:postgresql://host:5432/dbname, spring.datasource.username=user, spring.datasource.password=password, and spring.datasource.driver-class-name=org.postgresql.Driver. Add spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect. Add the postgresql JDBC driver to your pom.xml or build.gradle.

What is the difference between spring.jpa.hibernate.ddl-auto create, update, and validate?

create drops and recreates the schema on startup (development only). create-drop is like create but also drops on shutdown. update applies only the changes needed (risky in production — use migration tools like Flyway instead). validate checks that the schema matches your entities but makes no changes (recommended for production). none disables automatic schema management entirely.

Developer guide

Complete guide to Spring Boot configuration generation

Spring Boot's convention-over-configuration approach handles most defaults automatically, but production-grade applications require explicit configuration for database connection pools, security rules, caching layers, messaging systems, observability endpoints, and deployment environment differences. Managing these configurations across multiple environments — development, staging, and production — is one of the more tedious parts of setting up a new service.

Braxik's Spring Boot Config Generator produces ready-to-use application.properties or YAML configuration across four profiles (base, dev, staging, production) in a single step. You select the features your application needs — database type, ORM settings, security headers, Actuator endpoints, Redis or Caffeine caching, Kafka or RabbitMQ messaging, mail provider, file upload limits — and the tool generates the correct property keys for your chosen Spring Boot version.

The generator also produces matching Maven pom.xml dependency snippets, Gradle build.gradle dependencies, a Docker Compose file for local development with all selected services wired up, and an ENV vars reference table showing which properties are best externalised as environment variables in a Kubernetes or Dockerised deployment.

Spring Boot 2.x and Spring Boot 3.x have significant differences in property namespaces — for example, data source auto-configuration keys moved from spring.redis.* to spring.data.redis.* in Spring Boot 3, and the spring.security.* prefix expanded. The generator accounts for these differences automatically based on the version you select.

How it works

The generator builds four configuration profiles from a single set of options. The base profile contains settings common to all environments: application name, server port, JPA dialect and DDL mode, datasource driver class, connection pool minimums, and feature flags that do not vary by environment. The dev profile extends the base with relaxed settings: H2 console enabled, SQL logging, DEBUG log levels, and permissive CORS for local frontends. The staging profile mirrors production structure but with lower connection pool sizes and INFO log levels. The production profile includes the strictest settings: no debug logging, tighter pool limits, and properties designed to be overridden by environment variables at runtime.

For Spring Boot 2.x applications, the generator uses the pre-Boot-3 property namespaces (spring.redis, spring.datasource.hikari prefix conventions, spring.security.user for dev credentials). For Spring Boot 3.x, it switches to the updated namespaces (spring.data.redis, updated actuator endpoint paths, Jakarta EE imports in Gradle/Maven comments).

The Docker Compose output creates service definitions for the selected database, Redis, Kafka with ZooKeeper, RabbitMQ, or mail relay (MailHog) with ports, environment variables, and a shared network — matching the connection parameters in the generated dev profile so no manual coordination is needed.

The ENV vars table shows every property that should be externalised rather than hardcoded: database passwords, Redis auth tokens, JWT secrets, SMTP credentials, Kafka broker addresses, and Actuator auth passwords. Each row shows the property key, a suggested environment variable name, and a description of what it controls.

Common uses

  • Bootstrap a new Spring Boot microservice with production-safe defaults across dev, staging, and production profiles in under two minutes.
  • Generate HikariCP connection pool settings tuned for your database type and expected load without digging through documentation.
  • Set up Spring Security with CORS, CSRF, and session management configuration that matches your deployment model (stateless JWT, session-based, or OAuth2 resource server).
  • Configure Spring Boot Actuator with the right endpoints exposed, secured, and mapped for integration with Prometheus, Grafana, or AWS CloudWatch.
  • Generate a local Docker Compose file that mirrors production infrastructure for reliable local development without manual docker run commands.
  • Produce a complete Kafka consumer or producer configuration including consumer group ID, auto-offset reset policy, and dead letter topic settings.
  • Switch between Spring Boot 2.x and 3.x property namespaces without manually consulting migration guides.
  • Build a reference ENV vars table for your DevOps team showing which application.properties values need to be provided as Kubernetes Secrets or AWS Parameter Store entries.

Before you rely on the result

  • Review generated datasource URLs and adjust the database host, port, and schema name before using in any environment. The generator uses placeholder values (localhost, 5432, mydb) that must be replaced with your actual infrastructure.
  • Never commit production passwords, JWT secrets, or API keys — the generator shows placeholders like CHANGE_ME in the ENV vars table. Replace these with references to your secrets manager (AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets) before deploying.
  • For Spring Boot 3.x with Spring Security, the security auto-configuration changed significantly. Review the generated security configuration against the Spring Security 6.x migration guide if you are upgrading from a Boot 2.x application.
  • HikariCP pool sizes depend on your database server's max_connections setting and the number of application instances. The defaults are conservative — tune them based on your observed connection usage in production, not the generated values.
  • The generated Kafka configuration uses earliest as the auto-offset-reset policy for consumers, which is safe for new consumer groups but may reprocess all historical messages if applied to an existing group. Review this setting carefully.
  • Spring Boot Actuator endpoints are secured by default in the generated config using a separate management port and basic auth. Confirm that your load balancer or ingress does not expose the management port to the public internet.
  • Test the generated Docker Compose file locally before committing it to your repository — image versions pinned in the output may need to be updated to match your team's baseline or to address known vulnerabilities.