Sometimes it takes something really tangible to look at to see the implications. I'm sorry that this is one of those.
We've only looked at Heroku and docker to empower third-party deployments, and docker is already on the back-burner.
Adding native linux deployments is an extension of scope, even more so if it's a matrix of supported versions that are hard to test locally. There's also a ton of subtle changes in OSes that could trigger errors.
Pontoon's development also implies that there's at least four services running (web, db, sync, memcached), which limits the impact a single-machine-install can have.
I checked in with Matjaz, and we agreed that the Pontoon project can't lift the support for a third deployment mechanism.
The exercise here was useful, as it helped us to find problems we'll face when upgrading PostgresQL. That's a good thing, thanks for that.
Accordingly, I'm closing this bug as WONTFIX.
I did spin my head in a few ways. One thing we could've done is going for a native package, and do docker and heroku via installing that package. Sadly, that requires a package registry and build automation dependencies, and that's not something I'd be up to setting up. FTR, GH registry doesn't do linux packages to begin with.
I wonder if snaps would be a way for someone to build packages to install on bare metal. Snaps would take care of a lot of the matrix of dependencies. But I have no idea of services in snaps are a thing to begin with. I stopped that train of thought quickly, too.