The browser-based terminal: why your team should never install PuTTY again

Two decades of the same tool

PuTTY was first released in 1999. It was a good tool then, and it remains a functional tool now. But the fact that significant portions of the industry's infrastructure team are still using software from 1999 — or its equivalents — as their primary server access tool says something uncomfortable about how slowly the tooling in this space has evolved. The SSH protocol itself dates from 1995. The way most engineers connect to servers today is fundamentally similar to how they connected in 2005.

This stasis exists for understandable reasons. SSH works. The protocol is well-understood, secure, and ubiquitous. The desktop clients that implement it are mature and stable. For individual, ad-hoc access to a handful of servers, they're entirely adequate. The friction of switching to something different doesn't justify the operational overhead if you're just connecting to one server to check a log file.

But modern infrastructure management is not that simple anymore. Teams manage dozens to hundreds of servers across multiple environments and regions. Multiple engineers need access to the same systems, with different permission levels, from different devices and locations. Compliance requirements demand audit trails of who accessed what and when, plus what they did during those sessions. AI assistance is becoming a practical tool for operational work. And the "each engineer maintains their own local SSH setup" model creates a fragmented, inconsistent, and hard-to-audit access landscape that doesn't match the requirements of a modern operations team.

The desktop SSH client problem

The core problem with desktop SSH clients in a team environment isn't the client software itself — it's the model of access management that desktop clients impose. When access lives on individual machines, the infrastructure team loses centralised visibility and control. Consider what this model implies in practice:

Each engineer maintains their own set of SSH keys or passwords for each server they access. These may or may not be stored securely. They may be backed up to personal cloud storage. They may have been shared with a colleague at some point for a "just this once" situation. When an engineer leaves the team, their access needs to be revoked at the server level — which means auditing which servers they had access to and removing their keys or changing the passwords. In a 50-server environment with 10 engineers, this is a non-trivial exercise that often gets done incompletely.

The "access from any device" problem is equally significant. Engineers work from laptops, take those laptops home, sometimes work from personal machines, occasionally connect from coffee shops or airports. With desktop SSH clients, access is tied to the device where the client and keys are installed. If someone's laptop is lost or stolen, you need to assume that all the server credentials accessible from that device are compromised. If an engineer needs to work from a different machine, they need to set up their SSH configuration again — a process that can take hours if they have access to many servers and haven't documented their configuration.

Mobile access is essentially non-existent in the desktop client model. SSH apps for iOS and Android exist, but they're cumbersome for anything beyond emergency access, and maintaining a separate key and configuration management story for mobile adds yet another layer of complexity. For engineers who may need to respond to incidents from a phone, this is a meaningful operational constraint.

What a browser-based workspace actually gives you

CortexShell's browser-based terminal addresses the desktop client model's limitations not by improving the client, but by moving the access model to the right layer. Access is authenticated through CortexShell, not through device-level keys. The terminal session runs in the browser, with the server-side component managing the actual SSH connection. The engineer's device holds no credentials and performs no direct SSH connection — it's a display and input interface for a session that lives in CortexShell.

The immediate practical consequence is that access works identically from any device with a browser. The same engineer can start a session on their work laptop, continue it from a home computer, and check in on it from a tablet — all with the same access boundaries, the same session recording, and the same AI assistance. There's no SSH key to manage on the device, no configuration to replicate, and no credential to carry. The access model is in CortexShell, and CortexShell is accessible from anywhere.

For new team members, onboarding becomes trivial. Create their CortexShell account, assign them the servers they should have access to, and they're ready to work — immediately, from any device. The process that previously took hours of SSH key generation, distribution, and server-side configuration takes minutes. The quality of access is also immediately consistent: the new engineer's terminal environment, the available commands, the session recording — all of it is the same as every other engineer on the team.

Split-view terminals — up to three server sessions visible simultaneously in a single browser tab — are a capability that desktop clients typically don't offer at all, or offer only through awkward window management. For diagnostic and operational work that requires cross-referencing between multiple servers, this is a meaningful efficiency improvement. Comparing log output between two servers in real time, watching a deployment proceed across multiple nodes simultaneously, or coordinating between a load balancer and the application servers behind it — all of these become natural rather than requiring mental context-switching between separate windows.

Security: the browser model vs the client model

A common objection to browser-based terminals is security: if the session is running through a web interface, doesn't that introduce more attack surface than a direct SSH connection? This concern deserves a careful answer, because the security implications of the two models are genuinely different — but not in the direction the objection implies.

The desktop client model looks secure because the connection is direct: your SSH client talks to the server over an encrypted connection, and nothing sits in between. But this directness creates its own security problems. The client machine stores credentials. The credentials can be exfiltrated if the machine is compromised. Access is hard to centralise and monitor. Session recording doesn't happen by default. Audit trails are fragmented or non-existent.

CortexShell's model trades the "direct connection" property for a set of security properties that are, in aggregate, significantly stronger for a team environment. The connection from CortexShell's server to your infrastructure server is still SSH, still encrypted, and still uses proper credentials stored in Vault. The connection from the engineer's browser to CortexShell is HTTPS with the same security properties as any modern web application. The credentials are never on the engineer's device. The session is recorded and audited. Access can be revoked instantly from a central point.

CortexShell itself runs with HTTPS enforced, Let's Encrypt certificates for all endpoints, and can be deployed within your own network perimeter or on a VPN-accessible host. The attack surface is the CortexShell instance itself, which is a well-understood web application security model, versus the distributed attack surface of individual SSH clients on individual engineer devices — any one of which could be a weak point.

