Monky CLI

This is the server CLI, not the CLI generated for a bot. To package and operate your own bot, see Bot distribution.

Command line tool to create and administer Monky servers.

monky <command> [subcommand] [options]

The CLI is installed globally and does not depend on the directory you are in: it keeps a registry of this machine's servers in ~/.monky/servers.json and uses it to know which server each command applies to.

Installation

Requires Node.js 22 or newer (required by mediasoup, used in SFU mode).

bash

curl -fsSL https://monkyorg.github.io/install.sh | bash

To install a beta version:

bash

curl -fsSL https://monkyorg.github.io/install.sh | bash -s -- --beta

Manual installation (without the script)

Download the .tgz for the desired version from Releases and install with:

bash

npm install -g --allow-scripts=mediasoup https://github.com/MonkyOrg/Monky/releases/download/vX.Y.Z/monky-cli-X.Y.Z.tgz

--allow-scripts=mediasoup permits mediasoup's postinstall, which builds the SFU worker. From npm 12 on, install scripts are blocked by default, and without that binary the server still starts but SFU mode does not work: calls carry no media and the client keeps retrying until the worker comes up. On npm older than 11.16 the flag is unnecessary and can be omitted.

To run the server as a daemon (monky start) the CLI uses PM2. If it is missing, monky start installs it automatically. Every other command only warns about it:

bash

npm install -g pm2

The CLI looks for PM2 the way the terminal would, through PATH, so it also finds one installed by pnpm, Yarn or Volta. A PM2 that is found but fails pm2 --version is never installed over: the CLI warns instead, and it should be fixed with the tool that installed it.

Quick start

bash

monky create     # creates the server and offers to start it
monky status     # check that it is up
monky logs       # follow the logs

Multiple servers

A single machine can host as many servers as you want — each with its own data directory, port and PM2 process.

When there is one server, commands act on it directly. When there is more than one, the CLI asks which one you mean:

There are 2 Monky servers on this machine.
Which server would you like to restart?
❯ Friends — port 3000 — /srv/monky-friends
  Work — port 3100 — /srv/monky-work

Scripts and cron jobs have no interactive terminal, so pass --data explicitly:

bash

monky --data /srv/monky-friends restart

CLI language

The first command run in an interactive terminal asks for English (US) or Português (Brasil) and saves the choice in ~/.monky/cli-config.json. monky, --help and --version neither ask this question nor save a preference. Commands in scripts or with redirected input/output do not ask or change the saved language either.

To change it later, open monky config and choose Idioma / Language, or run:

bash

monky config language en-US
monky config language pt-BR

This setting works without creating or selecting a server. The next menu already uses the new language; identity, database and server configuration are unchanged. monky config language without a code opens the picker in a terminal; in scripts, it only queries the preference. The monky --lang pt-BR|en-US shortcut remains available.

en-US is normalized to en; English and Portuguese variants, including pt_BR.UTF-8, use the en and pt-BR catalogs. An unsupported code, a missing --lang value or an invalid configuration produces an error instead of silently overwriting the preference with a default.

Precedence is --lang → MONKY_LANG → saved preference → terminal locale → English. For terminal detection, the CLI checks LC_ALL, LC_MESSAGES, LANG and LANGUAGE, in that order. MONKY_LANG lets an app or script pass its selected language without reading or changing the CLI preference; the CLI does not read Electron profiles.

--lang alongside an interactive command saves the choice. With help, version or non-interactive commands, it applies only to that invocation. Standalone monky --lang <code> explicitly edits the preference and saves it even in scripts.

QA isolation: MONKY_HOME changes the directory of both the server registry and the language preference. For example, in PowerShell:

powershell

$env:MONKY_HOME = Join-Path $PWD '.monky-qa'
monky --lang en-US
monky --help

The preference then lives in .monky-qa\cli-config.json; --data still selects a server's data, not its language. Command names, keys such as maxUsers and voiceMode, permissions such as MANAGE_ROLES, and values such as true, false, p2p and sfu are not translated.

Global options

