Common Setups
Use this page whenonboard, ask, or chat already makes sense and you want
one practical setup shape instead of reading provider, channel, and gateway
pages separately.
This page is now the setup hub, not another long cookbook. The detailed
operational steps live in dedicated playbooks.
If you want the shared public config shape before you pick a playbook, start
with Configuration Patterns.
Start With The Common Cases
These playbooks cover a few repeatable rollout shapes. They are representative paths, not the full support matrix. Use Provider Guides and Channel Guides when you want the broader family-by-family map instead of one end-to-end playbook. Keep Provider Recipes and Channel Recipes for representative patterns. All routes here stay inside the current public contract:- managed-bridge-capable service channels currently surface to operators as Feishu / Lark, Telegram, Matrix, WhatsApp, and WeCom
- outbound-only surfaces stay outbound-only
gateway runremains the explicit owner contract for longer-lived service supervision- grouped operator shells such as
runtime,channels, andgatewayare the canonical docs surface
Choose A Playbook
If you still just need one provider to work locally, go back to
First Run and
Provider Guides instead of treating this
hub like a provider-only guide.
Shared Validation Loop
Use the same short loop after each setup slice:gateway status --json for the shortest ownership-specific view and status --json for the broader operator summary across gateway, ACP, and work-unit surfaces.
Reading Rules
- Start with the base CLI path first. Do not treat a channel or gateway setup as step zero.
- Use Configuration Patterns when the rollout is clear but you still want the shared provider, account, and memory shape before a playbook.
- Use a dedicated playbook when the rollout shape is already clear.
- Use provider-only or channel-only recipe pages when the setup is still narrow.
- Move to gateway selectors only after named
accounts.<id>entries exist.