How do I create beans programmatically in Spring Boot?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Spring Boot usually creates beans from annotations and configuration classes, but some applications need runtime-driven registration. Examples include plugin systems, tenant-specific services, and feature-flagged integrations. Programmatic registration is powerful when you need dynamic behavior, as long as registration happens at the correct phase of application startup.
When Programmatic Registration Makes Sense
Use programmatic registration when bean set is not fully known at compile time.
Common scenarios:
- Load a provider implementation based on external configuration.
- Register one bean per tenant from database metadata.
- Enable optional adapters only when a license key is present.
If beans are static and predictable, regular @Configuration plus @Bean is simpler and easier to maintain.
Option 1: Register with GenericApplicationContext
For straightforward runtime registration, inject GenericApplicationContext and call registerBean.
This approach is easy to read, but it may be too late for beans that must exist before auto-wiring of other startup components.
Option 2: Early Registration with BeanDefinitionRegistryPostProcessor
If other beans depend on dynamic bean definitions during context refresh, register in a registry post-processor.
This guarantees bean definition is available early in lifecycle.
Option 3: Conditional Dynamic Registration
Many teams combine environment checks with registration. Keep conditions centralized so startup behavior is predictable.
In production code, replace raw environment reads with Environment or ConfigurationProperties for better testability.
Wiring and Retrieval Patterns
After registration, you can consume dynamic beans by name or type.
Prefer typed retrieval where possible. Name-based access is useful for plugin-style registries but should be documented clearly.
Testing Programmatic Bean Registration
Context tests should verify both positive and negative conditions.
For condition-driven registration, add separate tests with different property sets to prevent regressions.
Common Pitfalls
- Registering dynamic beans too late in startup. Fix by using registry post-processor when early availability is required.
- Spreading condition logic across many classes. Fix by centralizing registration rules.
- Using string bean names without conventions. Fix by defining clear naming strategy and ownership.
- Ignoring lifecycle implications for dynamic beans. Fix by documenting scope, initialization, and destruction behavior.
- Skipping tests for disabled conditions. Fix by adding negative-path context tests.
Summary
- Programmatic bean registration is useful for runtime-driven application composition.
- '
GenericApplicationContextis simple for direct registration.' - Registry post-processors are better for early dependency-sensitive registration.
- Keep condition logic explicit, deterministic, and test-covered.
- Treat bean names and lifecycle as contracts, not ad hoc implementation details.