Option	Description
`--data <folder>`	Data directory of the target server. Required when there are several servers and the terminal is not interactive.
`--help`, `-h`	Show the help.
`--version`, `-v`	Show the installed version.
`--lang <code>`	Select `en`/`en-US` or `pt-BR`; used alone, save the preference.

Data directory layout

Path	Contents
`server.db`	SQLite database: members, roles, channels and messages.
`monky.json`	Server port and trusted proxies.
`ecosystem.config.cjs`	PM2 configuration, rewritten on every `start`/`restart`.
`attachments/`, `avatars/`, `icons/`	Uploaded files.
`server.lock`	Exists while the server is running. See Changes while the server is running.
`backups/`	Copies of `server.db` made by `monky update` before restarting onto the new version. The 3 most recent are kept.

Exit codes

Code	Meaning
`0`	Success.
`1`	Failure. The message is printed to `stderr`.

Changes while the server is running

The server keeps the whole database in memory and rewrites server.db from that copy. A change written from outside while it runs disappears within seconds, even after a monky restart. That is why the commands that change data require the server to be stopped:

monky admin add and monky admin remove;
monky roles create, assign, unassign and delete;
monky config set, except the port, autoUpdate and trustedProxies keys, which live outside the database.

With the server running, whether under PM2, hosted by the app or started by hand, the command is refused without writing anything and explains how to proceed:

bash

monky stop
monky admin add Someone
monky start

While the server runs, the change can also be made in the app. If the server is started while an interactive command waits for an answer, the command ends with an error and saves nothing. A command that fails also saves nothing halfway.

Queries (monky members, monky roles and monky config show) read a copy of the database and work while the server runs, without rewriting it. After the CLI is updated, they ask for a monky restart while the running server has not loaded the new version yet.

While it runs, the server marks the data directory with the server.lock file. If it is killed, the file is left behind and ignored: the CLI checks whether the process it names still exists on this machine.

Command reference

`monky create`

Creates a new server: prepares the database, sets the owner and saves the port. It replaces the former monky bootstrap, which still works as an alias.

bash

monky create [options]

After the initial language choice, when needed, the command asks:

Where to store the data — suggests ./data, but any path works. If the chosen folder already holds a server, it asks for another one.
Owner identity code (MONKY-ID2:...) — export it from the Monky app under Settings → My Profile → Identity. Treat the backup and password as credentials: use them only on a trusted administration machine. Codes starting with MONKY-ID2: need an up-to-date CLI; a CLI from before them answers "Invalid identity code". If the CLI was already installed, run monky update before monky create (or monky update --beta if the app is on the beta channel). MONKY-ID: codes, exported by earlier app versions, are still accepted.
Identity password — the one you set when exporting. The code and the password are checked before any data is written: a wrong password does not leave a half-created server behind. If the command says the code came from a newer version of Monky, update the CLI with monky update and run it again.
Server name
Server port (default: 3000)
Server password — leave empty for an open server.
Member limit — asks whether you want a cap on registrations. The default is no limit.
Voice/video mode — p2p or sfu. In SFU mode, it checks ports and dependencies and asks for available upload bandwidth to estimate capacity.

It then prints a summary, asks for confirmation and offers to start the server.

Options

Option	Description	Default
`--identity <code>`	Owner identity code	asked
`--name <name>`	Server name	`Friends Server`
`--port <n>`	Server port, from 1024 to 65535	`3000`
`--password <password>`	Server password (empty = no password)	asked
`--max-users <n>`	Registered member limit (`0` = no limit)	asked
`--voice-mode <p2p	sfu>`	Voice and media mode (`p2p` or `sfu`)

The identity password is never accepted as an option: it is always typed hidden in the terminal.

Examples

bash

# Fully interactive
monky create

# Folder given as an option, everything else asked
monky create --data /srv/monky-friends

# Non-interactive, except for the identity password
monky create --data /srv/monky-friends \
  --identity "MONKY-ID2:..." \
  --name "Friends Server" --port 3000 --password "serverPassword"

`monky list`

Lists this machine's servers and the state of each one. Also accepted as monky ls.

bash

monky list

NAME       STATUS   PORT   DATA DIRECTORY
Friends    online   3000   /srv/monky-friends
Work       stopped  3100   /srv/monky-work

