How to Self-Host a Free AI Chatbot That Remembers Your Conversations

Why Self-Host at All

Lately, “letting your AI run in the background and grow over time” has become a popular trend in the dev community: developers connect a server-side agent to group chats, keep it online around the clock, let it retain conversation history, and even give it accumulating “memory.” Under the hood, this is essentially a self-hosted agent gateway: a resident process running on your own server that connects to a messaging platform’s bot API on one side and a cloud LLM inference service on the other.

These projects differ significantly from typical app templates. They are not “fill in a few parameters and hit run” managed apps—the deployment flow deliberately keeps several steps that must be completed manually: risk confirmation, model authentication, and platform credential binding. Every one of these steps involves secrets and security boundaries, so full automation is unrealistic. That’s exactly why many first-time deployments get stuck. This article walks through each of these steps in detail.

Three core benefits of self-hosting:

1. Data control: conversations and memory are stored on your own server, with no third-party relay;
2. Cost control: the gateway itself comes from the open-source ecosystem and is free to use; the model side is billed by usage, so personal use costs very little;
3. Full customization: persona, memory strategy, and reply style are all adjustable.

Understand the Architecture First: What Exactly Are You Deploying?

Before getting hands-on, look at the three-layer structure—every later configuration step maps onto it:

[Chat platform side]              [Your server]                  [Model side]
 Group/private messages  ───►  Resident gateway process   ───►  LLM inference API
 Platform bot app               (messaging, dispatch,             (generates replies)
                                 memory storage)
        ◄── message callbacks ────────┘◄───────────────

Three key takeaways:

• The gateway does no inference. It only handles message routing, context management, and memory storage; actual text generation happens on the model side. Server requirements are therefore minimal—an entry-level cloud server (such as a low-spec instance from Baidu AI Cloud) is enough, and an idle VM works too.
• A stable egress IP is mandatory. Chat platforms generally require callers to be IP-whitelisted, and a frequently changing IP will get calls rejected. Home broadband connections, with their dynamic egress IPs, are usually unsuitable.
• The model side only needs a working account. Inference costs scale with conversation volume and are negligible for personal use.

Environment Checklist

Confirm four things before starting:

1. A Linux server: any mainstream distro works, as long as systemd is the init system (the troubleshooting section later relies on its user-level service capabilities);
2. SSH access: you can log in remotely as a regular user and run commands;
3. An LLM service account: any provider you already have an account with, used for model-side authentication;
4. A developer account on your messaging platform: personal registration is fine; self-hosted personal use doesn’t require business credentials.

Run the Onboarding Wizard: Your First Configuration

After your first SSH login, run the initialization command given in your framework’s documentation (usually something like <cli> onboard) and press Enter to start the interactive setup wizard.

The first step is risk confirmation: the wizard explicitly asks whether you understand the risks of self-hosting; confirm to proceed. This step exists because the process will run resident, send and receive messages externally, and hold platform keys—the framework needs to draw the security and compliance responsibility boundary clearly. It’s a responsible design, not bureaucratic friction.

The second step is choosing a configuration mode. The wizard typically offers “QuickStart” and “full customization” modes. For a first deployment, pick QuickStart: it uses a proven set of defaults to get the pipeline working first, leaving fine-tuning for later. In engineering practice, “get it working, then optimize” always beats “try to configure everything perfectly the first time”—and when something breaks, the troubleshooting surface stays small.

Configure the Model: Authentication and Selection Tips

Next, the wizard moves to model configuration. Pick any model from the list; you can switch later at any time.

If the selected model supports web-based authentication, the wizard will present an authorization page—log in and approve, and the binding is done with no copy-pasting of key strings. Compared with pasting secret strings around, this managed authentication significantly reduces leakage risk; prefer it whenever available.

Three criteria for choosing a model:

• Context length: determines how far back the conversation can “remember”; for a companion-style bot, go medium or higher;
• Tool calling support: determines how much the agent can do beyond chatting;
• Quota and billing: for everyday conversations, a mid-tier model is entirely sufficient—no need to pay a premium for top-tier models.

