Skip to main content
A workspace needs no services. Out of the box it keeps everything in memory. Each store below can move onto infrastructure you run, on its own or together with the others. The rest has pages of its own: runtimes run programs inside Mirage, on the host or in a sandbox; host folders show a mount through FUSE, FSKit or NFS; and credentials come from the environment, a dotenv file, AWS Secrets Manager or 1Password.

One store or several

store.type places the namespace, sessions, history and jobs together. A group key (namespace, workspace, observer, jobs) moves one of them to a backend of its own. Here symlinks and jobs live on Redis, history on disk and sessions in a bucket:
workspace.yaml
Every store keeps its state by workspace_id. Give the workspace a fixed id whenever its state should be found again, after a restart or by another process. Closing the workspace closes a store it owns, group stores included. stores.py and stores.ts place one store at a time on disk, build the workspace again and print what came back. A workspace built in code keeps its state in memory. One the server builds, through mirage workspace create or POST /v1/workspaces, keeps it on disk under ~/.mirage/state. A store block replaces either default.

Where you set it

One config describes a workspace, the same YAML on every surface. Python and TypeScript also take each store as a constructor argument, as each store’s page shows.
Every key is listed in Workspace configuration.