Stop Using nohup java -jar: How to Keep a Spring Boot App Alive in Production

A Spring Boot process started with `nohup` will not survive a server reboot, a JVM crash, or a full disk from unrotated logs. The fix is a few lines in a systemd unit file — no extra software, no cost — and it turns a fragile dev habit into a service that restarts itself and logs properly.

Running a Spring Boot jar with `nohup java -jar &` leaves a production service without automatic restarts, log rotation, or startup-on-boot. When the server reboots, the process stays dead until someone manually revives it, and hunting for PIDs to restart or stop the app risks collateral damage. The core problem is that `nohup` only ignores the hangup signal; it was never designed to supervise a long-running daemon.

systemd, built into every modern Linux distribution, solves this with a simple unit file that defines the Java command, the runtime user, restart policy, and log output. For environments without root access, systemd's user mode works after an administrator enables lingering. Supervisor remains a fallback for older CentOS 6 systems or cross-language workloads, though it is being phased out on newer distributions. Docker plus Kubernetes shifts the responsibility to the orchestrator, which handles health checks, rolling updates, and horizontal scaling.

A production checklist rounds out the advice: never run as root, pin JVM heap and GC settings, externalize configuration, enable graceful shutdown with SIGTERM, rotate logs, and match the Java version to the Spring Boot release. The through-line is that a service that "just runs" in dev needs explicit supervision to survive a year of unattended operation.