The gateway now ships in the
praisonai-bot package. praisonai serve gateway still works exactly as documented here; for a standalone install see praisonai-bot Migration.bot.yaml and BotOS platforms: configs to the canonical GatewayConfigSchema at load time — praisonai doctor reports migration opportunities so you can persist them.
praisonai doctor; migration reports legacy bot.yaml or BotOS configs and normalises them to the gateway schema at load time.
How It Works
Quick Start
Detect legacy format
Migration Table
Single-bot → multi-channel
Before (legacybot.yaml):
BotOS platforms: → channels:
Before:
String allowed_users → list
Before:
Behaviour Notes
BotYamlSchemais an alias ofGatewayConfigSchema— existing Python imports keep working.group_policydefaults tomention_onlyfor new channels without an explicit value. Configs that explicitly setrespond_allkeep that value.- Comma-separated
allowed_usersstrings are auto-converted to lists at load time. - All three YAML shapes (
platform+token,agents+channels,platforms:) validate against one schema — see Gateway.
Best Practices
Run doctor before upgrading
Run doctor before upgrading
Use
praisonai doctor --only gateway_config_migration after pulling a new PraisonAI release to see whether your persisted YAML can be simplified.Persist canonical YAML when WARN appears
Persist canonical YAML when WARN appears
Runtime auto-migration is transparent, but persisting the canonical
channels: form makes configs easier to diff and review in PRs.Keep explicit group_policy values
Keep explicit group_policy values
group_policy defaults to mention_only for new channels only. If your bot should respond to every message, set respond_all explicitly rather than relying on legacy defaults.Convert allowed_users to lists
Convert allowed_users to lists
Comma-separated strings still load, but list form is clearer and matches the schema validators.
Related
Gateway
Full gateway and channel configuration reference
Doctor
Gateway doctor checks and remediation

