Squirrel Servers Manager: The Ansible & Docker-Powered Tool

If you’ve spent any real time wrangling Linux servers — whether you’re running them bare metal, in VMs, or inside containers — you know the drill. You open a terminal, SSH into a box, run a playbook, forget which node you’re on, accidentally restart the wrong service, and spend the next hour undoing your own mess. It’s not glamorous. And frankly, the tools that are supposed to help haven’t always kept up with how modern infrastructure actually looks.

That’s what makes Squirrel Servers Manager (SSM) worth talking about.

What Is Squirrel Servers Manager?

Squirrel Servers Manager is a fully open-source, self-hosted configuration and container management platform built on top of Ansible and Docker. The project comes from Squirrel Corporation and lives on GitHub at SquirrelCorporation/SquirrelServersManager. At the time of writing, it’s crossed 1,000 stars and is actively maintained with over 2,000 commits — not bad for something still calling itself alpha.

The stated goal of SSM is to be a “user-friendly alternative to well-known established tools” — think Portainer for Docker management, or AWX for Ansible — but in a single cohesive package that doesn’t require you to have a DevOps team just to get started.

It’s licensed under AGPL-3.0, which means you can run it freely, inspect every line of code, and even contribute back.

Why This Matters for X11 and Wayland Users

Here’s something worth clarifying upfront: SSM itself is a web-based management dashboard, not a native desktop application. You access it through a browser. But that’s actually a big deal for Linux desktop users running either X11 or Wayland display servers.

Managing Docker containers and running Ansible playbooks against remote servers has historically meant either living in the terminal or using separate, often fragmented tools. For users on X11 (the classic display protocol that most traditional Linux desktops have relied on for decades) or the newer Wayland compositor model (adopted by GNOME, KDE Plasma, and many others as the modern replacement), a browser-based tool like SSM is display-server agnostic. It works identically whether your desktop is running under an X11 session or a Wayland session — no weird compatibility issues, no missing libraries, no XWayland hacks required.

This matters more than it sounds. A lot of infrastructure tooling assumes a particular environment. SSM sidesteps all of that by being fundamentally web-native. Whether you’re on X11 debugging an old deployment or a fresh Wayland setup on Fedora Silverblue, SSM just opens in a tab and works.

The Tech Stack Under the Hood

SSM runs as a Docker Compose application. That means the entire stack — frontend, backend, proxy, monitoring — comes up with a single command. Here’s what’s happening behind the scenes:

The backend is written in TypeScript (Node.js), which handles Ansible playbook execution, device communication, and Docker API integration. The frontend is built with React and Ant Design (Ant Pro), giving it a polished, responsive dashboard feel. MongoDB handles data persistence. Redis takes care of caching and job queuing. And Prometheus is built in for metrics collection — so you’re not bolting on monitoring after the fact.

The proxy layer (Nginx) glues it together and handles routing between the frontend and backend services.

Core Features: What You Actually Get

1. Metrics and Statistics

SSM pulls real-time metrics from your registered servers — CPU usage, RAM consumption, disk I/O — and surfaces them in a unified dashboard. More usefully, it’s built to detect anomalies, so you’re not just staring at graphs hoping something jumps out.

2. Ansible Playbook Management and Execution

This is where SSM really earns its keep for configuration management. You can manage your Ansible playbooks — both local ones and those stored in remote Git repositories — and execute them directly from the UI against any of your registered devices. No more copy-pasting SSH commands or hoping your local Ansible version matches the one on the control node.

The playbook runner supports variable injection, so you can parameterize your runs without editing files by hand every time. If you’ve ever managed more than three or four servers, you know what a quality-of-life improvement this is.

3. Container Management

SSM integrates with Docker to give you a live view of all running containers across your fleet. You can see container stats, receive alerts when image updates are available (no more running docker pull across ten machines to check), and manage containers without dropping to a terminal.

This is the part that puts SSM in conversation with tools like Portainer or Yacht — but with the added bonus of Ansible integration in the same interface.

4. Automations

SSM lets you build trigger-based automations: run a playbook when a container reaches a certain state, kick off a container action when a playbook completes, that kind of thing. It’s not yet as deep as something like n8n or Rundeck, but for basic infrastructure event chaining, it covers a lot of ground.

5. Collections (One-Click Service Installs)

