What is ShellCanvas?

ShellCanvas is a desktop application you install on your own computer. It connects to a machine you already reach over SSH and gives that machine a graphical workspace: a file manager, terminals, a text editor and small apps, each in its own window. The remote machine keeps running exactly what it ran before — ShellCanvas installs nothing on it.

How it works

Everything you see runs locally. When you open a workspace, ShellCanvas makes an ordinary SSH connection and uses standard channels over it:

What you use	What ShellCanvas uses	What the server needs
Terminal windows	An SSH shell channel with a PTY	The SSH server it already runs
Files, Editor, transfers	SFTP over the same connection	The SFTP subsystem, which OpenSSH provides
Host details, remote settings	Small read-only commands, and hostnamectl or timedatectl only when you apply a change	A shell account; changing a setting needs root and systemd

The server never renders a screen and never runs a ShellCanvas process. It answers file and shell requests, and your computer draws the windows. That has three practical consequences:

• Nothing to install or clean up. No agent, no daemon, no extra port. If you can ssh to the machine, you can open it in ShellCanvas — including short-lived servers you would rather not modify.
• The interface stays responsive. Scrolling a folder or moving a window is local work. Only the data you ask for crosses the network.
• Your account's permissions apply, unchanged. A terminal is a real shell for the account you signed in as. ShellCanvas adds no privileges and removes none.

It is worth being clear about what ShellCanvas is not, because the category is crowded:

• Not a remote desktop. VNC and RDP stream pixels from a desktop session running on the server, which needs a graphical environment installed there. ShellCanvas needs none, and it does not display graphical applications that run on the server. The windows are ShellCanvas's own.
• Not a terminal with tabs. Files, the editor and apps are first-class windows that work at the same time as your shells, over the same connection.
• Not a sync tool. Files stay on the server. Transfers happen when you ask for them, and you can watch and cancel them.

A single ShellCanvas window can hold several machines at once. Each one gets a workspace: its own windows, folders, terminal output and layout. You switch between them from the top bar, and a workspace survives a dropped connection — reconnect and your windows, folder locations and unsaved editor drafts are still there.

Beyond the built-in apps, ShellCanvas is extensible in three ways: installable apps that run in their own frame with permissions you approve, themes that are plain data files, and connection adapters that can supply files, a console or settings from something other than SSH. Today SSH is the connection that ships with the desktop.

Boundaries

ShellCanvas is a public preview, and the honest picture matters more than a feature list:

• The Windows client is the released one. Installers are published for Windows x64 and are not code-signed yet, so Windows warns about an unknown publisher. The macOS client builds from source, and its launch, layout and Settings have been confirmed on an Intel Mac; SSH workflows there are not validated. There is no validated Linux client yet.
• Remote support is proven where it has been tested. Files, terminal, editing and transfers are verified against an Ubuntu server. Other Linux distributions use the same SSH and SFTP paths but have not been tested. Browsing and a shell on a macOS server are confirmed; writes and transfers there are not. Windows OpenSSH servers are not validated.
• File features need SFTP. If the subsystem is disabled, terminals still work and file-based features report that the service is unavailable.
• Saving over an existing file needs an atomic rename. ShellCanvas replaces files using [email protected]. On servers without it you can still read, preview and create files, but overwriting an existing one is refused rather than risked.
• Installed apps are isolated on Windows only. App frames and the permission broker have targeted Windows and WebView2 validation. Containment of hostile code is not claimed, and installed app interfaces are gated off on other native platforms.
• Connection adapters are trusted native code. They run with your operating-system permissions. A package hash identifies content; it does not authenticate a publisher.

Where a limit has a number — file sizes, queue depths, item counts — it appears on the page for that feature and in Compatibility and known limitations.

Related guides

• Installation and builds — install the Windows preview or build from source.
• Requirements and compatibility — what your computer and your server need.
• Your first connection — add a host, check its fingerprint and open a workspace.
• Hosts, connections and workspaces — the model behind the windows.
• System architecture — how the parts fit together.