Performance, reconnection, and the mobile case

Performance is another concern worth addressing directly. Browser-based terminals have historically had a reputation for latency and visual jitter that made them unsuitable for interactive work. This was a legitimate concern in the early days of web-based terminals, when they were implemented on top of HTTP polling rather than WebSockets. Modern implementations using WebSockets for bidirectional communication, with optimised terminal rendering engines, have closed this gap significantly.

CortexShell's terminal uses a high-performance terminal emulator built on modern web standards. For typical interactive shell work — running commands, editing files with nano or vim, monitoring log output — the experience is indistinguishable from a local terminal client in a well-connected environment. The rendering engine handles ANSI escape codes, colour output, and terminal resizing correctly, which means tools like htop, tmux, and ncurses-based applications work as expected.

Session persistence is an area where the browser model actually has an advantage over direct SSH. When a desktop SSH session is interrupted — your laptop sleeps, your network drops, you close the lid — the session typically terminates, and anything running in that session stops. CortexShell sessions can be configured to persist through brief disconnections, and the session recording continues even if your browser tab is temporarily not visible. For long-running operations — a deployment that takes 20 minutes, a large file transfer, a database maintenance job — this persistence means you can close your laptop without interrupting the work.

On mobile devices, the browser-based model finally makes server management practical. Engineers who respond to on-call alerts from their phones have a usable interface — not just enough to acknowledge an alert and escalate, but enough to actually diagnose and resolve many classes of incidents. The same CortexShell interface, with CortexShell's assistance, accessible from a phone browser. For genuinely urgent situations at 3am, the difference between being able to resolve an incident remotely and needing to physically access a computer matters.

Collaboration features that desktop clients can't match

One of the less-discussed advantages of centralised, browser-based infrastructure access is the collaboration possibilities it enables. When terminal sessions are managed by a shared platform, features that are impossible with isolated desktop clients become straightforward.

Session sharing — the ability for a senior engineer to observe or join a junior engineer's terminal session — is one example. This is valuable for training, for real-time assistance during incidents, and for code review-style review of operational work. With desktop clients, this requires screen sharing through a separate tool, which captures the whole screen and can't be easily restricted to just the terminal session. With CortexShell, session access is controlled through the same access control system as server access itself.

The AI assistant CortexShell is another collaboration feature that only makes sense in a centralised model. Because CortexShell has access to the full server inventory and the context of your infrastructure, it can assist any engineer on the team with the same quality of guidance — regardless of their individual familiarity with the specific system in question. The knowledge that previously lived in a senior engineer's head is accessible to the whole team through CortexShell, which means the collaborative capability of the team as a whole is higher than the sum of individual expertise.

Team adoption: from habit to workflow

The practical challenge in transitioning from desktop SSH clients to a browser-based platform isn't technical — it's behavioural. Engineers have established muscle memory and workflows built around their existing tools. Opening a terminal, connecting via SSH, using tmux to manage sessions — these habits are deeply ingrained and interrupting them creates friction, at least initially.

The approach that works best for team adoption is gradual integration rather than forced replacement. Start by using CortexShell as a complement to existing tools: connect to new servers through CortexShell, use CortexShell for diagnostic work and fleet-wide operations, use the SFTP file manager for transfers. Let the advantages become apparent through use, rather than insisting on a complete switch from day one.

The switching point typically comes when engineers experience a specific moment that would have been significantly harder with their desktop client: resolving an incident with CortexShell's assistance, quickly checking a metric across 20 servers simultaneously, or reviewing a session recording to understand what happened during a deployment. Once an engineer has had that experience, the case for the centralised model becomes viscerally clear rather than theoretically appealing.

For new engineers joining the team after CortexShell has been adopted, there's no switching cost at all. CortexShell becomes the standard, the tool they learn on, the workflow they build their habits around. Within a few months, the "install PuTTY, generate SSH keys, add to authorized_keys on each server" onboarding process exists only as a story that senior engineers tell about what things used to be like.

What comes after the terminal

The terminal is the foundation of server management, but it's not the ceiling. The most powerful aspect of a unified, browser-based infrastructure platform is that it provides a layer above the terminal where higher-level operations become possible.

CortexShell's SFTP file manager is one expression of this: file operations that previously required either command-line file transfer tools or a separate SFTP client application are handled within the same interface, in the same browser tab, without any additional software. This sounds like a convenience feature, but it's meaningfully more than that — it means that file operations are subject to the same access control, audit logging, and session recording as terminal operations. The administrative boundary between "what you do in a terminal" and "what you do with files" disappears.

The AI assistant layer is the most significant evolution above the raw terminal. As CortexShell becomes more integrated into operational workflows — through scheduled automation, fleet-wide commands, and natural language interaction — the terminal itself becomes less a direct tool and more a verification and intervention layer. The routine operations happen through CortexShell; the terminal is where you go when you need to do something that requires direct, expert interaction with the system.

This trajectory points toward a future where the terminal is still present and essential, but where it's embedded in a richer operational context — one where your infrastructure is visible, queryable, and manageable as a coherent system rather than a collection of individual SSH sessions. The engineers who adopt that model today are building the operational practices that will define how infrastructure management works at scale over the next decade. Starting by replacing PuTTY with a browser tab is the first step in a much more significant evolution of how infrastructure teams work.