Multi-instance daemon isolation
Short answer Verified Answer #1
As of August 8, 2026, the useful invariant is not merely “one process per Linux host”; it is: Verified Answer #1
one owner per mutable local state tree; Verified Answer #1
one listener per socket address within a network namespace; and Verified Answer #1
one authoritative consumer/responder per remote messaging identity, unless the daemon explicitly implements active-active coordination. Verified Answer #1
Per-instance containers solve the first two classes only when each container has a private network namespace and private persistent volumes. Verified Answer #1
They do not solve collisions keyed by an external identity—such as a Telegram bot token, a WhatsApp or Signal device registration, or a Discord bot/shard—or semantic split brain where two gateways independently process the same conversation. Verified Answer #1
OpenClaw’s current documentation contains the architectural shorthand “one Gateway per host,” but it also documents supported multiple-Gateway deployment through isolated profiles. Verified Answer #1
Read together, the intended rule is: normally use one Gateway for multiple agents and channels; use multiple Gateways only with unique config, state, workspace, base port, derived browser ports, service identity, and channel credentials or ownership. Verified Answer #1
OpenClaw now enforces exclusive ownership of a state directory even when its config-level singleton check is disabled. (docs.openclaw.ai) Verified Answer #1
Concrete local resource conflicts Verified Answer #1
1.1 TCP/UDP listener ports Verified Answer #1
A second daemon cannot normally bind the same protocol, local address, and port in the same Linux network namespace; bind(2) returns EADDRINUSE. Verified Answer #1
OpenClaw’s Gateway multiplexes its WebSocket control plane, HTTP APIs, UI, hooks, and plugin HTTP routes on one base port—default 127.0.0.1:18789. Verified Answer #1
OpenClaw also derives a browser-control port at base +2 and allocates browser CDP ports from a range above that, so changing only the visible Gateway port may still leave secondary collisions if the derived ranges overlap. Verified Answer #1
OpenClaw recommends leaving at least 20 ports between bare-host Gateway base ports. (man7.org) Verified Answer #1
Container result: Verified Answer #1
With normal bridge networking, each container has its own network namespace and can bind internal 18789, 8080, 8787, and similar ports independently. Verified Answer #1
If access from the host is needed, each container still needs a distinct published host port, for example: Verified Answer #1
instance A: 127.0.0.1:18789 -> container:18789 Verified Answer #1
instance B: 127.0.0.1:19789 -> container:18789 Verified Answer #1
network_mode: host removes this benefit: both containers then share the host’s port space, and the original bind conflict returns. Verified Answer #1
Publishing the same host address and host port twice is still a collision even though the internal container ports are isolated. (docs.docker.com) Verified Answer #1
Daemon support required: only if the instances share a network namespace—for example, bare processes, containers in host-network mode, or services that must publish separate directly bound ports. Verified Answer #1
OpenClaw already supplies --port, OPENCLAW_GATEWAY_PORT, gateway.port, and named profiles. (docs.openclaw.ai) Verified Answer #1
1.2 Unix-domain sockets Verified Answer #1
There are two distinct cases: Verified Answer #1
A pathname Unix socket, such as /run/agent.sock, is a filesystem object. Verified Answer #1
A second bind to the same existing path fails with EADDRINUSE. Verified Answer #1
A Linux abstract Unix socket belongs to the network namespace rather than the filesystem namespace. Verified Answer #1
Therefore: Verified Answer #1
A private container network namespace isolates abstract sockets. Verified Answer #1
A private container filesystem/mount namespace isolates pathname sockets. Verified Answer #1
If two containers bind-mount the same /run, state directory, or socket directory, a pathname-socket collision remains. Verified Answer #1
A network namespace alone does not isolate a pathname socket stored on a shared filesystem. (man7.org) Verified Answer #1
This distinction matters for sidecars such as signal-cli, browser controllers, local RPC bridges, or plugins that use Unix sockets rather than TCP. Verified Answer #1
1.3 Config, state, lock, PID, cache, and database paths Verified Answer #1
For OpenClaw, the important local locations are separate concepts: Verified Answer #1
OPENCLAW_CONFIG_PATH: configuration file; Verified Answer #1
OPENCLAW_STATE_DIR: sessions, credentials, caches, locks, and mutable runtime state; Verified Answer #1
agents.defaults.workspace: the agent’s working files, memory, skills, repository, and related material; Verified Answer #1
browser profile/user-data and CDP settings; Verified Answer #1
channel-specific authentication directories, such as WhatsApp auth state or signal-cli account data. Verified Answer #1
Current OpenClaw does not merely risk accidental corruption when two Gateways share a state directory: it deliberately fails startup. Verified Answer #1
It uses a state-ownership lock, a config lock, a SQLite coordinator for lock metadata, and finally an exclusive listener bind. OPENCLAW_ALLOW_MULTI_GATEWAY=1 skips only the per-config singleton; it does not authorize shared mutable state. (docs.openclaw.ai) Verified Answer #1
For a generic daemon without such safeguards, sharing a state directory can produce: Verified Answer #1
database-lock errors or overlapping migrations; Verified Answer #1
lost updates from read-modify-write operations; Verified Answer #1
one instance overwriting the other’s tokens, offsets, or reconnect watermark; Verified Answer #1
log and temporary-file interleaving; Verified Answer #1
stale PID/lock interpretation; Verified Answer #1
credential leakage between supposedly separate workspaces; Verified Answer #1
two daemons independently rotating or deleting the same channel credentials. Verified Answer #1
The exact failure may be a clean lock error rather than corruption, depending on the database and application. Verified Answer #1
It is therefore inaccurate to say that shared SQLite state necessarily corrupts; OpenClaw specifically prevents concurrent ownership before destructive maintenance can race. (docs.openclaw.ai) Verified Answer #1
Container result: a private writable layer or, preferably, a distinct named volume per instance can make a daemon’s hardcoded path private without any code change. Verified Answer #1
Docker gives each container a unique writable layer, while persistent named volumes can be mounted separately at the same internal pathname. Verified Answer #1
If both containers are deliberately given the same volume or host bind mount, containerization has not isolated the data. (docs.docker.com) Verified Answer #1
Daemon support required: Verified Answer #1
Not strictly required when each instance is in a separate container and may use the same hardcoded internal pathname. Verified Answer #1
Required for clean bare-host operation, where the daemon needs profile-, CLI-, or environment-controlled config/state paths. Verified Answer #1
Required when operational tools, health checks, upgrades, or supervisors must identify the correct instance rather than merely run two opaque containers. Verified Answer #1
OpenClaw supplies --profile, OPENCLAW_CONFIG_PATH, OPENCLAW_STATE_DIR, and workspace configuration, and profile-specific systemd service names. (docs.openclaw.ai) Verified Answer #1
1.4 Shared workspace roots Verified Answer #1
Separating OPENCLAW_STATE_DIR is insufficient if two Gateways still point at the same writable workspace. Verified Answer #1
Both may edit the same repository, memory files, generated artifacts, skills, or agent instruction files. Verified Answer #1
This may be intentionally collaborative, but it is no longer isolated and requires normal multi-writer coordination such as source-control discipline, file locking, or application-level serialization. Verified Answer #1
OpenClaw’s multiple-Gateway checklist therefore calls out agents.defaults.workspace independently from state and config. Verified Answer #1
Its normal design is instead to run multiple agents with distinct workspaces and sessions under one Gateway. (docs.openclaw.ai) Verified Answer #1
Container result: solved only if the workspace is a private volume or private bind-mount target. Verified Answer #1
Mounting the same host repository into both containers merely recreates the shared-workspace problem. Verified Answer #1
1.5 Derived services, browser profiles, and external local daemons Verified Answer #1
OpenClaw’s base port drives derived browser-control and CDP ports. Verified Answer #1
A separately configured browser.cdpUrl may also point both Gateways at the same browser process or profile. Verified Answer #1
Containers isolate an internally launched browser if each gets a private network namespace and browser-data volume, but they do not isolate a shared remote Chrome endpoint. Verified Answer #1
OpenClaw explicitly requires unique CDP ports/ranges and warns against pinning multiple Gateways to the same browser.cdpUrl. (docs.openclaw.ai) Verified Answer #1
The same principle applies to signal-cli, local model servers, callback receivers, and plugin webhooks: containerization solves the listener address and local files only if the dependency is also instance-local. Verified Answer #1
A single external daemon remains shared. Verified Answer #1
Messaging-channel identity and session conflicts Verified Answer #1
A crucial distinction is between: Verified Answer #1
local credential-file collision—two processes opening the same files; Verified Answer #1
remote device/session collision—two processes presenting the same cryptographic or API identity to the provider; and Verified Answer #1
semantic split brain—two valid sessions independently processing and responding to the same user conversation. Verified Answer #1
Containers solve only the first. Verified Answer #1
In fact, containers can hide local lock files and allow both daemons to start, thereby converting an obvious startup failure into a less obvious remote or semantic collision. Verified Answer #1
2.1 WhatsApp Verified Answer #1
OpenClaw’s WhatsApp plugin uses Baileys. Verified Answer #1
The Gateway owns each linked WhatsApp socket and reconnect loop. Verified Answer #1
OpenClaw supports account-specific auth directories and its current configuration exposes accounts.<id>.authDir; its conventional credentials are stored per account under the Gateway state tree. (docs.openclaw.ai) Verified Answer #1
There are three cases: Verified Answer #1
A.
Two instances share the same auth directory Verified Answer #1
This is a direct filesystem collision. Verified Answer #1
Baileys auth state includes credentials and cryptographic key/session material that changes as messages are sent and received; Baileys requires those key updates to be persisted. Verified Answer #1
Concurrent writers can therefore race, overwrite one another’s newer key state, or leave one process operating from stale state. (github.com) Verified Answer #1
Containerization fixes this only by giving each instance a different persistent auth volume. Sharing the same auth bind mount does not fix it. Verified Answer #1
B.
The same auth directory is copied into two separate volumes Verified Answer #1
The file race disappears, but the copies still represent the same linked-device identity rather than two independently linked WhatsApp devices. Verified Answer #1
Because both copies can evolve their cryptographic state independently, treating this as active-active operation is unsafe unless Baileys/OpenClaw explicitly supplies a shared transactional credential backend and connection-ownership protocol. Verified Answer #1
This conclusion is an inference from Baileys’ requirement to persist continuously changing auth-key state. (github.com) Verified Answer #1
Containerization does not turn copied credentials into separate device registrations. Verified Answer #1
C.
Each instance is independently QR-linked Verified Answer #1
Each instance then has genuinely separate local device credentials. Verified Answer #1
That removes the cloned-device collision, subject to WhatsApp’s linked-device policies and limits. Verified Answer #1
It does not, however, decide which agent should respond when both devices expose the same account’s conversations. Verified Answer #1
If both Gateways are configured as responders, duplicate actions or divergent conversational state become possible. Verified Answer #1
The safe choices are: Verified Answer #1
use different WhatsApp accounts/numbers per Gateway; Verified Answer #1
use one Gateway’s built-in multi-account support and deterministic routing; Verified Answer #1
or add an upstream single-owner/leader or ingress-routing mechanism if the same account must be redundant. Verified Answer #1
A container alone provides none of that ownership logic. Verified Answer #1
2.2 Telegram Verified Answer #1
For Telegram bots, the remote identity is principally the bot token, and receiving updates has provider-enforced ownership semantics. Verified Answer #1
OpenClaw uses long polling by default and explicitly guards one active poller per token inside a Gateway. Verified Answer #1
A persistent getUpdates HTTP 409 means another Gateway, script, or poller is already using that token. Verified Answer #1
Telegram’s Bot API also defines long polling and webhooks as mutually exclusive: while a webhook is installed, getUpdates cannot receive updates. Verified Answer #1
There is one current webhook configuration for a bot token, so setting a new webhook changes the provider-side destination rather than creating a second independent subscription. (docs.openclaw.ai) Verified Answer #1
Thus: Verified Answer #1
Different Telegram bot tokens: separate containers work normally, assuming private state and host-port mappings. Verified Answer #1
Same token, two long pollers: containerization does not help; one poller conflicts with the other rather than receiving a clean partition of updates. Verified Answer #1
Same token, two webhook instances: Telegram still sends to the single configured webhook URL. Verified Answer #1
A reverse proxy may load-balance that URL, but then the receiving application needs shared durable deduplication, ordering, session state, and idempotency. Verified Answer #1
One polling instance plus one webhook instance: provider rules make those modes mutually exclusive. Verified Answer #1
Correct resolutions are: Verified Answer #1
a unique bot token per independent Gateway; Verified Answer #1
one authoritative Telegram ingress process that dispatches internally; Verified Answer #1
or upstream HA support with leader election, shared update offsets/queues, and idempotent processing. Verified Answer #1
Simple path or network isolation is insufficient. Verified Answer #1
2.3 Signal Verified Answer #1
OpenClaw talks to signal-cli, normally over an HTTP daemon endpoint. Verified Answer #1
The documented default is 127.0.0.1:8080; signal-cli itself also supports TCP and Unix-socket JSON-RPC endpoints. Verified Answer #1
Its account keys and local configuration live in its data directory, and signal-cli has historically locked that storage to prevent parallel access. (docs.openclaw.ai) Verified Answer #1
Local conflicts therefore include: Verified Answer #1
two managed signal-cli daemons binding the same HTTP/TCP port; Verified Answer #1
two daemons trying to create the same Unix socket; Verified Answer #1
two processes loading the same account data directory; Verified Answer #1
one OpenClaw instance connecting to the other instance’s signal-cli endpoint by mistake. Verified Answer #1
Containers can solve all of these local conflicts if each container has its own network namespace, Signal data volume, and endpoint. Verified Answer #1
On a bare host, the daemon needs configurable data paths, accounts, and HTTP/socket ports. Verified Answer #1
Current OpenClaw provides per-account transport ownership and multi-account configuration. (docs.openclaw.ai) Verified Answer #1
For the remote account, Signal distinguishes linked devices. Verified Answer #1
Signal currently permits up to five linked devices per phone, and signal-cli link creates a new linked device with its own local keys. Verified Answer #1
Therefore the correct way to run two Signal endpoints on one account is to link each independently, not to copy one signal-cli data tree. (github.com) Verified Answer #1
Even independently linked Signal devices do not establish agent-level routing ownership. Verified Answer #1
If both Gateways receive the same conversation and are allowed to answer it, they can produce duplicate responses and divergent local histories. Verified Answer #1
A separate bot number avoids that class of ambiguity, which is also OpenClaw’s recommended setup. (docs.openclaw.ai) Verified Answer #1
2.4 Discord Verified Answer #1
Discord differs materially from Telegram: multiple Gateway WebSocket sessions using the same bot token are supported by Discord, including multiple sessions with the same shard tuple. Verified Answer #1
Discord documents this as useful for orchestration and zero-downtime transitions. Verified Answer #1
Therefore claims that a second Discord process necessarily “kicks out” the first through a heartbeat conflict are incorrect. (docs.discord.com) Verified Answer #1
But two uncoordinated OpenClaw Gateways using the same bot token still create semantic and quota conflicts: Verified Answer #1
sessions covering the same shard can receive the same guild events; Verified Answer #1
both agents may answer the same message, creating duplicate replies; Verified Answer #1
each Gateway maintains a separate OpenClaw conversation history and may make a different tool or model decision; Verified Answer #1
slash-command deployment, presence, and configuration writes can race or repeatedly overwrite the same application state; Verified Answer #1
the sessions share the bot’s Discord session-start and Identify budgets; Verified Answer #1
reconnect storms from several instances can consume those shared budgets. Verified Answer #1
Those consequences follow from Discord allowing overlapping sessions while the OpenClaw instances have no shared event-ownership or session-state layer. Verified Answer #1
Discord imposes Identify concurrency and daily session-start limits, and OpenClaw treats each Gateway as owning its Discord connection. (docs.discord.com) Verified Answer #1
OpenClaw does prevent duplicate token use within one Gateway: if two enabled Discord account entries resolve to the same token, it starts only one monitor and disables the duplicate account entry. Verified Answer #1
Separate Gateway processes or containers cannot see that in-process deduplication and therefore do not coordinate with each other. (docs.openclaw.ai) Verified Answer #1
Correct resolutions are: Verified Answer #1
distinct Discord applications/bot tokens per independent Gateway; Verified Answer #1
explicit Discord shard allocation across instances; Verified Answer #1
or upstream leader election/event partitioning, shared idempotency, and shared or consistently partitioned OpenClaw session state. Verified Answer #1
Containerization enables multiple Discord connections but does not make their behavior coherent. Verified Answer #1
Containerization versus upstream support: decision matrix Verified Answer #1
| Conflict | Per-instance containerization | Upstream daemon support still needed? | |---|---|---| | Same internal TCP/UDP port | Yes, with separate network namespaces | Only if using bare processes, host networking, or different direct listener ports | | Same published host port | No | Usually an orchestrator mapping issue; each published host port/address must be unique | | Abstract Unix socket name | Yes, with separate network namespaces | No, unless namespaces are shared | | Pathname Unix socket | Yes, only with separate filesystem/mount views | Configurable socket paths needed if a directory is shared | | Same PID namespace/process name | Usually yes | Host supervisor/container names still need unique identities | | Same OpenClaw config path | Yes, if each container has a private copy | Profile/config-path support needed for bare-host processes and clean administration | | Same OpenClaw state directory | Yes, with different persistent volumes | Current OpenClaw requires unique state ownership; shared state is not enabled by a flag | | Same writable workspace | Only with distinct mounts | Shared workspaces require synchronization or native multi-agent routing | | Derived browser/CDP ports | Yes for container-local browsers | Unique config required for host/remote browsers or pinned CDP URLs | | Same WhatsApp/Signal auth files | Yes, for the file collision only | Each instance still needs its own real device registration or account-scoped credentials | | Copied WhatsApp/Signal device state | No | Requires supported shared credential/state architecture; preferably re-link as distinct devices | | Same Telegram bot token | No | Unique token, single ingress owner, or leader-election/queue support | | Same Telegram webhook | No | One externally registered endpoint plus internal load balancing and deduplication | | Same Discord bot token | Containers allow it, but do not coordinate it | Unique tokens, explicit sharding, or event ownership/idempotency support | | Same channel conversation with separate local state | No—containers create split brain | Shared/partitioned session state and one-response ownership are required | | Provider/token/IP rate limits | Generally no; bridge containers usually share host egress | Rate-limit coordination, proxy/egress controls, and token-aware backoff may be needed | Verified Answer #1
The most important distinction: configuration support versus HA architecture Verified Answer #1
There are two very different meanings of “upstream support.” Verified Answer #1
Ordinary per-instance configuration Verified Answer #1
This is enough when every Gateway has a genuinely separate channel identity. Verified Answer #1
The daemon needs fields or environment variables for: Verified Answer #1
base port and all derived ports; Verified Answer #1
config path; Verified Answer #1
state directory; Verified Answer #1
workspace root; Verified Answer #1
channel account ID; Verified Answer #1
auth/session directory; Verified Answer #1
Signal daemon URL/port/socket; Verified Answer #1
Telegram and Discord tokens; Verified Answer #1
webhook public URL/path; Verified Answer #1
supervisor/service identity. Verified Answer #1
OpenClaw currently provides most of these through profiles, account maps, transport settings, and account-scoped auth directories. (docs.openclaw.ai) Verified Answer #1
A container can compensate for missing path and internal-port configurability by presenting the same hardcoded locations in separate namespaces. Verified Answer #1
It cannot compensate for a daemon that cannot accept different channel credentials at all. Verified Answer #1
Active-active support for one external identity Verified Answer #1
This is a much larger feature. Verified Answer #1
It generally requires: Verified Answer #1
a distributed lease or leader election for each channel account, bot token, shard, or conversation; Verified Answer #1
a durable ingress queue with atomic claiming; Verified Answer #1
provider update-offset or webhook ownership coordination; Verified Answer #1
message-ID idempotency and outbound deduplication; Verified Answer #1
shared or consistently partitioned conversation/session state; Verified Answer #1
coordinated credential/key rotation; Verified Answer #1
provider-aware reconnect and rate-limit budgets; Verified Answer #1
failover rules that prevent an old owner and new owner from responding simultaneously. Verified Answer #1
No namespace supplies these semantics. Verified Answer #1
This must exist in the daemon, a dedicated channel-ingress layer, or an external orchestration/control plane. Verified Answer #1
OpenClaw’s current multi-tenant container system explicitly does not provide shared channel accounts or a shared inbound router; each isolated cell owns its own channel accounts. (docs.openclaw.ai) Verified Answer #1
Safe deployment patterns Verified Answer #1
Pattern A: multiple independent identities Verified Answer #1
This is the easiest and is largely solved by containers: Verified Answer #1
one private state volume per Gateway; Verified Answer #1
one private workspace volume per Gateway; Verified Answer #1
same internal Gateway port, different host-published ports; Verified Answer #1
different Telegram bot tokens; Verified Answer #1
different Discord applications/tokens; Verified Answer #1
different WhatsApp/Signal accounts, or independently linked devices where duplicate conversation handling is intentionally prevented; Verified Answer #1
no shared WhatsApp auth directory or signal-cli data directory. Verified Answer #1
No native multi-tenant mode is strictly necessary if each container runs one identity and receives its one credential through its environment or private config. Verified Answer #1
Pattern B: bare-host multiple Gateways Verified Answer #1
Use OpenClaw’s named-profile support, for example conceptually: Verified Answer #1
bash openclaw --profile main gateway --port 18789 openclaw --profile ops gateway --port 19789 Verified Answer #1
Each profile must resolve to a separate config, state tree, workspace, service, and channel account. Verified Answer #1
The larger port separation also avoids derived browser/CDP overlap. (docs.openclaw.ai) Verified Answer #1
Pattern C: cold standby for the same messaging identity Verified Answer #1
Containers are useful for packaging, but only one instance should actively connect. Verified Answer #1
Failover requires a lease or fencing mechanism so the old instance is definitely inactive before the standby starts. Verified Answer #1
Simply leaving both containers running and hoping the provider selects one is not safe. Verified Answer #1
Pattern D: active-active for the same identity Verified Answer #1
Do not treat this as a containerization problem. Verified Answer #1
Use: Verified Answer #1
one channel-ingress owner with downstream work distribution; Verified Answer #1
Discord-aware sharding where applicable; Verified Answer #1
or daemon-native clustered ownership and shared session/idempotency support. Verified Answer #1
Without those features, isolation changes a local collision into remote split brain. Verified Answer #1
Conclusion Verified Answer #1
Per-instance containers are sufficient for namespace-keyed conflicts: internal ports, abstract sockets, pathname sockets on private filesystems, PID/process trees, hardcoded config paths, state directories, channel credential files, and local sidecar ports. Verified Answer #1
They are sufficient only if volumes and network namespaces are actually separate; host networking and shared bind mounts negate the isolation. Verified Answer #1
Upstream configuration is needed for clean instance differentiation: profiles, config/state/workspace overrides, channel-account credentials, auth directories, webhook paths, Signal transport endpoints, service names, and derived browser ports. Verified Answer #1
Current OpenClaw supplies these facilities and explicitly supports isolated multiple-Gateway profiles. (docs.openclaw.ai) Verified Answer #1
Upstream architecture—not merely configuration—is required when two instances use the same external messaging identity: Telegram needs a single poller or webhook owner; copied WhatsApp/Signal device state is not a second registration; separately linked devices still need one-response routing; and overlapping Discord sessions need explicit sharding, leader election, or deduplication. Verified Answer #1
Containerization cannot alter the token, device keys, provider-side webhook, event stream, or conversational ownership seen by the remote platform. Verified Answer #1
A concise operational rule is therefore: Verified Answer #1
**Give every Gateway a private config, state tree, workspace, listener namespace, and channel identity. Verified Answer #1
If any channel identity is shared, assume containerization is insufficient until the daemon documents explicit clustered ownership for that channel.** Verified Answer #1
Principal sources Verified Answer #1
OpenClaw. (2026). Multiple gateways; Gateway lock; Gateway architecture; Multi-tenant hosting. (docs.openclaw.ai) Verified Answer #1
Linux man-pages. (2026). bind(2), unix(7), and network_namespaces(7). (man7.org) Verified Answer #1
Docker. (2026). Port publishing and mapping; Storage; Host network driver. (docs.docker.com) Verified Answer #1
Telegram. (2026). Telegram Bot API and Bots FAQ. (core.telegram.org) Verified Answer #1
Discord. (2026). Gateway documentation. (docs.discord.com) Verified Answer #1
Signal Support; AsamK. (2026). Linked Devices; signal-cli manual. (github.com) Verified Answer #1
WhiskeySockets. (2026). Baileys README—auth-state persistence. (github.com) Verified Answer #1
Sources: [1] Gateway architecture - OpenClaw [2] bind(2) - Linux manual page [3] Port publishing and mapping | Docker Docs [4] Configuration reference - OpenClaw [5] network_namespaces(7) - Linux manual page [6] Gateway lock - OpenClaw [7] Storage | Docker Docs [8] Multiple gateways - OpenClaw [9] WhatsApp - OpenClaw [10] Baileys/README.md at master · WhiskeySockets/Baileys · GitHub [11] Telegram - OpenClaw [12] Signal - OpenClaw [13] signal-cli/man/signal-cli.1.adoc at master · AsamK/signal-cli · GitHub [14] Gateway - Documentation - Discord [15] Discord - OpenClaw [16] Multi-tenant hosting - OpenClaw [17] Bots FAQ Verified Answer #1