`monky start`

Starts an existing server as a PM2 daemon.

bash

monky start [--port <n>] [--fresh]

If the machine has no server, the command fails and points at monky create — it never creates a server on its own.

The ecosystem.config.cjs file is rewritten before starting, so the current port and name take effect from then on. It also pins the absolute path of the Node that ran the command (see Changing the Node version).

Options

Option	Description	Default
`--port <n>`	Port for this run only	value in `monky.json`, or `3000`
`--fresh`	Drops the PM2 process registration and recreates it from scratch	off

To change the port permanently use monky config set port.

--fresh is rarely needed: the CLI detects a stale registration on its own and recreates the process. It exists to force that by hand. Logs under ~/.pm2/logs are not deleted.

Removed options

--password, --max-users, --name, --voice-channel and --text-channel are no longer accepted here. They only had an effect while creating the database and were silently ignored for existing servers. The command now fails pointing at the alternative: monky create or monky config set.

`monky stop`

Stops the server, keeping it registered in PM2.

bash

monky stop

The process stays listed in PM2 on purpose: removing it would discard the logs exactly when they matter most, right after a crash or a manual stop. monky logs keeps working with the server stopped.

Online people counters (including the home page and monitor) exclude bots and count each identity only once, even when connected from multiple devices. Invisible people still count toward the shutdown warning: they remain connected and will also be disconnected.

If anyone is connected at that moment, the CLI reports how many people will be disconnected and asks for confirmation before stopping. On a non-interactive terminal (scripts, cron) the warning is printed and the stop goes ahead.

`monky restart`

Restarts the server applying the current configuration.

bash

monky restart [--port <n>] [--fresh]

ecosystem.config.cjs is rewritten before the restart, so a port or name changed since the last start takes effect.

Just like stop, if anyone is connected the CLI warns and asks for confirmation before restarting.

--fresh works the same as in monky start: it drops the PM2 process registration before bringing the server back up.

If PM2 still executes a file from another CLI installation, start and restart automatically recreate only that server's registration. Rewriting ecosystem.config.cjs is not enough in this case: PM2 may retain the previous executable path. The data directory and logs are preserved; a change only to the Node interpreter still uses the normal restart.

Database reads performed by start, restart and status (including --watch) do not write data or apply migrations. The server owns migrations at startup, after the previous instance exits, so its in-memory snapshot cannot overwrite a schema upgraded by the CLI.

`monky status`

Shows the state of the server.

bash

monky status [--data <folder>]

With a single server (or with --data), it shows the details:

Server state: Friends
State: online
Data directory: /srv/monky-friends
port 3000
PM2 process: monky-server-a1b2c3d4
PID: 21877
Started at: 2026-08-27T18:02:11.000Z
Restarts: 0
Memory: 88 MB
CPU: 0%
Node.js: 24.20.0

status does not just echo what PM2 says: the port is actually probed. PM2 reports the state it intends to keep, not one it verified — a process that failed to start still shows up as online. When PM2's claim does not match reality, a diagnostics block appears:

Diagnostics
⚠ PM2 is running the server on Node 20.20.2, but Monky requires Node 22+.
  Upgrade Node, then run "monky update" to rebuild native modules and "monky restart" to apply it.
⚠ PM2 reports the process as "online", but it has no PID — it never actually started.
  This usually means PM2 is trying to use a Node that no longer exists. Run "monky restart --fresh" to re-register the process.

With several servers and no --data, it prints the same table as monky list — a read-only query has no side effects, so asking would be busywork.

Detailed status for a running server also reports bots with an incompatible or unchecked protocol. These warnings appear after monky start and monky restart and explain when to update or check the bots' SDK. After starting or restarting (including after monky update), the CLI retries for up to 10 seconds while /preview is unavailable, ending the wait as soon as it receives data. If the deadline expires or the response lacks valid compatibility data, the CLI reports that compatibility could not be retrieved; check again with monky status --data <folder>.

monky list and multi-server tables keep these warnings next to the relevant server. In monky status --watch, the warning refreshes each cycle and clears when bots reconnect with a compatible SDK. Stopped servers are not queried or reported as incompatible.

