# Running Multiple Rooms

A MeshCore room server is a single node that hosts a **single room**. There is no multi-room mode: one room server node = one room. To offer several separate spaces across a community (for example, a public room and a private emergency operations room), you deploy **multiple room-server nodes** — one node per room. This page covers how a single room server works and how to run several of them as a coordinated set.

## How a room server works

A MeshCore room server is a store-and-forward node configured entirely over its serial/BLE CLI — there is **no configuration file**. A single room server has:

- One advertised **node name**, set with `set name <name>` (this is the name clients see; there is one name per node).
- One **admin password**, changed with `password <new>`, used for administrative control of the node.
- One **guest password**, changed with `set guest.password <password>` (default: `hello` — change it immediately). This gates guest access to the room.
- One per-contact **access control list (ACL)**, managed with `setperm <pubkey> <level>` and viewed with `get acl`. Permission levels are Guest (0), Read-only (1), Read-write (2), and Admin (3).
- A single **read-only flag**, `set allow.read.only on|off` (default: **off**). When on, it permits unauthenticated read-only access; by default unauthenticated read is not granted.
- A single persisted **message history** store. The room server retains posts and pushes the unseen backlog to a client when that client next connects (a client receives the previously unseen messages on login — documented as the previous 32). This persistence is the entire point of a room server versus an ordinary channel.

A client connects to a room server (supplying the guest password if one is required) to access that server's single room. There is no "choose which room to join" selection, because a server hosts only one room. A client can, however, hold multiple room servers as contacts and interact with each separately.

Exact password defaults, ACL levels, and the unseen-message count should be verified against your firmware version and the current MeshCore CLI reference at [docs.meshcore.io/cli\_commands](https://docs.meshcore.io/cli_commands/) (as of 2026-06-08).

## Deploying multiple room servers

Because one node hosts one room, separate spaces require separate nodes. A community that wants a public room and a restricted emergency room runs two room-server nodes, each configured independently over its own CLI. Each node is a separate piece of hardware (for example a Heltec V3 or an nRF52840 board) with its own name, passwords, ACL, and history store.

For example, to set up three room servers across a region you would, on each node in turn, connect over serial/BLE and configure it:

```
# --- Node 1: public regional room ---
set name RegionMesh-Public
password <newAdminPassword>
set guest.password <publicGuestPassword>   # or leave blank for open guest access
set allow.read.only on                     # optional: allow unauthenticated read-only
advert

# --- Node 2: restricted emergency room (separate hardware) ---
set name EmergencyNet
password <newAdminPassword>
set guest.password <emergencyGuestPassword>
setperm <coordinatorPubkey> 2             # grant a coordinator Read-write
advert

# --- Node 3: club room (separate hardware) ---
set name ClubNet
password <newAdminPassword>
set guest.password <clubGuestPassword>
advert
```

All of these nodes — like every node in the network — must share the same radio preset (frequency, bandwidth, spreading factor, coding rate) as the companions and repeaters around them; otherwise their packets and adverts cannot be received by other nodes. Use the named region preset in the app or web flasher rather than hand-entering values. Give each node a clear, distinct name so users can tell the rooms apart.

## Controlling access to each room

Access to a room is governed by the room server's guest password and per-contact ACL, not by a per-room PSK. Anyone who has a room's guest password can join and read that room's messages, so treat it like a shared secret: distribute it through a separate secure channel (encrypted email, in person, Signal, etc.), not over the mesh itself, and rotate it with `set guest.password <new>` if it may have leaked.

For finer control on a given node, grant individual contacts specific permission levels with `setperm <pubkey> <level>` (Guest/Read-only/Read-write/Admin) and review the current list with `get acl`. For a restricted emergency room, the guest password is typically shared only with vetted local emergency-management personnel, ARES/RACES members, and CERT team leads — not published publicly — and trusted operators can be given Read-write or Admin via the ACL.

## Monitoring a room server

A MeshCore room server has no HTTP status endpoint and no management script — it is firmware on a microcontroller (nRF52840/ESP32). You monitor it over the serial/BLE CLI using the built-in stats commands:

```
# System stats: battery, uptime, queue length, debug flags
stats-core

# Radio-layer stats
stats-radio

# Packet-level stats
stats-packets
```

These commands are issued over the serial console (or the companion app's CLI). To monitor several rooms, connect to each room-server node and query it individually.