Configuring the Application Context Path in Spring Boot
Fast recall
Quick revision
Core answer
servlet in the path. This applies at the servlet container level, so every request must include the prefix: a controller mapped to /users becomes /api/v1/users. It affects Actuator too — endpoints move under the prefix to /api/v1/actuator/health. To keep Actuator on a clean path, either run Actuator on a separate port with management.server.port=8081 (then management.endpoints.web.base-path is independent), or use management.endpoints.web.base-path to override only the Actuator base. The main alternative to server-level context paths is API Gateway path rewriting — keep context path at / and let the gateway route — which is cleaner for microservices with many services.Whether you know the exact property name, understand it applies at the servlet level (not `@RequestMapping`), and know how it interacts with Actuator
Writing `server.context-path` (the Boot 1 name); not realizing Actuator endpoints also shift under the context path; confusing it with controller-level base paths
Discuss when to use context paths vs API Gateway rewriting, and explain how `management.server.port` changes the Actuator path resolution
Interview-ready guide
Interview answer
The property
server.servlet.context-path=/api/v1- The
servletin the name matters — Boot 2 added the namespace to make room for WebFlux - Applies at servlet container level before Spring MVC sees the request
What shifts under the prefix
- Every controller endpoint —
/users→/api/v1/users - Actuator —
/actuator/health→/api/v1/actuator/health - Static resources too
Actuator — two ways to keep it on a clean path
1. Separate management port (preferred for prod)
management.server.port=8081- Actuator ignores the servlet context path entirely
- Management port can be bound to an internal-only interface — isolates probe traffic from user traffic
2. Same port, override Actuator base path
management.endpoints.web.base-path=/actuator- Still relative to context path — not a full escape
API versioning — context path is no longer the standard
- Microservices prefer API Gateway rewriting — gateway strips
/api/v1/, service runs at/ - Versioning handled uniformly at the edge, not embedded in deployment config
Generating absolute URLs (emails, webhooks)
ServletUriComponentsBuilder.fromCurrentContextPath()— respects scheme, host, port, and context path from the current request
Configuring the Application Context Path in Spring Boot
Direct Answer
Set server.servlet.context-path=/api/v1 — note the servlet in the path. This applies at the servlet container level, so every request must include the prefix: a controller mapped to /users becomes /api/v1/users. It affects Actuator too — endpoints move under the prefix to /api/v1/actuator/health. To keep Actuator on a clean path, either run Actuator on a separate port with management.server.port=8081 (then management.endpoints.web.base-path is independent), or use management.endpoints.web.base-path to override only the Actuator base. The main alternative to server-level context paths is API Gateway path rewriting — keep context path at / and let the gateway route — which is cleaner for microservices with many services.
Common Mistakes & Pitfalls
Writing server.context-path (the Boot 1 name); not realizing Actuator endpoints also shift under the context path; confusing it with controller-level base paths
Check your understanding
Answer these without looking back at the article.
- What's the difference between `server.servlet.context-path` and `spring.mvc.servlet.path`?
- How do you configure a context path in a WebFlux (reactive) application?
- How does `management.server.port` on a different port affect observability with Micrometer?
- Can you have multiple context paths in a single Spring Boot application?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.