Changing the Node version

PM2 runs as a long-lived daemon and holds on to the Node it was started with. Upgrading Node does not upgrade PM2 along with it, and that is where most post-upgrade trouble comes from.

What breaks is not upgrading Node itself, but the binary path changing or disappearing:

Situation	What happens
In-place upgrade (apt/NodeSource, stays at `/usr/bin/node`)	Keeps working: the path exists and now points at the new Node
Switching package manager (apt → nvm) and removing the old one	Breaks: PM2 points at a binary that no longer exists and cannot start the process
`nvm use` another version, without removing the old one	Silent: the server keeps running on the old Node

In the second case PM2 shows status: online with pid: N/A, and nothing listens on the port — the client complains that "the computer is online, but no Monky server is active on the port". monky status calls this out in the diagnostics block.

Since version 8.1 ecosystem.config.cjs pins the absolute path of the Node that ran monky start, instead of letting PM2 resolve node from the daemon's environment. Because the file is rewritten on every start and restart, it re-adjusts itself.

Recommended procedure

After changing the Node version:

bash

monky update     # rebuilds native modules for the new ABI
monky restart    # re-pins the interpreter in the ecosystem file
pm2 save         # writes the good state to the PM2 dump

Use monky restart, not pm2 restart

Only monky rewrites ecosystem.config.cjs. pm2 restart reuses the previous registration, with the stale interpreter.

pm2 update alone does not fix it

pm2 update restores processes from ~/.pm2/dump.pm2, and the dump carries the old interpreter. If the server does not come back, recreate the registration:

bash

monky restart --fresh

That drops the PM2 process and registers it again. Files under ~/.pm2/logs are preserved.

If the updated CLI shows the new version but connections still report an old protocol, check monky status --data <folder>. Diagnostics compare the file actually executed by PM2 with the current CLI installation's file, showing both when they differ. On versions without this automatic recovery, monky restart --fresh --data <folder> recreates only the selected registration without deleting the database. Run it as the user managing that instance; if the mismatch persists, check which process is listening on the server port.

Native modules are a separate concern: better-sqlite3 and the mediasoup worker are compiled against the Node ABI (20 = 115, 22 = 127, 24 = 137). Any major version change requires reinstalling the CLI, which is what monky update does.

`monky logs`

Shows the logs of the server started with monky start.

bash

monky logs [--lines <n>] [--level <level>] [--no-follow]

Options

Option	Description	Default
`--lines <n>`	How many previous lines to show	`100`
`--level <level>`	Minimum level: `INFO`, `WARN` or `ERROR`	no filter
`--no-follow`	Print and exit instead of following live	follows

--level filters by minimum level: INFO shows everything, WARN shows warnings and errors, ERROR shows errors only. Continuation lines (stack traces, for instance) inherit the level of the line above them.

Examples

bash

monky logs                              # follows live (Ctrl+C to exit)
monky logs --lines 500                  # starts with the last 500 lines
monky logs --level WARN                 # warnings and errors only
monky logs --level ERROR --no-follow    # prints recent errors and exits

TIP

monky logs reads PM2's logs. If the server is running inside the Monky app, use the Server Monitor in the app itself (server menu → Server Monitor).

`monky members`

Lists the server members and their roles.

bash

monky members
monky members info <nickname|clientId>

members info shows the id, clientId, public key, creation and last-seen dates, whether they own the server and their roles.

`monky admin`

Grants or revokes the Admin role.

bash

monky admin add [nickname|clientId]
monky admin remove [nickname|clientId]

Without an argument, the command lists the members for you to pick from. It requires the server to be stopped; see Changes while the server is running.

`monky roles`

Administers the server roles.

bash

monky roles                       # list
monky roles create [name] [color] [permissions]
monky roles assign [member] [role]
monky roles unassign [member] [role]
monky roles delete [role]

Without arguments, each subcommand is interactive. Permissions can be passed by name, comma separated. Colors use the #RRGGBB format. The server's default role cannot be removed from a member. Creating, assigning, removing and deleting roles requires the server to be stopped; listing them does not.

