Volcengine Plus Feishu Or Lark
Use this playbook when one Ark-family hosted provider should own the runtime and the next real surface should be a Feishu or Lark room. This page keeps the rollout honest:- Volcengine stays the hosted provider lane
- Feishu / Lark stays the shipped runtime-backed service channel
gateway runonly comes after the basicchannels serve feishuloop is healthy
When This Is The Right Playbook
- the base CLI path already works or is close to working
- the team already operates in Feishu or Lark
- you want a shipped inbound runtime, not just outbound notifications
- you want Volcengine to stay explicit instead of hiding it behind a proxy story
Use A Different Playbook If
| If you actually need… | Go here instead |
|---|---|
| WeCom as the primary enterprise lane | WeCom Rollout |
| BytePlus Coding plus a lightweight bot surface | BytePlus Coding Plus Telegram |
| one host supervising several already-healthy runtime-backed channels | Gateway Rollout |
Step 1: Bring Up The Hosted Provider
Step 2: Choose The Inbound Transport
Pick the transport on purpose:| Mode | Use it when | What changes |
|---|---|---|
websocket | the runtime should hold the inbound connection itself | fewer moving parts; no webhook verification material |
webhook | you explicitly want the platform to call a local bind and path you own | requires webhook verification material and a local listener |
websocket is the cleaner first lane.
Step 3: Single-Account Feishu Or Lark Runtime
Websocket example:domain = "lark"selects the Lark lane, whiledomain = "feishu"keeps the Feishu lane- webhook mode requires
verification_tokenandencrypt_key - websocket mode should not be documented as if webhook-only secrets were mandatory
allowed_chat_idsremains the trust boundary in both modes
Step 4: Smoke-Test Before Any Gateway Ownership
doctorsays the provider and channel prerequisites are healthychannels send feishuworks with the current accountchannels serve feishucan stay up cleanly and reply on the expected room boundary
Step 5: Add Named Accounts Before Selectors
Do not jump to--channel-account lark=work while the config is still
single-account. Selectors should target configured accounts.<id> entries.
Multi-account example:
Step 6: Choose Foreground Or Persisted Ownership
Foreground single-surface loop:channels serve feishu first during initial rollout. Use gateway run only after
the service loop already behaves correctly.
Troubleshooting
| Symptom | What to check |
|---|---|
runtime models list fails before the channel even matters | fix the Volcengine provider lane first; do not debug the channel before the hosted path is healthy |
| websocket setup still asks for webhook-only material | the config shape is wrong; websocket mode should not depend on verification_token or encrypt_key |
gateway run --channel-account lark=work fails on a single-account config | add default_account and accounts.work first, or run gateway run without a selector |
| sends work but the runtime replies in the wrong room | review allowed_chat_ids and receive_id_type before changing gateway ownership |
| you are not sure whether the runtime is actually owned | run loong gateway status --json from another process |
Continue Reading
- Continue to Common Setups for other end-to-end rollout shapes.
- Continue to Channel Guides for the full shipped channel matrix.
- Continue to Channel Recipes for the tutorial-style channel recipe set.
- Continue to Gateway And Supervision for the owner contract and selector rules without the playbook framing.