No Server, No Domain, No Cert: LangBot Cloud Puts a QQ Bot in a Group in Minutes
Many people who first want to put an AI bot into a QQ group start by searching for "how to deploy a bot." They usually stop right there: you need to buy a server, have a domain, apply for a certificate, install a runtime environment, keep a process alive, and go to some model platform to apply for a key. None of those steps is hard alone, but the six steps together are enough to kill the thought "I just want something in the group that can respond."
This article sets out to take apart which of those six steps are actually necessary. The conclusion up front: for the goal of "an AI in the group that can answer," most of them are other people's problems, not yours.
First, what having no server actually saves
Spread out "deploying a chatbot" from an operations viewpoint, and you see it forces you to solve five things at once, none of which has anything to do with what the bot says.
The first is a public endpoint. For group messages to reach your machine, your machine has to be somewhere externally findable. Home broadband doesn't have a fixed public address; many people get stuck here and start researching tunneling solutions, then discover the solution is harder to maintain than the bot itself.
The second is resident operation. A bot is a resident process. It has to stay awake and be ready when a message comes. Close your laptop, drop the network, or reboot, and it's gone. To make it truly "always on," you have to deal with startup on boot, restart on crash, and long-term maintenance.
The third is persistence. Personality settings, group configuration, and conversation context all have to be stored somewhere. In memory, a reboot wipes it; in files, you have to think about backups and migration.
The fourth is certificates. To deliver group messages to your service securely, encryption and renewal are a separate job. Self-signed certs aren't accepted by browsers or platforms, and applying and renewing is another process.
The fifth is model keys. The bot needs a model to generate replies, which usually means registering on another platform, doing real-name verification, getting a key, and managing quota.
What these five things have in common is that they are all operations, not "raising fish." What you want is that when someone @mentions it in the group, it answers properly; what you don't want is a "process exited" notification in the middle of the night.
The cloud folds five things into three items in an account
LangBot itself is an open-source IM AI bot platform, with its code public on GitHub, and you're fully free to deploy it yourself. That's its foundation, and it's the premise for judging all the suggestions that follow.
LangBot Cloud is the officially hosted version, entered at cloud.langbot.app. On this path, the five things above get folded into three items in your account.
Bot. It represents "the identity in the group." The QQ line uses the official QQ bot API, and binding is done by scanning a QR code, so you don't need to handle an external endpoint. The public endpoint and certificate issues disappear right here.
Pipeline. It defines how this fish thinks and speaks: which model to use, how to describe the personality, and what counts as a trigger. Resident operation and data storage land in this managed configuration; you don't have to care which machine it runs on.
Model quota. After logging in with a LangBot account, you can directly choose models from LangBot Models, such as deepseek-v4-flash and deepseek-v4-pro, and free quota is included. The fifth thing doesn't require a separate trip to another platform.
The login screen is just account plus password. No deployment, no pile of config fields. The psychological cost of this step matters more than the technical cost; it means you can see something running first, then decide whether to get serious.
The boundary of the free tier: 1 bot, 3 pipelines
The free tier is ¥0, with 1 bot and 3 pipelines. Read those two numbers carefully, because they decide how you should plan, not whether you should start.
1 bot means you raise one. You can put it in one group, or, following the official bot's capabilities, in multiple groups, but don't expect to run three different personalities at once.
3 pipelines means you can have combinations like "default chat," "one specific role," and "a spare experiment." It sounds small, but what most people actually need is just one.
I actually think this constraint is a good thing. I've seen too many people try to design a multi-role router at the start, and then fail to even write the personality for their first pipeline. Getting one pipeline written well beats figuring out how to scale first.
Group trigger with At only is a social decision
There's an option in settings for the trigger mode in group chats. The common temptation is to select everything; reply to every message so the bot looks active. Don't do that.
QQ groups have many people. If it responds to every sentence, noise will immediately drown out normal conversation, and every message burns model quota. Keeping only At means people know "it only speaks when @mentioned," so it won't interrupt or butt in while you're discussing something serious.
What this setting saves isn't money; it's other people's patience. A group tolerates a bot long-term not because the bot is smart.
The order in the interface
The whole path in the interface is fixed, with no branches:
Open cloud.langbot.app, log in with a LangBot account → choose a model from LangBot Models → create a pipeline and write the persona → set group trigger to At only → create a bot, choose the QQ official API adapter → scan the QR code with your phone QQ → enable → go back to the group and @ it to talk.
The only part requiring thought is writing the personality. There's no standard answer, but there's one piece of experience: writing "who you are, what style you speak in, and when to keep quiet" works better than a long list of "be smart, be professional, be empathetic." Models can't tell the difference from the latter; they can from the former.
When you should still build it yourself
Having written all that, I'll be clear that the cloud isn't a fix-all. There are three situations where self-hosting is genuinely more appropriate.
Data must stay on your own machine. If conversation content cannot leave your environment, then the hosted path doesn't hold; go to the repository and deploy from the docs.
Special network environments. Intranet, offline, or scenarios requiring a fixed egress address are things the hosted service can't help with.
Deep customization. Modifying source code, writing your own plugins, or connecting your own message channels is only possible when you run your own instance.
The standard for judgment is simple: if your goal is "an AI in the group that can answer," the cloud is enough; if your goal is "I want to control how it runs, where it runs, and what the code looks like," then build it yourself. These two aren't in conflict, and there's no hierarchy; they solve different problems.
Open source guarantees the latter always exists; hosting guarantees the former needs no barrier. This is also why I recommend most people start from hosting: confirm you really want to raise it first, then decide whether to build a fish tank for it.
The repository is here: langbot-app/LangBot, and the official site is at langbot.app. To try it directly, log in at cloud.langbot.app, configure it, and you can @ it in the group. Questions go in the comments.