Enable Memory: The Heart of Multi-Turn Conversations

On the feature selection page, check “Memory” and press Enter to confirm.

Once enabled, the gateway persists conversation history and its summaries to local storage, enabling multi-turn context linkage—something you told it last week is still remembered this week, with no need to restate your requirements every time. For a companion-style bot, memory is nearly the soul of the experience; enable it.

Two practical tips: first, memory data grows over time, so check storage usage periodically and prune expired sessions; second, never write sensitive information (passwords, ID numbers, internal data) into memory, because memory content is continuously sent to the model side as context.

Register the Chat Platform Bot and Bind Credentials

This is the only step done “outside your server,” in five sub-steps:

1. Go to the open platform of your messaging platform and register a developer account. Personal use doesn’t require business credentials—just fill in your personal details as prompted;
2. Create a bot application. For the authorization scope, choose “accessible only to specified users and specified chats” to minimize exposure—this is basic security hygiene for any self-hosted service;
3. Get the bot’s AppID and AppSecret from the management page;
4. Add your server’s public egress IP to the platform’s IP whitelist;
5. Back in the wizard on your server, enter the AppID and AppSecret to complete the binding.

Three security reminders: the AppSecret is effectively the bot’s “password”—only view it when needed, and never commit it to a code repository or share it in screenshots; if you suspect a leak, reset it on the platform immediately; the whitelisted IP must match the server’s actual egress IP, and remember to update it after a server migration.

Troubleshooting a Common Error: “Failed to connect to bus” Under Passwordless Login

Symptom: If you operate the server via passwordless login (or through automated scripts), the gateway’s self-check may report that systemctl --user is unavailable, or throw errors like “Failed to connect to bus,” before you run the initialization or startup commands.

Cause: On Linux, systemd’s user-level service instances and the D-Bus session bus exist by default only alongside the user’s login session—they are reclaimed when the user fully logs out. In passwordless, non-interactive login environments, the user-level bus is often not yet ready, or the runtime directory environment variable is missing, so every systemctl --user operation fails to connect to the bus.

Fix: Before running the initialization command, execute these two commands:

# 1. Allow the current user to keep a user-level systemd instance after logout (linger)
loginctl enable-linger $(whoami)
# 2. Explicitly set the runtime directory (often missing in passwordless login scenarios)
export XDG_RUNTIME_DIR=/run/user/$(id -u)

Verification:

# The Linger field should show yes
loginctl show-user $(whoami) | grep -i linger
# If user-level units are listed normally, the bus is reachable
systemctl --user --no-pager list-units

enable-linger has an extra benefit: from now on, the bot’s user-level services keep running even after the SSH session drops—this is the correct way to deploy a resident service anyway. Filling in the runtime directory fixes the missing path in non-interactive shells. Together, the two commands permanently resolve both “can’t connect to the bus” and “service dies after logout.”

After It’s Running: Verification and Routine Maintenance

• Verify the pipeline in three steps: confirm the service is running on the server → confirm the bot shows as online on the platform → send a test message in the designated group or private chat and confirm it replies correctly with contextual memory;
• Hand the service to systemd: enable auto-start (systemctl --user enable --now <service name>; use the service name from your framework’s documentation). Combined with the linger setting above, the service automatically recovers after a server reboot;
• Troubleshoot via logs: use journalctl --user -u <service name> -f to follow logs in real time—most anomalies leave clues here;
• Security baseline: tighten key file permissions to 600, open only necessary ports in the firewall, and keep the framework updated to get security fixes.

Conclusion

The whole process boils down to five steps: install the gateway → configure the model → enable memory → bind the platform → fix session persistence. The real difficulty was never the “installation” itself, but the handful of steps that must be done manually, plus the pitfalls buried in Linux’s user-level session mechanics under passwordless login. Walk through this article’s sequence once, and you’ll come away with more than an online bot that remembers things—you’ll have a reusable deployment methodology that transfers directly to any similar self-hosted agent.