HTTP-Endpoint starting, even when its not configured in appsettings.json (Version 2026.2.0)

@markusburkhardt Hey Markus. This has to do with the Devolutions login callback functionality. It does seem like a timing issue where both services are selecting the same port and then trying to bind to it. We select a port in the range, starting with 60370, and increasing from there to find an open port within the range. If two PSU instances start at the exact same time, a conflict could happen.

You can also work around this by specifying the PSULoginPort value in appsettings.json.

Here is some more information about it.
Licensing | PowerShell Universal

That said, I've opened an issue to track this because we should both be more resilient and also allow for disabling the port all together.

@Adam Driscoll
Hello Adam,

first of all, thanks for the quick response and the great explanation. I took your solution approach and changed my appsettings.json for both instances accordingly. My port-conflict on server startup ist now resolved. One thing i noticed is though that the callback-ports for the Devolutions login are not running on the loopback address 127.0.0.1 or its IPv6-equivalent ::1. Is this behavior intended? I checked that with the following command (you may need to change the filter in the "where"-clause).

Get-NetTCPConnection -State Listen | Select-Object @{name = 'Server'; expression = { $env:ComputerName } }, LocalAddress, LocalPort, OwningProcess, @{name = 'Commandline'; expression = { (Get-Process -Id $_.OwningProcess).Commandline } } | Where-Object {$_.CommandLine -like "D:\*"} | Format-Table

Thats the output from my server. Port 60370 and 60371 are the configured "PSULoginPort"-ports.

Server  LocalAddress LocalPort OwningProcess Commandline
------  ------------ --------- ------------- -----------
S107123 ::               60371          4028 D:\psu_test\app\Universal.Server.exe
S107123 ::               60370          4016 D:\psu_prod\app\Universal.Server.exe
S107123 ::1              49882          4028 D:\psu_test\app\Universal.Server.exe
S107123 ::1              49812          4028 D:\psu_test\app\Universal.Server.exe
S107123 ::1              49810          4016 D:\psu_prod\app\Universal.Server.exe
S107123 ::                8443          4028 D:\psu_test\app\Universal.Server.exe
S107123 ::                 443          4016 D:\psu_prod\app\Universal.Server.exe
S107123 127.0.0.1        49882          4028 D:\psu_test\app\Universal.Server.exe
S107123 127.0.0.1        49812          4028 D:\psu_test\app\Universal.Server.exe
S107123 127.0.0.1        49810          4016 D:\psu_prod\app\Universal.Server.exe

Since the callback-ports are not whitelisted in the Windows Firewall, they are not reachable from the clientside, and PSU works totally fine. Is it probably no issue in my use case, because we dont use the devolutions login?

Thanks in advance for the help.

Best regards,

Markus

@markusburkhardt It won't cause an issue in your case because you aren't using the Devolutions login. They aren't scoped to localhost to support hosting in a reverse proxy like Docker or IIS. If we were to do that, they would be inaccessible from outside the container and would fail to work. While we originally intended PSU Devolutions Login to only work on local machines, it was to restrictive to actually lock it down when it's very natural for someone to pull a Docker image and run a container in a development setting.