Not to put too fine a point on it: I would start by running an onion server on a dedicated machine in a network enclave behind NAT and with intentionally invalid hostnames, so that any/all metadata that might leak in (say) Apache headers, is mostly useless; the NAT-internal network would be 10.0.0.0/24, the hostname "invalid.invalid", etc...

It was thinking like this which led me to draft this (now slightly dated) document; but overall it still is useful: 

https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md 

The other benefit of putting your onion servers in a NAT enclave is that you can lock down your guards to a limited set and drill holes in your firewall specifically for those, and then ban all other outgoing traffic from your machine; this will help prevent identification via DNS lookups, package update checks, pingbacks in your CMS stack, etc. 

Then: work out for yourself how to do software updates via (say) a HTTP proxy + VPN.

    -a