In practice
Not "it does everything" — these four things it does with less friction than what you have now.
Standing up a rack
Twenty new servers, fresh OS. The same steps on each: switch the package source, install dependencies, install the JDK, install middleware, set environment variables. Before, twenty terminals and twenty pastes. Now one application against twenty machines, each scrolling its own output.
Migrating to Kylin or UOS
Machines move from CentOS to a domestic distribution: the package manager changes, paths change. Treating Kylin and UOS as their own OS types means one application, two sets of commands dispatched automatically — not two runbooks to keep in sync.
Bulk source change on an isolated network
No internet in the data centre, so every machine must point at a local mirror. Editing sources.list or a repo file by hand across twenty machines guarantees one gets missed. Send it as a batch command, then spot-check a few in the file manager.
A 2 a.m. incident
If a phone can open a browser, that is enough: read the install record to find which machine failed and at which step, open the terminal, fix one line, restart the service. No trip to the office, no laptop.
One bulk install, start to finish
Five machines, from clicking the button to reading every result.
Build the application
Create an application named nginx with three blocks: refresh the source, install the package, start the service. Use $PACKAGE_INSTALL_COMMAND$ for the install step.
Select machines, install
Tick five machines in the left tree, choose install, pick nginx. Each machine opens its own console immediately.
Read results, keep records
Green for success, red for failure. Open the failing one for its full output and exit code. The record is already saved.
Your case is probably none of these four
Then install it and spend ten minutes. Keep it if it fits, delete it if not — single jar, no database, nothing left behind.