You finally have a Java web app that just works. Then you decide to deploy Jetty on Ubuntu and somehow, everything feels one config file away from magic or misery. Let’s make it the first one.
Jetty is the lean, embeddable HTTP server that powers countless JVM-based services. Ubuntu is the dependable workhorse of cloud environments. Together they form a minimal, fast, repeatable setup for hosting lightweight web applications without the overhead of full-blown containers. But only if you understand how Jetty fits Ubuntu’s service model, file structure, and security defaults.
In Ubuntu, Jetty runs best as a dedicated system service with clear separation between app logic and runtime configuration. Think of it as a polite roommate who keeps his jar files tidy in /usr/share/jetty and stays out of your working directory. The key lies in controlling identity: who runs it, what ports it binds to, and which configs it loads on boot. Properly tuned, you get frictionless restarts, transparent logging, and no mysterious permission fights with systemd.
A good integration workflow starts simple. Use Ubuntu’s prebuilt Jetty packages to get a clean directory layout. Drop your web app as a WAR into /var/lib/jetty/webapps/. Then configure jetty.base and jetty.home for environment-specific settings. Keep secrets in environment variables or external vaults instead of XML configs. Automate deployments with apt hooks or CI/CD runners. Map authentication with OIDC or SAML providers like Okta using Jetty modules, wiring your identity provider to enforce access policies from first request.
If you hit snags—Jetty not starting, 403 errors, or logs nowhere to be found—start with systemctl. It reveals permission mismatches faster than any Stack Overflow post. Use Ubuntu’s journalctl -u jetty for logs, match SSL certificates to the right keystore path, and rotate them frequently. Remember, SSL trust stores age faster than you think.