New in xyOps 1.1.9: Real terminals, right in your browser

[jhuckaby]

New in xyOps 1.1.9: Real terminals, right in your browser

I'm really excited to share a new feature in xyOps 1.1.9: interactive server terminals! You can open a real terminal on your Linux, macOS, or Windows servers directly from the xyOps web interface, without installing an SSH server or opening any incoming ports on the remote machine.

This brings the command line right alongside your server monitoring, jobs, and workflows. When a server needs a closer look, you can move straight from its monitoring page into a shell.

One click from any server

As a full administrator, open an online server's page and click the new Open Terminal icon button in the Server Summary:

Your terminal opens in its own browser tab, leaving your dashboard or job details right where they were. A welcome banner identifies the server and shows its operating system, CPU, and memory, so you know exactly where you're working. You can open multiple terminals across your fleet, too.

A real PTY, with full interactive applications

This is a real pseudoterminal (PTY), with support for full terminal user interfaces. Run htop, edit a file in vim or nano, browse logs with less, or work in an interactive shell. Keyboard input, cursor movement, screen updates, and terminal resizing all travel between your browser and the remote process.

Here's htop running on a Linux server inside xyOps:

The terminal automatically fits your browser window, and resizing the window updates the remote PTY's dimensions so applications can adjust their layout.

It also supports full ANSI colors and styles, including 24-bit RGB true color. Colorful prompts, syntax highlighting, and terminal dashboards can look right at home:

Linux, macOS, and Windows

The same terminal interface works across all three platforms. On Linux and macOS, xySat selects an available shell such as Bash. On Windows, it uses native ConPTY support and prefers PowerShell, with a command processor fallback.

Here's a PowerShell session on Windows Server:

Cloud instances, Macs, Windows servers, and even Raspberry Pis can all be reached from the same place. Each server just needs a connected, terminal-capable version of xySat.

No incoming connections. No SSH required.

This is my favorite bit: the terminal does not open any new listening ports on the remote server, and there is no incoming connection to that server.

xySat already establishes an outbound, authenticated WebSocket connection to the xyOps conductor. Terminal input, output, and resize messages piggyback on that existing connection. Your browser connects to the conductor, which relays the terminal traffic to and from xySat.

flowchart LR
	Browser["Administrator's browser"] -->|"Authenticated WebSocket"| Conductor["xyOps conductor"]
	Server["Remote server running xySat"] -->|"Existing outbound WebSocket"| Conductor

Loading

The arrows show which side initiates each connection. Once connected, terminal traffic flows in both directions over those established sockets. The terminal reuses xySat's authentication and transport security, including TLS when the connection uses WSS.

That makes this especially useful for servers behind NAT, in private subnets, or under strict no inbound connections policies. Air-gapped deployments can use it entirely within their private network, provided xySat can reach an internal conductor. No public internet access is needed for the terminal session.

And yes, you can open a terminal on a server that doesn't even have SSH running. There are no SSH keys to distribute or separate SSH sessions to configure for this feature.

Sessions that survive a connection drop

The shell runs on the remote server, so temporary socket disconnections and conductor failovers do not automatically end your terminal session. The open browser tab can reconnect to the existing session and continue working.

Detached sessions have a cleanup grace period, which defaults to five minutes, so abandoned terminals don't accumulate forever. Output produced while the connection is down is not replayed when it returns.

The browser also asks for confirmation before you close a tab with an active terminal, helping prevent an accidental click from interrupting your work.

Administrator access and central controls

Only full xyOps administrators can use terminals. This is enforced by the conductor, including checks that terminal input belongs to the administrator who opened the session. By default, the shell runs as the operating system account running xySat, making this a powerful administration tool.

The System Status & Maintenance page now includes an Open Terminals table. See which administrator opened each terminal, its server, process ID, age, and last activity, all in one place:

The Kill Process menu lets you send signals such as SIGTERM, SIGINT, or SIGKILL on Linux and macOS. On Windows, the action uses PowerShell's process termination controls. You can manage a terminal's shell process even when its browser tab is no longer connected.

Make it your terminal

The emulator follows xyOps' light and dark themes and comes with 10,000 lines of scrollback by default. Its appearance and behavior are customizable through Terminal UI Settings in the configuration editor, using the client.xterm_defaults setting.

Adjust fonts, font size, line height, cursor style and blinking, scrollback, contrast, and colors. These settings are passed directly to the terminal emulator; the xterm.js options reference covers the available options.

A few things to try

• Investigate a failed job: Open a terminal on the server that ran it, inspect its files, and try a command interactively.
• Follow up on an alert: Go from a CPU or memory alert to htop on the affected machine.
• Check a service: Inspect configuration and follow a log while keeping the xyOps monitoring page open beside it.
• Work across operating systems: Keep a Linux shell and a Windows PowerShell session open in neighboring tabs.
• Reach a private worker: Troubleshoot a machine that accepts no inbound connections, using the xySat connection it already has.

To try it, update to xyOps 1.1.9 and xySat v1.1.7, sign in as a full administrator, and click Open Terminal on an online server. xySat 1.1.7 isn't technically required, but it includes the latest shell detection and startup error reporting improvements.

I'd love to hear if this feature is useful to you!

[nickdollimount]

Get out of my head! This is amazing 🙌

[mhuovinen]

Nice feature, really useful!
Is there going to be logging who has logged in to which server? Maybe even recording of session or some sort of audit trail?

[jhuckaby]

Transaction logging absolutely! That's coming in the next version. I mean, it's already logged now, but I will make it more visible, i.e. on the "Activity Log" page.

Session recording is a much more sensitive topic, because the user may type in passwords, echo secrets to the console, etc. It would have to be encrypted at rest. I'll have to put some thought to it. It's a much larger feature.