Switching JHipster Microservices to Monolith: Configuration Changes for Low‑Traffic Deployments

Goal: Migrate a JHipster-generated microservices stack (gateway, registry, and one or more services) to a monolithic deployment to lower infrastructure costs for a low‑traffic workload.

Constraints: The microservices version relies on separate Docker containers for the JHipster Registry and Gateway, each with its own JVM heap settings, and uses a shared database that may need to be re‑evaluated for tight coupling. The monolith generator produces a single application with its own Maven or Gradle build configuration, and the existing CI/CD pipelines are tuned for multi‑artifact builds.

Uncertainty: It is unclear which configuration files (application-*.yml, Dockerfiles, docker-compose.yml, pipeline scripts) must be removed or altered, how the build tool choice (Maven vs Gradle) influences resource usage after the switch, and what JVM memory settings are appropriate for the consolidated monolith without causing excessive GC pauses.

Which JHipster configuration artifacts (e.g., registry and gateway Docker Compose services, their application-*.yml files, and related CI/CD steps) should be deleted or repurposed when converting to a monolith?

How does the build tool selection (Maven or Gradle) affect the resource consumption and build time of the resulting monolith compared to the original microservices build?

What JVM heap (-Xmx) and GC tuning values provide a balance between low idle memory usage and acceptable pause times for the monolith under low‑traffic conditions?