A new role follows the same rules as the app: its name has 1 to 32 characters and cannot be Admin, which is reserved for the administrator role. Roles do not grant the administrator permission; use monky admin add for that.

`monky config`

In a terminal, opens CLI settings, including language and access to the server configuration. Without a TTY or in CI, it keeps the direct server query.

bash

monky config                       # settings menu in a terminal
monky config show                  # show server data directly
monky config language en-US        # CLI language, even without a server
monky config set                   # pick the key interactively
monky config set <key> [value]     # change it directly

Keys

Key	Description	Default
`name`	Server name (at least 2 characters)	`Servidor dos Amigos`
`password`	Join password. Empty, `none` or `clear` removes it	no password
`port`	TCP port, from 1024 to 65535	`3000`
`icon`	Path to an image, copied into the data directory. Empty or `clear` removes it	no icon
`maxUsers`	Maximum registered members. `0` removes the limit	`20`
`maxMessageLength`	Characters per message. `0` removes the character limit; the 8 MiB packet limit still applies	`16000`
`allowSoundboard`	Allows the soundboard (`true`/`false`). Turning it off also turns off the recent sounds cache	`true`
`allowEveryoneMention`	Allows `@everyone`/`@todos` in chat (`true`/`false`)	`true`
`maxAttachmentFileBytes`	Maximum size per attachment, in bytes. Cannot exceed the total storage	no limit
`maxAttachmentStorageBytes`	Total attachment storage, in bytes	no limit
`voiceMode`	Voice mode: `p2p` (direct mesh) or `sfu` (Selective Forwarding Unit)	`p2p`
`autoUpdate`	Enables the machine's automatic updates (`true`/`false`). See Automatic updates	`false`
`turn`	Enables the TURN media relay (`true`/`false`). Linux only, requires coturn installed	`false`
`trustedProxies`	IPs or networks (CIDR) of your reverse proxies, separated by commas. `none` turns it off. See Behind a reverse proxy	off

port, autoUpdate and trustedProxies can change while the server runs. Changing port or trustedProxies with the server running offers to restart right away, through the same path as monky restart: it warns people in a call, rewrites the PM2 registration and runs pm2 save, so the new port survives a reboot. The other keys live in the database and require the server to be stopped (see Changes while the server is running); they take effect on the next monky start.

Examples

bash

monky config show
monky config set name "Friends Server"
monky config set password           # typed hidden
monky config set password clear     # removes the password
monky config set maxUsers 50
monky config set autoUpdate true
monky config set turn true          # see "Media relay (TURN)" below
monky config set trustedProxies 127.0.0.1   # server behind a reverse proxy

Media relay (TURN)

By default Monky's voice and video travel straight between participants (P2P). When two members sit behind CGNAT, they cannot see each other and the call does not connect. TURN fixes it by having the server forward the media for that pair.

Full guide

See the dedicated TURN Relay page with detailed instructions on ports, firewalls (Oracle Cloud, AWS, iptables, ufw), verification and troubleshooting.

Enabling it

bash

monky stop
monky config set turn true
monky start

coturn is installed automatically from your distro. If the server does not run as root, run once: sudo bash scripts/install-turn.sh

Required ports

Port	Protocol	Purpose
`3478`	TCP and UDP	TURN signaling
`49152-65535`	UDP	Media relay

Must be open both in the Linux firewall and the provider's panel (Oracle Cloud, AWS, etc.).

Checking

bash

monky status    # should show ✔ accessible

In the monky status --watch dashboard, the TURN setting is read again only when the database changes (at most every 30 s), and the ports are checked every 60 s or as soon as TURN is turned on.

Disabling it

bash

monky stop
monky config set turn false
monky start

SFU Mode (Selective Forwarding Unit)

By default, Monky operates in P2P Mesh: each participant broadcasts audio and video directly to all other peers. However, streaming 1080p 60fps screen share to 20 users would require ~120 Mbps continuous upstream bandwidth from the host.

SFU mode centralizes media forwarding via mediasoup. The broadcaster uploads streams once to the host server, which forwards them to subscribers.

Enabling via CLI

bash

monky stop
monky config set voiceMode sfu
monky start

The CLI automatically computes and displays a capacity estimate based on available CPU cores, RAM, and upload speed.

