Thanks for reporting this. The XOpenDisplay failed exception came from the Remote Debugger trying to initialise its graphical interface on a machine without a display.
I’ve now implemented headless Remote Debugger support, and it is scheduled for the next release. There is also a separate piece needed for the Web debugging workflow you describe, which I’ve explained below.
The same Remote Debugger download will support both graphical and headless operation. With the next release, you’ll be able to extract the Linux archive, open its directory and run:
"./Remote Debugger" --headless
That starts the debugger in the terminal without opening a window. It does not require a desktop environment, X11 or a virtual display. The published Linux executable also includes its .NET runtime, so a separate .NET installation is unnecessary.
The graphical and headless modes now share the same debugger server, keeping deployment, debugging, profiling and shutdown behaviour consistent.
By default, headless mode listens on 127.0.0.1:9740. For an SSH-accessible server, I recommend keeping that default and opening a tunnel from your development computer:
ssh -N -L 19740:127.0.0.1:9740 user@server
Then, in Objo Studio:
- Open Settings > Remote Targets.
- Add a target with Host
127.0.0.1 and Port 19740.
- Select that target under Solution > Run Remotely.
Keep the SSH tunnel open while debugging. Loopback listeners do not advertise themselves through automatic discovery, so this setup uses a manual target.
For a trusted local network, you can explicitly listen on the machine’s network interfaces and give it a discovery name:
"./Remote Debugger" --headless --bind 0.0.0.0 --name "Debian Debug Server"
The available options include:
--bind <address> to select an IPv4 or IPv6 address.--port <port> to change the default port.--name <name> to choose the discovery name.--no-discovery to disable automatic discovery.--help and --version, which also work without a graphical display.
The debugger accepts and runs application deployments, so I recommend the SSH tunnel for a server reached over an untrusted network. Its TCP connection is separate from your application’s HTTP or HTTPS address.
Headless mode writes startup, connection and application-host diagnostics to the terminal. Ctrl+C or SIGTERM stops the listener, terminates active application and Worker processes, and removes their temporary deployments. Headless command-line options also leave the graphical debugger’s saved settings alone.
I’ve tested the published debugger on Debian 12 without X11, Xvfb or an installed .NET runtime, as well as on another minimal Linux image, macOS and Windows. Testing included real VM and C# debugging sessions, breakpoints, stepping, locals, watches, arguments and profiling. I also exercised plugin and Worker deployments, failed startup, interrupted connections and process cleanup.
For your particular setup, remote Web application debugging is still a separate feature. This first change supports Command Line applications, their Workers and profiling. Desktop applications still need a graphical display on the target machine.
I’ve accepted Debug Web applications on remote servers to cover the workflow you described: deploying and debugging a Web application on the remote server, opening its public HTTPS address on your development computer, and retaining breakpoints, stepping, variable inspection, output and Stop behaviour through that setup.
The headless listener is implemented for the next release.