Embedded Tomcat vs Standalone Tomcat: Detailed Differences and Choosing the Right Approach
This article compares embedded Tomcat (bundled inside a Spring Boot executable JAR) with standalone Tomcat (installed separately), covering installation, packaging, resource usage, startup speed, management, version flexibility, feature set, pros and cons, and guidance on selecting the appropriate deployment model.
What Are Embedded and Standalone Tomcat?
Standalone Tomcat is the classic Java web server you download, install, configure, and then deploy WAR files into its webapps directory. The server runs independently and can host multiple applications simultaneously.
Embedded Tomcat is packaged as a JAR library and bundled directly into a Spring Boot application. The resulting executable JAR contains the Tomcat runtime, so the application can be started with java -jar app.jar without installing a separate server.
Core Differences (Plain Language)
Installation : Standalone Tomcat requires downloading, extracting, setting environment variables, and configuring ports. Embedded Tomcat needs only a Maven/Gradle dependency; the server is built into the JAR.
Packaging : Standalone uses WAR files placed in webapps. Embedded uses an executable JAR that already includes Tomcat.
Number of Projects per Instance : One standalone Tomcat can run many WARs (one‑to‑many). One embedded Tomcat runs a single project (one‑to‑one); multiple projects need separate JAR processes.
Resource Isolation : Standalone shares memory and thread pools across projects, offering higher utilization but risking whole‑process crashes. Embedded gives each project its own JVM and Tomcat instance, providing isolation at the cost of higher total memory usage.
Startup Speed : Standalone Tomcat starts slowly because it loads all deployed WARs. Embedded Tomcat starts quickly, loading only the current project—typically a few seconds.
Operations Management : Standalone allows centralized configuration and log handling, but a global change affects all apps. Embedded requires per‑project management; scaling many instances may need orchestration tools.
Version & Configuration Flexibility : All apps on a standalone server share the same Tomcat version and global config, making per‑app tuning difficult. Embedded lets each JAR use its own Tomcat version and configuration (e.g., application.yml).
Feature Completeness : Standalone includes admin UI, default welcome pages, and examples. Embedded is lightweight, keeping only core servlet processing; it still provides identical request handling and performance.
Pros and Cons Summary
Standalone Tomcat
✅ Centralized management, high resource utilization, mature and familiar.
❌ Complex deployment, shared failures, low flexibility, unsuitable for microservices or containerized environments.
Embedded Tomcat
✅ One‑command startup, process isolation, flexible per‑app configuration, ideal for microservices, Docker, and Kubernetes.
❌ Higher total memory consumption with many services, no built‑in unified admin UI, requires new operational practices.
When to Choose Which?
Choose Standalone Tomcat when
Running a few large monolithic applications on a single server.
Many small legacy apps need to share resources.
Existing infrastructure and team expertise are tied to the classic model.
Operations prefer centralized control of all web apps.
Choose Embedded Tomcat when
Developing Spring Boot / Spring Cloud microservices (the default).
Deploying to Docker or Kubernetes with elastic scaling.
Frequent deployments, rapid start/stop, or independent scaling per service.
Each service requires distinct configuration or Tomcat version.
Developers want a simple java -jar launch without a local Tomcat install.
Common Misconceptions Clarified
Embedded Tomcat is not a “cut‑down” version; core servlet capabilities are 100% identical.
All core parameters (port, thread pool, timeouts, etc.) are configurable via application.yml, often more conveniently than editing server.xml in standalone mode.
Tomcat is not the only embeddable container—Spring Boot also supports Jetty, Undertow, etc., by swapping the dependency.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
CTO Full-Stack Academy
15 years of IT industry experience, sharing practical insights on pre-sales, product design, architecture, technology development, software testing, project management, IT consulting, and operations management.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