Required ports for SFU

Port	Protocol	Purpose
`40000`	UDP and TCP	mediasoup worker WebRTC media port, shared by every call. If it is taken, the SFU uses the next free one of the `40000-49151` range; `monky status` and `monky config` show which

The range must be open in your server firewall (Oracle Cloud Security List, AWS Security Group, iptables/ufw) — on UDP and on TCP too, which is the way in for anyone on a network that blocks UDP. Ready-to-run commands and how to check them are in Opening the SFU mode ports.

`monky tls`: automatic secure connection

Makes the server also accept encrypted wss://, using a free Let's Encrypt certificate issued directly to the public IP, with no domain and no reverse proxy. It is what lets people join the server from the Monky web version. ws:// keeps working for whoever already uses it.

bash

monky tls            # shows the state: valid until, next renewal, last error
monky tls enable     # checks port 80 and enables
monky tls disable    # goes back to ws:// only

Requirements: a public IP and port 80/TCP open to the internet, besides the server port. Let's Encrypt validates the IP through port 80, which Monky opens only during the validation.
Precheck: before enabling, Monky asks Let's Encrypt's staging environment for a test certificate. If port 80 is not reachable, enabling is refused with the reason.
Linux without root: the system does not let an ordinary user open port 80. monky tls enable offers to allow it with sudo (writes net.ipv4.ip_unprivileged_port_start=80 to /etc/sysctl.d/60-monky-tls.conf). Without passwordless sudo, it prints the command for you to run once.
Renewal: the certificate lasts about 6 days and renews by itself 2 days before expiry, without disconnecting anyone. If the IP changes, a new certificate is issued. If renewal fails, the server keeps accepting ws://, warns in monky status and tries again.
Does not work over a VPN (Radmin, Hamachi, ZeroTier, Tailscale), CGNAT or a local network only: there the desktop app keeps connecting over ws://.
The change takes effect on the next monky start or monky restart; with the server running, the command offers to restart it.

Certificate shared between server and bots

The certificate lives in a machine-wide folder, ~/.monky/tls (change it with the MONKY_TLS_DIR variable), and is used by everyone: the server and any bot built with @monky/bot-sdk. Whoever enables TLS first issues the certificate; the others, when they run tls enable, just reuse the one that already exists for the machine's public IP, without asking Let's Encrypt for another. Each server or bot enables and disables on its own; tls disable never deletes the shared certificate.

Renewal: whoever has TLS enabled renews, and a lock file (renew.lock) ensures only one process renews at a time and only it opens port 80. The others see the renewed file within 1 minute and swap the certificate without restarting.
Migration: if the server already had a certificate at <data>/tls/certificate.json, it is copied to the shared folder the first time.

In bots

