Skip to content

In a Nutshell (🌰)

  • SSM uses an agentless architecture with SSH as the primary connection method
  • Components include a server, client frontend, database, and cache
  • Secure, lightweight approach with minimal requirements on target devices
  • Combines Docker and Ansible capabilities through a unified interface
  • Modular design enables extensibility through plugins

System Architecture

Squirrel Servers Manager (SSM) is designed with a modern, microservices-based architecture that prioritizes security, flexibility, and ease of use. This document provides an overview of how SSM works and how its components interact.

Core Components

Server Component

The SSM server is the central component that:

  • Handles authentication and user management
  • Communicates with devices over SSH
  • Runs Ansible playbooks and commands
  • Manages the database and caching layer
  • Provides the REST API for the frontend client

Technologies Used:

TechnologyPurpose
Node.js + NestJSBackend framework and runtime
TypeScriptType safety and better tooling
WebSocketsReal-time updates
JWTAuthentication

Client Component

The web-based frontend client provides:

  • User interface for all SSM features
  • Real-time device monitoring
  • Container management interface
  • Dashboard with performance metrics
  • Configuration tools for devices and services

Technologies Used:

TechnologyPurpose
React + TypeScriptFrontend framework and type safety
Ant DesignUI component library
WebSocketsReal-time updates
Chart librariesMetrics visualization

Storage Components

SSM uses two primary storage mechanisms:

MongoDB

Purpose: Primary database for persistent data storage

Stores:

  • User accounts and preferences
  • Device configurations
  • Container definitions
  • Playbook execution history
  • System settings and credentials
Redis

Purpose: In-memory data store for queue management and settings

Stores:

  • Session data
  • Task execution queues
  • Settings storage
  • WebSocket subscription data
Prometheus

Purpose: Collects and stores metrics from devices and containers

Stores:

  • Time-series metrics
  • Alerting rules
  • Service discovery configurations
Local Filesystem Storage

Purpose: Stores underlying data for databases and other persistent application files

Stores:

  • MongoDB data files
  • Redis RDB/AOF files
  • Application logs
  • Uploaded user content
  • Backup archives

Monitoring Components

SSM includes built-in monitoring capabilities through:

  • Prometheus: Collects and stores metrics from devices and containers
  • Internal Metrics Collector: Gathers performance data through SSH and Docker API

Communication Flow

1

Client Request

User initiates action via the web interface

2

Server Processing

Server validates request and prepares operation

3

Device Connection

Server connects to target device using SSH

4

Command Execution

Command, playbook, or Docker operation runs on device

5

Result Processing

Server processes and stores operation results

6

Client Update

Result sent to client via REST API or WebSocket

Security Architecture

Security is a core principle of SSM's design:

Credential Management

  • SSH keys and passwords encrypted using Ansible Vault
  • Credentials stored in database with additional encryption layer
  • No permanent storage of plain-text secrets in memory

Authentication & Authorization

  • JWT-based authentication for API access
  • Session management with configurable expiration
  • Secure credential storage and transmission

Network Security

  • SSH connections with strict host key verification
  • No permanent open ports on managed devices (except SSH)
  • SSH connections closed after command execution

Agentless Architecture Benefits

SSM's agentless approach offers several advantages:

Next step

🛠️
Agentless Architecture

Understand how SSM manages devices without permanent agents

Made with love