This is a genuinely nice feature: SSM includes a “Collections” store where you can install common open-source services on your devices with a single click. Think of it as a curated app store for self-hosters — if you want to spin up Grafana, Nextcloud, or a monitoring stack on a target server, you select it, configure a few options, and SSM handles the rest via Ansible.

6. Security

SSM uses Ansible Vault to encrypt secrets at rest and Bcrypt for authentication credentials. Your SSH keys and API tokens aren’t just sitting in plaintext config files — they’re protected. For a self-hosted tool that presumably has root access to all your servers, that’s not optional, and it’s good to see it taken seriously from the start.

Getting Started: Installation

Getting SSM running is deliberately straightforward. For a quick start, the project provides a one-liner installer:

bash

curl https://raw.githubusercontent.com/SquirrelCorporation/SquirrelServersManager/refs/heads/master/getSSM.sh | bash

If you prefer to do things manually (and you probably should, at least the first time, so you understand what’s being deployed), clone the repository, edit the .env file with your configuration, and bring the stack up with Docker Compose:

bash

git clone https://github.com/SquirrelCorporation/SquirrelServersManager.git
cd SquirrelServersManager
cp .env.example .env
# Edit .env with your settings
docker compose up -d

The project also ships separate Compose files for development (docker-compose.dev.yml) and a demo environment (docker-compose.demo.prod.yml), which is handy if you want to explore the UI before connecting real infrastructure.

One thing worth noting: make sure you edit the .env file before doing anything else. The default values include placeholder secrets that you absolutely don’t want running in production.

A Realistic Look at the Limitations

SSM is still in alpha, and the project is refreshingly honest about this. The README explicitly says “it may not work on your system” and includes an “absolutely no warranties” disclaimer. That’s not a red flag — it’s the right thing to say for a project at this stage — but it does mean you should treat SSM as a promising tool for homelab and internal infrastructure rather than something you’d put in front of enterprise-grade production systems today.

A few other things to be aware of:

The Integrations feature (triggering automations from external tools, calling external services) is listed as “coming soon.” If your workflow depends heavily on webhooks from CI/CD pipelines or third-party services, you’ll want to check the current state of that feature before committing.

Anonymized telemetry is enabled by default. To disable it, set TELEMETRY_ENABLED=false in your .env file. Not a dealbreaker, and the data collected is described as basic usage statistics, but worth knowing.

The project is primarily TypeScript with some Python for Ansible-related components. If you’re evaluating it for contribution or customization, that’s the stack you’re working in.

How It Compares to Other Tools

People tend to ask how SSM stacks up against the usual suspects. Here’s a quick mental model:

vs. Portainer: Portainer is more mature and Docker-focused, but it doesn’t have native Ansible integration. If you need both config management and container management in one place, SSM has a meaningful advantage.

vs. AWX/Ansible Tower: AWX is powerful but heavyweight and complex to deploy. SSM is considerably lighter and more approachable for smaller teams or individual operators who want Ansible execution without a full Tower setup.

vs. Cockpit: Cockpit is excellent for single-server management but isn’t really designed for multi-server fleet management with container orchestration baked in. SSM covers a different scope.

The honest answer is that SSM isn’t trying to replace any of these tools individually — it’s trying to occupy the space between them for operators who don’t want to stitch together four separate tools to manage their servers.

Who Should Look at This

SSM is a good fit if you’re running a homelab or small-to-medium self-hosted infrastructure, you’re already using or planning to use Ansible for configuration management, you want Docker container visibility without deploying a full Kubernetes stack, and you’re comfortable with a tool that’s moving fast and might have rough edges.

It’s less suited for large-scale enterprise environments right now, teams that need deep RBAC and audit logging, or anyone who needs integrations with external orchestration tools (at least until that feature ships).

Final Thoughts

What Squirrel Servers Manager gets right is the framing. Server management has been ugly and fragmented for a long time. Having a single, open-source, browser-based UI that wraps Ansible and Docker — and runs cleanly in any browser whether you’re on an X11 or Wayland desktop — is genuinely useful. The fact that it includes Prometheus metrics, an automations engine, and a one-click service collection store puts it several steps ahead of what most comparable projects offer at the alpha stage.

If you’ve got a homelab sitting under your desk or a few VPS instances scattered across providers, SSM is absolutely worth spinning up and kicking the tires on. The one-line install gets you there in under five minutes. Just remember to change those default .env values first.