Every @monky/bot-sdk bot gets the same command (replace <bot> with your bot's command name):

bash

<bot> tls            # shows the state
<bot> tls enable     # reuses the shared certificate or issues a new one
<bot> tls disable    # this bot stops using TLS

In the bot's code:

const https = require('node:https');
const { createBotTls } = require('@monky/bot-sdk');

const tls = createBotTls({ dataDir: process.env.MONKY_BOT_HOME });
const material = tls.material(); // { cert, key }, or null if TLS is not enabled
const server = material ? https.createServer(material, handler) : http.createServer(handler);
tls.onChange(({ material }) => material && server.setSecureContext?.(material));
tls.start(); // renews and follows the shared file

`monky update`

Updates Monky to the latest published version.

bash

monky update [--beta] [--check] [--yes]

Options

Option	Description
`--beta`, `-b`	Also considers prereleases
`--check`	Only checks and exits, without updating
`--yes`, `-y`	Asks nothing — for scripts and the auto-updater

The command downloads and installs the new package with npm install -g from the GitHub release artifacts.

At the end the running servers are restarted (with confirmation, except with --yes): all of them on this machine, or only the --data one. Stopped servers stay stopped and use the new version on the next monky start.

So that a broken version cannot leave the server down:

Before restarting, the new CLI is run once. If it does not run on this machine (old Node, missing module), the previous version is reinstalled and no server is restarted.
Each server has its server.db copied to backups/ before the restart (the 3 most recent copies are kept) and must answer again within 60 seconds.
If the first server restarted onto the new version does not answer, the update is undone: the previous version is reinstalled, the database is restored from the copy when the new version had already migrated it, and the server comes back up. The command ends with an error to flag it, and monky logs shows why.

monky update never installs a version older than the current one. For example, someone on a beta newer than the latest stable does not get the stable one installed over it. Forcing a reinstall is only offered for the same version. Two updates on the same machine never run at once: the second waits for the first to finish.

Before disconnecting participants for that restart, the server reports that it is updating. Clients show a dedicated notice in their selected language and ask them to reconnect in a few seconds. This requires a running server process that already supports the notice; an older process still running during its first upgrade may send only the generic shutdown notice. Declining the restart neither disconnects participants nor sends an update notice.

Examples

bash

monky update --check           # is there a stable update?
monky update --check --beta    # and considering betas?
monky update                   # updates to the latest stable
monky update --beta            # updates to the latest, betas included

Automatic updates

bash

monky config set autoUpdate true

Registers a single PM2 schedule for the machine (monky-auto-updater) that runs monky update --yes: it installs the update once and restarts the servers that are running. A server stopped on purpose is not started. If a run finds a server still on the previous code (after a declined restart, for example), it restarts it with the same database copy and the same rollback on failure.

In a terminal, the CLI asks for the schedule: daily at an HH:MM time (default 04:00) or every 1 to 168 hours. Scripts get the daily 04:00 schedule. The channel follows the installed version: if you are on a beta, the auto-updater follows the beta channel. The script lives at ~/.monky/auto-update.cjs (or in the MONKY_HOME folder). Enabling auto-update replaces the per-server schedules created by older versions.

It works on Linux, macOS and Windows. To turn it off:

bash

monky config set autoUpdate false

`monky destroy`

Permanently deletes all data of a server.

bash

monky destroy [--data <folder>]

Removes the database, attachments, avatars and configuration, kills the PM2 process and drops the server from the registry. It asks for two confirmations: typing DESTROY and a final "yes". It only accepts folders that actually hold a Monky server.

Without a PM2 the CLI can use, the server's PM2 processes cannot be removed and would keep restarting the deleted server. In that case the warning names them, and a third confirmation asks whether to delete the data anyway; declining leaves everything as it was.

If anyone is connected, the warning shows up before the confirmations, saying how many people will be disconnected.

Monky CLI ​

Installation ​

Quick start ​

Multiple servers ​

CLI language ​

Global options ​

Data directory layout ​

Exit codes ​

Changes while the server is running ​

Command reference ​

monky create ​

Options ​

Examples ​

monky list ​

monky start ​

Options ​

monky stop ​

monky restart ​

monky status ​

Changing the Node version ​

Recommended procedure ​

monky logs ​

Options ​

Examples ​

monky members ​

monky admin ​

monky roles ​

monky config ​

Keys ​

Examples ​

Media relay (TURN) ​

Enabling it ​

Required ports ​

Checking ​

Disabling it ​

SFU Mode (Selective Forwarding Unit) ​

Enabling via CLI ​

Required ports for SFU ​

monky tls: automatic secure connection ​

Certificate shared between server and bots ​

In bots ​

monky update ​

Options ​

Examples ​

Automatic updates ​

monky destroy ​

See also ​

Monky CLI

Installation

Quick start

Multiple servers

CLI language

Global options

Data directory layout

Exit codes

Changes while the server is running

Command reference

`monky create`

Options

Examples

`monky list`

`monky start`

Options

`monky stop`

`monky restart`

`monky status`

Changing the Node version

Recommended procedure

`monky logs`

Options

Examples

`monky members`

`monky admin`

`monky roles`

`monky config`

Keys

Examples

Media relay (TURN)

Enabling it

Required ports

Checking

Disabling it

SFU Mode (Selective Forwarding Unit)

Enabling via CLI

Required ports for SFU

`monky tls`: automatic secure connection

Certificate shared between server and bots

In bots

`monky update`

Options

Examples

Automatic updates

`monky destroy`

See also