# Operating Multiple Channels on One Network

Running multiple Meshtastic channels on the same network infrastructure enables privacy separation, role-based access control, and operational flexibility. This page covers design patterns for multi-channel community networks.

## Why Multiple Channels?

- **Privacy tiers:** Public channel (open access) + private community channel (member-only key) + infrastructure/ops channel (operators only)
- **Functional separation:** General chat, emergency/tactical, telemetry/MQTT, admin coordination
- **Geographic zones:** Neighborhood channels within a metro-wide network
- **Inter-network bridging:** A bridge node can monitor a second network's channel while primarily operating on your community channel

## Channel Capacity

Meshtastic supports up to 8 channels simultaneously on a single node (slots 0-7). Channel 0 is the primary channel (all nodes have it). Channels 1-7 are secondary and only active on nodes configured to use them.

All enabled channels share the same LoRa radio and the same RF frequency - the node transmits and receives on one frequency at a time. Adding channels does not add spectrum; it adds logical (name/PSK) separation only. Multiple channels increase channel utilization proportionally with message volume on each channel, because every channel's traffic competes for the same airtime.

## Recommended Multi-Channel Configuration

The commands below use the official Meshtastic Python CLI. `--ch-add` creates a new secondary channel, and `--ch-index N --ch-set <field> <value>` sets a field on the channel at that index (see the Meshtastic CLI reference at meshtastic.org/docs/software/python/cli/).

```
# Channel 0: Public community channel
meshtastic --ch-index 0 --ch-set name "PDXMesh"
meshtastic --ch-index 0 --ch-set psk "community-key-base64=="
meshtastic --ch-index 0 --ch-set uplink_enabled true # optional: MQTT bridge
meshtastic --ch-index 0 --ch-set downlink_enabled false # prevent loops

# Channel 1: Operations/admin (limited to infrastructure operators)
meshtastic --ch-add
meshtastic --ch-index 1 --ch-set name "PDX-Ops"
meshtastic --ch-index 1 --ch-set psk "ops-key-base64=="
meshtastic --ch-index 1 --ch-set uplink_enabled false # keep off MQTT
meshtastic --ch-index 1 --ch-set downlink_enabled false

# Channel 2: Emergency (activated during events)
meshtastic --ch-add
meshtastic --ch-index 2 --ch-set name "PDX-EmComm"
meshtastic --ch-index 2 --ch-set psk "emcomm-key-base64=="
```

## Channel Key Management

With multiple channels, key management becomes important:

- Store all channel keys in a password manager (Bitwarden, 1Password) shared with authorized operators
- Document which nodes have which channels configured - a node without channel 2 will miss emergency messages
- When a key is compromised, change only the affected channel key - other channels are unaffected
- Establish a key rotation schedule: community channel annually, ops channel quarterly, emcomm channel pre-activation

## Traffic Impact

Each additional active channel increases channel utilization by the traffic that channel carries — all channels share one radio and one frequency, so their airtime adds up. Monitor total CU across all channels:

- With 3 channels, target total CU under 20% combined (channel utilization is reported over a 1-minute window; firmware self-throttles, deferring its own transmissions, as CU rises around 25%)
- Low-activity channels (ops, emcomm) add minimal overhead: mostly periodic NodeInfo broadcasts
- A busy community-chat channel can contribute a substantial share of total CU; the exact percentage depends on message rate, packet size, and modem preset, so measure it on your own network rather than assuming a fixed figure