Skip to content
MisterShell

Frequently asked questions

Deployment, sessions, security, AI, and licensing — answered.

MisterShell mascot
What is MisterShell?
MisterShell is a self-hosted platform to access and troubleshoot your infrastructure from one browser — servers, network, Kubernetes, cloud and databases. From a single workspace you get privileged remote access (SSH, cloud CLI, Kubernetes, database, RDP, VNC, and web-app sessions), health monitoring and configuration change tracking, IDS alerts and syslog in context, event-driven automation, and AI assistance — with policy-driven governance that covers human operators and AI alike, and every session recordable and replayable by policy.
How is MisterShell deployed?
MisterShell runs as a single Docker container or Kubernetes deployment on your own infrastructure. Everything is self-contained out of the box, so a single container gets you a complete workspace. The same image scales up without re-architecting: add cores for an active/active, no-single-point-of-failure cluster in one region, or run cores across multiple regions for geographic reach (multi-core deployments come with the Pro edition, together with an external database, shared Redis, and a load balancer you operate). Optionally deploy remote workers (Pro) to scale operations across multiple sites or align to network segmentation policies.
Can MisterShell run highly available?
Yes — MisterShell runs active/active. Deploy three or more cores in a region and they self-cluster into one mesh: every core serves traffic, an elected leader orchestrates task scheduling exactly-once, and session recordings replicate across cores. Lose a core and the cluster keeps serving; a new leader is elected automatically. You can extend the same model active/active across multiple regions for geographic reach. MisterShell makes its own application tier highly available; you front it with a load balancer and point it at a highly-available database and cache you operate — those stay under your control. Multi-core high availability comes with the Pro edition. Remote workers are stateless and reconnect automatically, so session reach stays resilient throughout.
How does licensing work?
Licensing is an edition ladder plus independent add-ons. The Free edition covers 25 managed resources at no cost — and it is not a trial: it never expires. Each paid edition includes everything below it: Base adds authoring (your own commands, AI agents, prompts and skills), report templates and report generation, and resource capacity licensed to your estate; Pro adds the security layer — remote workers, enterprise sign-in (LDAP, OIDC, SAML), multi-core high availability, and audit export to your SIEM; Enterprise adds session, recording, file transfer, fact and configuration policies, session recording, automation playbooks, and configuration push. Capability add-ons — IDS Sensors, Syslog Collector, and Session Proxy for external access — pair with any paid edition and each scales on its own capacity dial. Licenses of the same edition stack in capacity packs; a paid license replaces the free 25 rather than adding to it. Keys are bound to the email you bought them with, not to a machine, so they survive rebuilds and moves; you preview a key before installing it, and MisterShell never phones home. List prices are published on the pricing page in packs of 50, 100, 500 and 1,000 resources per edition; from 5,000 resources, pricing is a volume quote.
What happens when a license expires?
Nothing is deleted and nothing is hidden. The installation falls back to the Free edition until you renew: your resources, configuration history, and audit evidence stay intact and readable, and licensed features simply lock until a valid key is installed. If you are over the free capacity, you can't add new resources until you renew — but you can always see and manage what exists.
What support comes with a paid edition?
Every paid edition — Base, Pro and Enterprise — includes standard web and email support, 8×5, through the Support link in the site header. Guaranteed response-time SLAs, a designated customer success manager and professional services are available on a Custom agreement.
Do I need to open inbound firewall rules?
MisterShell itself must be accessible over HTTPS for browser access. Remote workers also connect outbound over HTTPS to the MisterShell server — no inbound firewall rules are required for them.
What session types are supported?
SSH (any SSH-compatible device), AWS CLI, Azure CLI, Kubernetes shell (kubectl), database shells (PostgreSQL, MySQL, MariaDB, SQL Server, ClickHouse), interactive RDP (browser-delivered Windows desktops for servers and workstations), VNC (graphical access to any host running a VNC server, including OT/IoT devices), and web-application sessions (interactive HTTP/HTTPS apps delivered in the browser). Shell sessions can be opened from the browser or from your own SSH client; graphical sessions are browser-delivered. Every session type can be recorded and replayed under Recording Policy (an Enterprise-edition capability), with AI assistance and shared collaboration.
Do my engineers have to work in the browser?
No. Point the SSH client you already use — OpenSSH, PuTTY, your terminal of choice — at MisterShell and work exactly as you do today, against every shell resource your roles let you reach. What comes with it is a full terminal workspace: the same resource tree you would have browsed in the UI, several sessions open in tabs, and the same in-session AI assistant alongside the one you are working in. Sign in with your own SSH key if you prefer — any multi-factor check your account requires still applies. Or skip the workspace and land straight in a device session, the way a jump host would drop you there. Either way it is the same door as the browser — the same permissions, the same session policy and per-command ACLs, the same approvals, and the same recording. Your SFTP client reaches the file catalog the same way. It is included in every edition, including Free.
Will my existing automation still work?
Yes — Ansible, Netmiko, NAPALM and anything else that speaks SSH keep reaching your devices, with no playbook rewrite. Instead of each tool connecting straight to the target, it connects through MisterShell with a personal SSH key — allowed resource by resource, while the device credential stays in MisterShell and never lands in a script. MisterShell becomes a governed transport: every automated session runs under the same policy, approvals and recording as a person opening a session by hand, and lands in the same audit trail. So the automation your team already trusts stops being the one path into your estate that nothing governs.
What is the browser RDP and VNC experience like?
RDP and VNC sessions render the full graphical desktop in the browser, with no client to install. Clipboard text flows in both directions, the session can be recorded for visual replay, and graphical sessions use a single-controller model — one person drives at a time and can hand control to a participant. Graphical sessions render at up to 1920×1080; multi-monitor and drive redirection are not supported, and graphical replays are visual (no text transcript). Note that AI assistance, health monitoring, and configuration change tracking apply to shell-managed platforms; graphical RDP and VNC sessions are recordable and policy-governed, but provide remote access only.
Does MisterShell support file transfer?
Yes — and not as an SFTP client bolted onto a terminal. Your location tree doubles as a file catalog: people browse and transfer against MisterShell, never against the resource directly, and a File Transfer Policy decides every copy between the catalog and a resource. Rules are ordered and match on location, resource type, tag, role, direction, and both source and destination paths, so you can permit a firmware image while refusing sensitive destinations on the device — and a rule can require a human approval before transfers to a resource begin. Nothing is denied halfway — the whole selection is checked before the task starts, and if no rule matches, the transfer is refused. Every transfer is its own session in the audit trail, with the operations and hashes recorded and no file content retained. File transfer is available in every edition; policy authoring is an Enterprise capability.
Where are transferred files actually stored?
In stores you mount onto the location tree. The built-in Root store keeps content locally; you can attach an Amazon S3 bucket or Azure Blob container to any location, and everything at that location and below uses it — so mounting a French bucket at /EMEA/France means files for Paris resources are held in France without anyone having to think about it. Data residency becomes a property of your topology rather than a rule people have to remember. Existing files stay in the store where they were created; changing a location's store does not move old content.
Do my devices need access to the object store?
No — and that is the point. The resource never talks to the store. A transfer runs as a task on the worker closest to the resource, which streams bytes to and from the core, which in turn talks to the store. Your segmentation stays intact: no new egress path from a device to cloud storage, no credentials on the device. It also means transfers survive you closing the tab — the work continues on the worker — and that distributing something like a firmware image pulls it from a store near the resource rather than dragging it across your WAN.
Which file protocols does it use?
Whatever the target actually supports — you get the same two-pane experience either way. On an SFTP-capable host it uses SFTP. On network gear that only offers SCP, MisterShell presents the same browse, rename, move, and delete experience by driving the device's own shell commands, using SCP purely to move the bytes. Operators get one consistent way to work with files across the estate instead of learning which boxes are second-class. If you would rather stay in your own tooling, an SFTP client such as WinSCP or FileZilla can browse the catalog directly, under the same permissions.
Can external vendors or contractors get access?
Yes. You can invite an external guest to a single shared session by email — a one-time join link, no account required. External guests are reached over a deployed proxy, are off by default until an administrator enables them, and your session policy still applies. External access is the Session Proxy capability add-on, available with any paid edition.
Can I use my existing identity provider?
Yes. MisterShell supports SAML, OIDC, and LDAP authentication — configure your corporate IdP for single sign-on and map directory groups to MisterShell roles so access follows your directory — an OIDC or SAML provider can resolve group membership from your LDAP directory when the token does not carry it. Enterprise sign-in comes with the Pro edition.
Does MisterShell enforce multi-factor authentication?
Yes, at two levels. With SAML or OIDC single sign-on, multi-factor and conditional-access policies are enforced by your identity provider and apply to MisterShell like any other application. For local and LDAP sign-in, MisterShell enforces MFA itself — an authenticator app, or an emailed code where that is enough, chosen per provider — alongside password requirements for local accounts.
How does AI work in MisterShell?
You bring your own LLM and own the account and billing — ten providers are supported: Anthropic, OpenAI, Ollama (self-hosted), Azure OpenAI, Google, Mistral, xAI, Cohere, OpenRouter, and AWS Bedrock. AI is opt-in: nothing is sent to the provider you configure until you invoke an agent. Interactive assistance runs under the invoking user's permissions and location scope; background automation agents are constrained by agent-type and per-agent tool restrictions. On top of that sit AI guardrails: per-resource-type command allowlists, read-only by default, rate-limited — and every chat, agent run, model request and tool call lands in one AI audit trail, correlated by actor, origin and outcome. The AI agent platforms you already run can reach MisterShell through its MCP endpoint by signing in as a user through your own identity provider, with exactly that user's permissions (Pro edition, OIDC).
How does MisterShell control what an operator can run?
Session Policy is a firewall for sessions: ordered rules decide Accept or Deny when a session opens, and again on each command typed in a shell — checked at the worker, so a denied command never reaches the target. A matched rule can additionally notify or log, and a rule can require approval before access — the roles you choose decide, the access expires on its own, and every request and decision is kept as evidence. Rules reference reusable named command ACLs — ready-made database read-only and mutating sets ship built in, and you define your own for anything else. Session Policy comes with the Enterprise edition.
How does MisterShell work alongside TACACS+/RADIUS, like Cisco ISE?
They complement each other. Keep ISE, TACACS+, or RADIUS for device authentication, and let MisterShell add command-, device-, and location-level session policy, recording, and per-user attribution on top — without re-engineering per-device AAA. The policy layer that is otherwise complex to express and maintain across many devices lives in one place.
How are credentials stored, and can they be rotated?
Credentials never leave your environment: secret fields are masked in the UI and stored encrypted. Service account credentials serve automation; people get a personal and team vault of their own — shared by role, with history, a password generator and an audit record of every use — so the team password file can retire. MisterShell does not replace your secrets management: keep rotation in the system you already run, and update MisterShell programmatically through the REST API or the official Terraform provider.
Does MisterShell handle intrusion detection and log collection?
Yes, as independent capability add-ons that pair with any paid edition. Passive IDS Sensors stream intrusion-detection alerts (capacity by number of sensors) from a detection ruleset you manage in-app — enable rule sources, add custom rules, override individual signatures, and build, version, and roll back the ruleset your sensors apply. The Syslog Collector ingests inbound device and server syslog (capacity by number of collecting workers) — both attributed to the right resource and location, and searchable in context alongside health and configuration history. Note this is about pulling logs in: exporting your own audit events to a SIEM via syslog/CEF is a separate capability that comes with the Pro edition.
What audit evidence does MisterShell produce?
Several layers, all under your control. Session Policy writes an audit trail of its decisions — enable logging per rule and every accept or deny is recorded with who, what, and where — and every access approval request and decision is kept in its own evidence timeline, even after the rule changes. The AI audit trail correlates every chat, agent run, model request and tool call with its actor and outcome, and Review keeps fleet-wide Health and Compliance timelines. Security audit events, and a metadata-only AI stream, export via syslog/CEF or webhook to your SIEM (Pro edition). And Recording Policy captures full session recordings with replay — terminal, RDP, VNC, and web — to an object store you own (local, S3, or Azure), routed by data residency with per-rule retention. The policy and recording engines come with the Enterprise edition.
How durable are session recordings as evidence?
Recordings are immutable operational evidence: deleting a resource, user, or worker never deletes its recordings, and replay flags any detected gap as partial rather than papering over it. Each recording is SHA-256 hashed when it is captured; the hash is kept in MisterShell, apart from the recording itself, and every replay verifies the recording against it — so you can show a recording has not been altered since capture. Recordings live in an object store you control — local, S3, or Azure Blob — with retention set per Recording Policy rule, under your own storage governance.
Is MisterShell certified (SOC 2, ISO 27001)?
MisterShell is self-hosted: it runs entirely in your environment, so your deployment is governed and audited under your own controls. MisterShell does not currently hold third-party certifications such as SOC 2 or ISO 27001. The compliance page maps how MisterShell capabilities support common control frameworks (SOC 2, ISO 27001, NIST 800-53, PCI DSS, CIS) to speed your own evidence-gathering.
How is MisterShell itself tested and secured?
More than 27,000 automated tests cover the backend, UI and workers, including over 2,000 integration and end-to-end tests, for over 85% code coverage. CI gates every change with lint, the unit suite and a dependency audit. Critical and high CVE findings in the dependency chain are evaluated weekly, and fixes ship in minor releases, traceable in the changelog. The codebase also gets regular security reviews with the latest frontier models from Anthropic and OpenAI. View the changelog.
Does MisterShell back up resource configurations automatically?
Yes. MisterShell collects configuration snapshots of every managed resource on a regular, configurable schedule — not only during sessions. Each snapshot is compared to the previous version into a timestamped, searchable changelog, attributed to the change author whenever one can be identified.
What are operational facts?
Operational facts are the operational state MisterShell automatically extracts from each managed resource — for example physical interfaces, ARP entries, IP routes, or NTP sync status. What is collected varies by resource type, and every fact is tracked over time so you can see how it changed. Facts surface at the resource and location level in the UI and through the built-in MCP server, giving people and AI searchable context to reason about the environment without touching a single device — for example, every MAC address at a site and below, or every resource with a route to 10.0.0.0/8. Operational facts are a core capability included in every edition, Free included — an administrator switches collection on with a single toggle.
Can MisterShell check whether my resources match an intended state?
Yes — that's Fact Policy. On top of operational facts, you define an operational intent (for example "NTP must be synchronized", "an approved software version must be running", "an uplink route must be present") as reusable checks, and MisterShell verifies every in-scope resource against its actual collected state on each snapshot. The result is a pass/fail compliance heatmap tracked over time — at fleet, location, or single-resource scope — with drill-down to the exact assertion that failed. A status change can raise an automation event and write an audit entry for your SIEM. It verifies operational state against your intent — continuous checking and evidence, not configuration-baseline auditing. Fact Policy itself changes nothing on a device; remediation is an explicit playbook step, which can sit behind a human Approve step. Fact Policy comes with the Enterprise edition.
Some of my vendors or platforms are not supported yet. What can I do?
Please contact us — we'll be happy to discuss adding official support for your platforms.
Is there a cloud/SaaS version?
No. MisterShell is always deployed on your own infrastructure. Your data, sessions, and credentials stay in your environment; AI calls go only to the model provider you choose to configure — which can be a self-hosted Ollama endpoint you operate. This is by design — operational access to infrastructure should stay under your control.

Get in Touch

Want a guided demo, or a trial license to evaluate Pro or Enterprise on your own infrastructure? Tell us — we'd love to hear from you.