I just made a proof of concept of xdebug on the hypernode dev plans, but it looks like this won't be feasible.

I compiled the php-xdebug plugin for our PHP setup, that all worked fine. By setting the connection details to localhost like so:

xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9005

and then reverse tunneling the PHPstorm xdebug port to the Hypernode with ssh -R 127.0.0.1:9005:127.0.0.1:9005 I was able to get debug data.

But it turns out you can break our monitoring with this because we monitor the server through the PHP stack to make sure someone gets beeped when a server is not able to host a Magento shop for any reason. Our monitoring wouldn't be able to differentiate between people setting breakpoints on all first lines and servers actually timing out.

So we won't be supporting XDebug at this point in time on production/dev Hypernodes. If you want to use Xdebug you can use the Vagrant box (https://github.com/ByteInternet/hypernode-vagrant) and virtualize a Hypernode on your local machine. Or you can use another profiler/debugger like NewRelic or Blackfire. https://support.hypernode.com/knowledgebase/profiling-magento-blackfire/

I'm currently looking into cloud-based development on a development Hypernode. Would love to see options which give me access with xdebug!

Xdebug slows down the environment and adds lots of complexity, so it is not recommended to use this in production environments. It would be better to load this into Vagrant.

This'll only be useful if php's memory_limit is adjustable. In the cases where you have a reproducible scenario, you can also pull the site locally if the site owner consents to it. In cases where there is no scenario (yet), xdebug is no help, but New Relic Pro is.
I would much prefer to be able to select a debug backend for php-fpm. This backend would have no opcode cache of any sort, larger memory_limit, xdebug, strict mode and whatever else people can think of, without any impact on "production performance".

Instead of /etc/nginx/php-handler.conf you'd then include /etc/nginx/php-debug-handler.conf. Seems like the simplest solution for all cases.