We might add proxy-over-ssh/vlan options later on, but it would be incompatible with the 2-clicks-and-your-done interface right now.
As far as I know, postgres authentication is rather simple and exposing the port does not easily add huge liability.
This is really a trade-off between ease-of-setup and better security. We're eager to talk to (a lot of) users to see what there current setup is and how PGBackup could add some value for them.
The comment caught me off guard as well. It seems as a customer you're placing a lot of trust in this company as you're replicating your data to them and then trusting that they will handle and store it securely.
Until then (or additionally) you could add a FAQ entry with your server IP range(s), so people can allow them in their firewall for the specific port (usually 5432).
Even if not concerned with security, it opens a pretty easy DOS window. Authentication happens after forking of a new backend. That's not exactly cheap...
Edit to add why: You'll have full reachability between pgbackup and your customer's servers without opening ports inbound on either side. Traffic is also encrypted :-)
For customers with stronger security concerns, they could issue your service a client cert and only allow replication connections from your service's IP range that auth with certificate.
As far as I know, postgres authentication is rather simple and exposing the port does not easily add huge liability.
This is really a trade-off between ease-of-setup and better security. We're eager to talk to (a lot of) users to see what there current setup is and how PGBackup could add some value for them.