Largely you probably want to use CLN. We have some instructions on how to deploy with CLN: https://vls.tech/docs/latest/get-started/cln-vls/ . We have the theoretical ability to connect to an LDK-based node, but we cannot connect with the "official server version" ldk-node project yet. We have a separate LDK-based project, lnrod, whose instructions for integration are: https://vls.tech/docs/latest/get-started/ldk-vls/ , and you can also dive deeper into the actual codebase if you are writing your own LDK-based node software for how to integrate it.
I suggest running at least one extra machine: a very secure machine, ideally domiciled by you and not hosted on cloud or remote rack, that will run VLS. I would suggest locking all incoming ports in the firewall for this machine (VLS actually "connects out" to the node, instead of being a server and waiting for the node to connect in) and disabling everything, including SSH on the machine (i.e. use the machine's console directly). The "connect out" gives a tiny security boost, in that you can actually lock out many possible attackers by simply completely disallowing incoming connections and only allowing outgoing to the very specific node software machine.
In addition to VLS itself, you need TXOO server, which you can probably run with the machine that runs bitcoind. CLN needs a bitcoind as well anyway.
As to overhead, additional network roundtrips will occur due to the node software having to call out to the VLS machine. How much impact this has will depend on your setup between the VLS machine and the node software.
Largely you probably want to use CLN. We have some instructions on how to deploy with CLN: https://vls.tech/docs/latest/get-started/cln-vls/ . We have the theoretical ability to connect to an LDK-based node, but we cannot connect with the "official server version"
ldk-nodeproject yet. We have a separate LDK-based project,lnrod, whose instructions for integration are: https://vls.tech/docs/latest/get-started/ldk-vls/ , and you can also dive deeper into the actual codebase if you are writing your own LDK-based node software for how to integrate it.I suggest running at least one extra machine: a very secure machine, ideally domiciled by you and not hosted on cloud or remote rack, that will run VLS. I would suggest locking all incoming ports in the firewall for this machine (VLS actually "connects out" to the node, instead of being a server and waiting for the node to connect in) and disabling everything, including SSH on the machine (i.e. use the machine's console directly). The "connect out" gives a tiny security boost, in that you can actually lock out many possible attackers by simply completely disallowing incoming connections and only allowing outgoing to the very specific node software machine.
In addition to VLS itself, you need TXOO server, which you can probably run with the machine that runs bitcoind. CLN needs a bitcoind as well anyway.
As to overhead, additional network roundtrips will occur due to the node software having to call out to the VLS machine. How much impact this has will depend on your setup between the VLS machine and the node software.