Ten years ago, deploying a Java application meant dropping a WAR file into a Tomcat or JBoss instance running on a dedicated server. The application server managed everything — classloading, connection pooling, transaction coordination, session state. You configured it once, deployed to it repeatedly, and hoped it didn't run out of PermGen space overnight.
That model worked when applications lived on a handful of servers with predictable traffic. It doesn't work when your application needs to scale from zero to fifty instances in seconds, run in ephemeral containers, or cold-start inside a serverless function. The Java server landscape has shifted fundamentally — not because the old servers were bad, but because the deployment targets changed underneath them.
This article traces that evolution and helps you understand which approach fits your situation. If you're looking for a direct head-to-head comparison of specific servers with benchmarks and deployment examples, see our Java application server comparison guide. For a parallel look at how the Ruby ecosystem has evolved — from Passenger and Puma to modern alternatives — see our Ruby application servers guide.
What Changed: From Servers to Runtimes
The traditional Java application server model assumed a clear separation between the server (infrastructure) and the application (your code). You built a WAR or EAR file, deployed it to a running server, and the server provided services — JNDI lookups, managed data sources, transaction managers, JMS queues.
This separation made sense when servers were expensive, long-lived machines. You ran one Tomcat or WildFly instance and deployed multiple applications to it. The server was shared infrastructure.
Three shifts broke this model:
Containers made servers disposable. When your deployment target is a Docker container that lives for hours or minutes, the idea of a shared application server
stops making sense. Each container runs one application. The server becomes an implementation detail inside the container, not a piece of shared infrastructure you manage separately.
Kubernetes changed what scaling
means. Traditional scaling meant adding capacity to your application server — more threads, more memory, bigger heap. Kubernetes scaling means launching more pods. A server that takes 30 seconds to start becomes a bottleneck when your horizontal pod autoscaler needs to respond to a traffic spike in seconds.
Microservices changed what an application
means. When a single business feature might span five services, each running in its own container, the overhead of a full Jakarta EE server per service is wasteful. You don't need JMS, EJBs, and distributed transactions in a service that just validates email addresses.
The Traditional Tier: Still Running in Production
Despite the cloud-native hype, traditional servers still run a significant share of production Java workloads. Understanding them matters even if you're building something new — because you'll likely need to integrate with systems that use them.
Apache Tomcat
Tomcat implements the Jakarta Servlet, JSP, and WebSocket specifications. Nothing more, nothing less. That constraint is its greatest strength — there's very little in Tomcat that can surprise you.
A typical Tomcat deployment starts in 2–4 seconds and uses 150–250 MB of memory. The thread-per-request model handles moderate concurrency well, and the server.xml configuration format hasn't changed substantially in over a decade. Every Java developer on your team has used it.
The limitation is exactly what's missing: if you need dependency injection, ORM, messaging, or reactive support, you're bringing those libraries yourself. That's fine for a REST API backed by Spring, but it means your application's dependency tree — not the server — determines your operational complexity.
WildFly
WildFly provides the full Jakarta EE 10 platform. When your application uses EJBs, JMS, JTA distributed transactions, or CDI, WildFly provides all of those as managed services. The modular classloading system (JBoss Modules) means unused subsystems don't consume resources.
The operational trade-off is real: WildFly uses 500–700 MB of memory at baseline, standalone.xml configuration can run to thousands of lines, and troubleshooting requires understanding the subsystem architecture. But for applications that genuinely need enterprise services — financial transaction processing, message-driven architectures, applications with complex security domains — WildFly provides them without your application having to manage those concerns.
WildFly also offers domain mode for managing clusters of instances from a single management point, and built-in HA clustering with session replication through Infinispan. These capabilities matter for organisations that need high availability without adopting Kubernetes.
The Transition Layer: Embedded Servers
The first break from the traditional model came when frameworks started embedding the server inside the application, rather than deploying the application to a server. This inverted the relationship — the application owns its runtime.
Spring Boot
Spring Boot popularised the fat JAR model: your application bundles Tomcat (or Jetty, or Undertow) as a dependency, and java -jar app.jar is your entire deployment command. There's no separate server to install, configure, or manage.
This model solved a real problem that every Java team had experienced: it works on my machine
deployment failures caused by differences between the developer's Tomcat and the production Tomcat. When the application carries its own server, the development and production runtimes are identical.
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
Spring Boot's auto-configuration means that adding spring-boot-starter-data-jpa to your dependencies automatically configures a connection pool, entity manager, and transaction manager. You get Jakarta EE-like managed services without a Jakarta EE server — the Spring framework provides them instead.
The trade-off is startup time and memory. A non-trivial Spring Boot application takes 5–15 seconds to start and uses 200–500 MB of memory. Most of that time is spent on component scanning, auto-configuration, and dependency injection wiring — work that happens at runtime because Java's reflection-based DI frameworks can't do it any earlier.
The Cloud-Native Tier: Built for Containers
The cloud-native frameworks asked a fundamental question: if the deployment target is always a container, and containers are always disposable, what changes if we optimise for startup time and memory density instead of long-running throughput?
Quarkus
Quarkus answered that question by moving work from runtime to build time. Dependency injection, configuration parsing, and ORM metadata processing all happen during compilation. The result is an application that starts in 1–2 seconds on the JVM, or under 50 milliseconds as a GraalVM native binary.
@Path("/api/orders")
@ApplicationScoped
public class OrderResource {
@Inject
OrderService orderService;
@GET
public List<Order> list() {
return orderService.listActive();
}
}
The code looks similar to Spring or Jakarta EE — that's intentional. Quarkus uses CDI for dependency injection, JAX-RS for REST endpoints, and Hibernate for persistence. The developer experience is familiar; the runtime behaviour is radically different.
The catch is GraalVM native compilation. It's slow (minutes, not seconds), breaks reflection-heavy libraries, and requires explicit configuration for any code that uses dynamic class loading. JVM mode avoids these issues but gives up the sub-second startup. Most production Quarkus deployments use JVM mode with native reserved for serverless or edge use cases where cold start time directly affects user experience.
The developer experience deserves special mention: quarkus dev provides live reload that rivals interpreted languages. Change a Java file, save it, and the next HTTP request runs the updated code — without restarting the application. This dramatically shortens the feedback loop during development.
Micronaut
Micronaut takes a similar approach to Quarkus — compile-time dependency injection and ahead-of-time processing — but with a different philosophy. Where Quarkus aligns with Jakarta EE and MicroProfile standards, Micronaut defines its own annotation model designed from the ground up for compile-time processing.
@Controller("/api/products")
public class ProductController {
private final ProductRepository repository;
public ProductController(ProductRepository repository) {
this.repository = repository;
}
@Get
public List<Product> list() {
return repository.findAll();
}
}
Micronaut's startup time (1–2 seconds JVM, sub-second native) and memory footprint (60–100 MB) are competitive with Quarkus. Its differentiator is the built-in support for multi-language applications — Micronaut runs on Groovy and Kotlin as first-class citizens alongside Java, and has native GraalVM support that's arguably more mature than Quarkus for certain workloads.
Where Micronaut falls short is ecosystem breadth. Quarkus has Red Hat's backing and a larger extension catalogue. Spring Boot has the largest community in the Java world. Micronaut, backed by Oracle's GraalVM team via Object Computing, has a smaller but dedicated community. If you need an obscure integration, Spring Boot or Quarkus are more likely to have it.
How Startup Time Actually Affects Deployments
The emphasis on startup time in cloud-native frameworks isn't about developer impatience — it's about operational characteristics that directly affect cost and reliability.
Kubernetes horizontal pod autoscaling adds pods when CPU or memory thresholds are exceeded. If your application takes 15 seconds to start, you need 15 seconds of overcapacity in your existing pods to absorb the traffic spike while new pods come online. With sub-second startup, the new pod is serving traffic almost immediately.
Serverless platforms (AWS Lambda, Azure Functions) cold-start your application on the first request after an idle period. A 10-second cold start means the first user after an idle period waits 10 seconds for a response. A 50ms native binary cold start is imperceptible.
Rolling deployments restart pods one at a time. With a 3-pod deployment and 15-second startup, you're running at 67% capacity for 15 seconds per pod — 45 seconds of degraded performance per deployment. With 2-second startup, the degraded window shrinks to 6 seconds total.
These differences compound as you move to microservices architectures. A system with 20 microservices, each restarting during a deployment, amplifies the startup penalty by 20x.
The Container Deployment Pattern
Regardless of which server or framework you choose, the deployment pattern for containerised Java applications follows the same structure:
# Build stage - compile and package
FROM eclipse-temurin:21-jdk AS build
WORKDIR /app
COPY . .
RUN ./mvnw clean package -DskipTests
# Runtime stage - minimal image
FROM eclipse-temurin:21-jre
COPY --from=build /app/target/app.jar /app.jar
# JVM tuning for containers
ENV JAVA_OPTS="-XX:+UseG1GC -XX:MaxRAMPercentage=75.0 -XX:+UseContainerSupport"
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app.jar"]
Two details matter here:
-XX:+UseContainerSupport (enabled by default since JDK 10) tells the JVM to respect container memory limits rather than reading the host's total memory. Without this, a JVM in a container with a 512 MB limit might try to allocate a 4 GB heap based on the host's physical memory.
-XX:MaxRAMPercentage=75.0 sets the heap to 75% of the container's memory limit, leaving 25% for the JVM's own overhead (metaspace, thread stacks, native memory). The exact percentage depends on your application — memory-intensive applications may need a lower percentage to avoid OOM kills.
Observability: The Non-Negotiable Requirement
Whichever server you choose, production Java applications need three observability pillars: metrics, traces, and logs. The good news is that OpenTelemetry has emerged as the standard across all servers and frameworks.
Spring Boot integrates via Micrometer and the OpenTelemetry Java agent. Spring Boot Actuator exposes a /actuator/prometheus endpoint out of the box when micrometer-registry-prometheus is on the classpath.
Quarkus has native OpenTelemetry support via the quarkus-opentelemetry extension. MicroProfile Metrics and Health are also available for simpler setups.
WildFly supports MicroProfile Metrics and Health through its MicroProfile subsystem, and OpenTelemetry via the Java agent.
The practical recommendation: use the OpenTelemetry Java agent regardless of your framework. It auto-instruments HTTP requests, database calls, and messaging without code changes, and works identically across all servers.
Making the Transition
If you're running traditional Java deployments and considering a move toward cloud-native, the transition doesn't have to be all-or-nothing:
Step 1: Containerise your existing deployment. Put your current Tomcat or WildFly deployment in a Docker container. This alone gives you reproducible builds, consistent environments, and the ability to run multiple versions side by side.
Step 2: Migrate to an embedded server model. Move from deploying WARs to a Tomcat instance to building fat JARs with Spring Boot. This eliminates the server management overhead without changing your application architecture.
Step 3: Evaluate cloud-native frameworks for new services. When you build your next microservice, try Quarkus or Micronaut. Don't rewrite existing applications — the risk/reward ratio rarely justifies it unless you have specific problems (memory density, cold start time) that cloud-native frameworks solve.
Step 4: Automate the deployment pipeline. Whether you're deploying WARs, fat JARs, or container images, automating the build-deploy cycle eliminates manual errors and makes deployments boring — which is exactly what you want.
Deploying Java Applications with DeployHQ
DeployHQ supports Java deployments across the entire spectrum described in this article. The build pipeline includes OpenJDK 8, 11, 17, and 21, plus Maven and Gradle, so your build commands run natively without Docker.
For traditional deployments, DeployHQ uploads your WAR or JAR to the server and runs post-deploy scripts to restart the application. For containerised deployments, the build pipeline produces the artifact, and a shell server deployment can trigger docker compose pull && docker compose up -d or kubectl rollout restart on your cluster.
The key advantage for Java teams is zero-downtime deployments. Java's relatively slow startup makes zero-downtime critical — without it, every deployment means a visible outage window while the new version starts. DeployHQ's atomic deployments with symlink swaps eliminate that window entirely for file-based deployments.
Ready to automate your Java deployments? Sign up for DeployHQ and connect your Git repository — you can be deploying in under five minutes, whether you're running Tomcat WARs or Quarkus native binaries.
Questions about Java deployment strategies? Reach out at support@deployhq.com or find us on Twitter/X.