Skip to main content
The Mirage server is a Fastify app from @struktoai/mirage-server. It holds workspaces and serves them over the HTTP routes, MCP and RPC, and over SSH when ssh_port is set. The Python server speaks the same protocol, so a client of one works against the other.

Install

The SSH server runs on ssh2, installed beside the server, needed only for SSH.

Run it

buildApp returns the Fastify instance; it serves until you stop it.

Started by the CLI

@struktoai/mirage-cli runs the same app as a daemon, mirage-daemon, on 127.0.0.1:8765 in local auth mode, logging to ~/.mirage/daemon.log. That entry adds the two daemon behaviors: it writes $MIRAGE_HOME/daemon.pid for mirage daemon stop and kill, and exits 30 seconds (MIRAGE_IDLE_GRACE_SECONDS) after its last workspace is deleted. It listens on MIRAGE_DAEMON_PORT, the port setting, or 8765. Its settings are on the CLI page.

What is particular to this server

The protocol is the same on both servers. These are the differences in how this one serves it:
  • SSH output is sent whole. A line’s output over SSH is sent when the line finishes, as HTTP sends it. The Python server streams it.
  • No legacy scp -O. Modern scp uses SFTP, which is served; the old SCP protocol is not.
  • authorized_keys options. Only mirage-profile is read, which binds the key to a profile. A key line carrying any other option (from=, command=, …) is skipped with a warning, rather than accepted as if it had none.
  • Terminal line limit. 1024 bytes.
  • One event loop. Every workspace shares Node’s loop. Shell evaluation yields between steps, but a long synchronous step in a JavaScript callback or a CPU-heavy runtime holds every workspace until it returns, so run such work in a worker.

Code map