[SUPPORT] - Meshmonitor win64 multiple instances

[sisari]

Hi Yeraze,
Is it (can it be) possible to run multiple Meshmonitor instances each connected to a different node ?
I tried with different ports 8080,8081 and not working ...
Best regards,
Kokoshell

[Yeraze]

That's very doable via docker, is the Windows or Mac apps it's a bit more difficult.

[Yeraze]

Claude finished @sisari's task —— View job

---

🤖 Automated Triage

Todo List

• Classify issue type
• Search for duplicate issues
• Analyze codebase for multi-instance configuration
• Provide diagnostic steps
• Reference relevant documentation
• Apply appropriate labels

---

Thank you for asking about running multiple MeshMonitor instances! This is a QUESTION about existing functionality that has a solution.

The good news: Multiple MeshMonitor instances are absolutely supported! Each instance connects to exactly one Meshtastic node, so running multiple instances for different nodes is the intended design.

The Solution

For Windows Desktop Apps

The Windows Desktop application has limitations for running multiple instances because:

1. Each instance tries to use the same port (8080 by default)
2. Desktop apps store configuration in the same location
3. Each instance runs as a single-user application

For Docker (Recommended)

As mentioned by the maintainer, Docker is the ideal solution for multiple instances. Here's the exact configuration from our documentation:

services:
  meshmonitor-node1:
    image: ghcr.io/yeraze/meshmonitor:latest
    container_name: meshmonitor-node1
    ports:
      - "8080:3001"
    volumes:
      - meshmonitor-node1-data:/data
    environment:
      - MESHTASTIC_NODE_IP=192.168.1.100
      - ALLOWED_ORIGINS=http://192.168.1.50:8080
      - SESSION_COOKIE_NAME=meshmonitor-node1.sid
    restart: unless-stopped

  meshmonitor-node2:
    image: ghcr.io/yeraze/meshmonitor:latest
    container_name: meshmonitor-node2
    ports:
      - "8081:3001"  # Different port!
    volumes:
      - meshmonitor-node2-data:/data
    environment:
      - MESHTASTIC_NODE_IP=192.168.1.101
      - ALLOWED_ORIGINS=http://192.168.1.50:8081
      - SESSION_COOKIE_NAME=meshmonitor-node2.sid  # Different cookie name!
    restart: unless-stopped

volumes:
  meshmonitor-node1-data:
  meshmonitor-node2-data:

Key points:

• Each instance needs a different port (8080, 8081, etc.)
• Each instance needs a unique SESSION_COOKIE_NAME to prevent cookie conflicts
• Each instance connects to its own MESHTASTIC_NODE_IP
• Access them at http://your-ip:8080 and http://your-ip:8081

For Windows Desktop Alternative

If you prefer staying with Windows applications:

1. Use different ports for each instance:

   • Instance 1: Port 8080
   • Instance 2: Port 8081
   • Configure this in each instance's settings

2. Run from different user accounts (advanced)

3. Consider switching to Docker Desktop on Windows for easier management

Diagnostic Steps

To troubleshoot your current setup:

1. Check Port Conflicts

netstat -an | findstr :8080
netstat -an | findstr :8081

Look for existing connections on these ports.

2. Verify Meshtastic Node Connectivity

ping 192.168.1.100  # Your first node IP
ping 192.168.1.101  # Your second node IP
telnet 192.168.1.100 4403  # Test TCP connection
telnet 192.168.1.101 4403  # Test TCP connection

3. Check Desktop App Logs

• Windows logs location: %LOCALAPPDATA%\MeshMonitor\logs\
• Look for port binding errors or connection failures

Documentation References

• Multiple Instances FAQ: Can I monitor multiple Meshtastic nodes with one MeshMonitor instance?
• Docker Configuration Guide: Getting Started with Docker
• Desktop Application Guide: Desktop Configuration
• Session Cookie Conflicts: CSRF errors when running multiple instances

Suggested Labels

• question - User needs help with existing functionality
• docker - Solution involves Docker configuration
• configuration - Configuration guidance needed
• desktop - Related to desktop application

The Docker approach will give you the most reliable multi-instance setup!

[sisari]

For Win64 the "Starting" button sohws always busy cycle preventing any new Meshmonitor instance to be started on another port for another node etc.

[Yeraze]

Technical Analysis

I've investigated the desktop application code and identified why multiple instances aren't working. The issue is architectural rather than a deliberate single-instance lock.

Root Causes

1. Shared Configuration File
   All instances read from the same config file:

   • Windows: %APPDATA%\MeshMonitor\config.json
   • Mac: ~/Library/Application Support/MeshMonitor/config.json

   When you change the port in one instance, it changes for all instances since they share the same file.

2. Shared Database
   All instances use the same SQLite database:

   • Windows: %LOCALAPPDATA%\MeshMonitor\meshmonitor.db

   Even if port conflicts were resolved, running multiple instances against the same database would cause data conflicts.

3. Port Binding Failure
   When the second instance starts, it reads the same config (same port) and tries to start the Node.js backend. The port is already in use by the first instance, so the backend fails to start. The UI then shows a perpetual "Starting" spinner because it's waiting for a backend that will never come up.

The "Busy Spinner" Explained

The screenshot you shared shows the backend startup failing silently. The app isn't explicitly blocking multiple instances - it's just that the second instance can't bind to the same port, and there's no error feedback to the UI.

Potential Solution: Profile Support

To properly support multiple instances, we'd need to implement a "profile" or "instance" system where:

• Each profile has its own configuration file
• Each profile has its own database
• Each profile has its own web port
• Users could launch with something like MeshMonitor.exe --profile node2

This would allow truly independent instances, each monitoring a different Meshtastic node.

---

For now, Docker remains the recommended approach for running multiple MeshMonitor instances, as shown in the earlier comment. Each container is fully isolated with its own config, database, and port mapping.

Would profile support for the desktop app be valuable to you? I can look into implementing this if there's interest.