Eh. From an ops perspective there isn't much difference between an executable file that Golang statically compiled all dependencies into and embedded a file system into, and a WAR archive that the Java compiler embedded a file system including dependencies into.

Both are self-contained single files you can give to a completely different organization and expect to run on the first attempt with no complications.

It's just that the latter needs Tomcat (not an issue, realistically) and has to be written as EnterpriseFactoryPatternFactorySingletonAbstractBaseFactorySingletonProvider that makes you feel dead inside just from looking at the documentation; while Golang (and similar newer languages) give you a lot more flexibility and better ergonomics on the developer side.

Try Guava or Spring. In either case the framework supplies you with a

   Factory, FactoryFactory, FactoryFactoryFactory, ...

that does the transitive closure so you can just get a "single" object injected into your app where you need it.

"lasciate ogne speranza, voi ch'intrate" (~ lose all hope, who enters) from Dante's Inferno is what comes to mind whenever someone mentions Spring.

You still need a bespoke systemd configuration for TFA's Go deploys so it's not really a "single file" deploy their either.

And like the sibling comment noted, once you're allowed to set up the machine to support easy depolyment (e.g. JRE, Tomcat), a WAR becomes a single file deploy.

You can use JLink to embed only the needed modules and classes of the JRE for your application to run