No Server, No Domain, No Cert: LangBot Cloud Puts a QQ Bot in a Group in Minutes
Most QQ bot projects die at the deployment step, and this hosted route lets a developer go from login to a replying bot without touching a server, a domain, or a certificate. The same pattern applies to any chat platform with an official API: the infrastructure that used to gate hobby bot development is now a managed service.
Deploying a chat bot normally demands a public endpoint, a resident process, persistence, certificates, and a model key; every one of those is ops work that has nothing to do with what the bot says. LangBot Cloud removes all five: the QQ line hooks into the official bot API via QR code binding, the pipeline holds model choice and personality, and model quota comes from LangBot Models with free tier included.
The free tier is ¥0 for one bot and three pipelines, which the author argues is a feature, not a limit, because most people only need one good pipeline. The console's only real thinking task is writing the persona, and the advice there is concrete: state who the bot is, its speaking style, and when to stay silent, rather than piling on adjectives like "smart" and "professional." The At-only trigger is a social decision as much as a technical one, saving group patience and quota.
Self-hosting still makes sense when data must stay on-premises, the network is isolated or offline, or the bot needs source-level customization. Open source keeps the self-host path alive; the hosted path lowers the entry barrier. The author's rule: if the goal is "an AI in the group that answers," the cloud is enough; if the goal is controlling how and where it runs, build your own.
The one-bot, three-pipelines limit is a useful guardrail; it forces a developer to ship one working pipeline before designing a multi-role routing system that usually never gets finished.
The hardest part of the hosted setup is writing the persona, not deploying; that shift shows where the actual value of a bot lies once infrastructure is commoditized.
Choosing At-only trigger is framed as a social decision, which points to a real dynamic: groups tolerate dumb bots better than chatty ones.
Treating 'cloud vs self-host' as two answers to different questions, rather than as a hierarchy, is a more practical stance than most deployment guides take.