DEV Community

Cover image for Deploy a Telegram Rubber Duck That Actually Answers Back
Serverspace
Serverspace

Posted on

Deploy a Telegram Rubber Duck That Actually Answers Back

#ai #beginners #tutorial #devops

Your application has crashed.

The terminal has responded with 47 lines of red text, three warnings you don’t understand, and one particularly helpful message:

Something went wrong.
Enter fullscreen mode Exit fullscreen mode

You could paste the whole thing into five browser tabs.

Or you could send it to a Telegram bot that explains the error, suggests what to check next, and patiently waits for the command output.

In this tutorial, we’ll build exactly that.

Meet Debug Duck 🦆: a private AI assistant that lives in Telegram and helps you work through stack traces, logs, and mysterious server errors.

Unlike a regular rubber duck, this one answers back.

Occasionally, it may even be useful.

🦆 What We’re Building

The setup is simple:

You
 ↓
Telegram
 ↓
OpenClaw running on a VPS
 ↓
Language model API
 ↓
A debugging answer in Telegram
Enter fullscreen mode Exit fullscreen mode

You send the bot an error, log fragment, command output, or stack trace.

OpenClaw adds the system prompt and conversation history, sends the request to the selected language model, and returns the answer to Telegram.

By the end of the guide, your bot will be able to:

  • explain errors in plain English;
  • separate confirmed facts from likely causes;
  • suggest a few diagnostic steps;
  • provide commands you can run;
  • ask for the result of the next check;
  • remember the current debugging context.

It will not automatically log in to your server and fix everything.

That feature is also known as “giving an AI agent root access and hoping for character development.”

What You’ll Need

Prepare the following:

  • a Linux VPS running Ubuntu;
  • a Telegram account;
  • an API key for a supported language model;
  • around 20–30 minutes;
  • one error message that has already ruined part of your day.

OpenClaw itself is lightweight when it uses an external model API.

For a private bot, a small VPS with the following configuration is enough:

Resource Configuration
Operating system Ubuntu 24.04
CPU 1 vCPU
RAM 1 GB
Storage 20 GB
Access SSH key recommended

This tutorial uses a Serverspace VPS, but the OpenClaw and Telegram steps are the same on any regular Ubuntu server.

Step 1: Create a Small Linux VPS

Create an Ubuntu server and connect to it over SSH:

ssh root@YOUR_SERVER_IP
Enter fullscreen mode Exit fullscreen mode

Replace YOUR_SERVER_IP with the public IP address of your VPS.

Update the installed packages:

apt update && apt upgrade -y
Enter fullscreen mode Exit fullscreen mode

The language model itself runs through an external API, so the VPS mainly handles:

  • Telegram messages;
  • the OpenClaw gateway;
  • configuration;
  • conversation history.

Local inference with Ollama is a different story.

A server with 1 GB of RAM will look at a 7B model, sigh quietly, and refuse to participate.

Step 2: Install OpenClaw

Run the official installer:

curl -fsSL https://openclaw.ai/install.sh | bash
Enter fullscreen mode Exit fullscreen mode

The installer detects the operating system, installs the required dependencies, and starts the onboarding process.

OpenClaw requires Node.js 22.14 or newer. Node.js 24 is recommended.

During onboarding:

  1. Select your language model provider.
  2. Enter the provider API key.
  3. Complete the basic assistant setup.
  4. Enable the background service when prompted.

After installation, check that the OpenClaw CLI is available:

openclaw --version
Enter fullscreen mode Exit fullscreen mode

Run the built-in diagnostics:

openclaw doctor
Enter fullscreen mode Exit fullscreen mode

Then check the gateway status:

openclaw gateway status
Enter fullscreen mode Exit fullscreen mode

When openclaw doctor reports no critical problems, the duck is alive.

It just doesn’t have a Telegram account yet.

Step 3: Create a Telegram Bot

Open Telegram and find the official @botfather account.

Send the following command:

/newbot
Enter fullscreen mode Exit fullscreen mode

BotFather will ask you for:

  1. a display name;
  2. a username ending in bot.

For example:

Display name: Debug Duck
Username: debug_duck_bot
Enter fullscreen mode Exit fullscreen mode

Once the bot is created, BotFather will give you a token that looks like this:

123456789:AAExampleTokenThatShouldRemainSecret
Enter fullscreen mode Exit fullscreen mode

Treat this token as a password.

Do not paste it into a public GitHub repository unless you enjoy emergency token rotation.

Step 4: Connect Telegram to OpenClaw

Open the OpenClaw configuration file:

nano ~/.openclaw/openclaw.json
Enter fullscreen mode Exit fullscreen mode

Add the Telegram channel:

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "YOUR_TELEGRAM_BOT_TOKEN",
      "dmPolicy": "pairing",
      "groups": {
        "*": {
          "requireMention": true
        }
      }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Replace YOUR_TELEGRAM_BOT_TOKEN with the token received from BotFather.

Save the file and exit Nano:

Ctrl + O
Enter
Ctrl + X
Enter fullscreen mode Exit fullscreen mode

The important option here is:

"dmPolicy": "pairing"
Enter fullscreen mode Exit fullscreen mode

Pairing means that finding the bot’s username is not enough to start using it. A new user must be approved first.

This prevents a random stranger from discovering your bot and spending your API budget asking it to write a 12-volume fantasy series.

For a private bot, avoid an open direct-message policy with unrestricted access.

Step 5: Turn It into Debug Duck

A generic AI assistant will answer almost anything.

That sounds useful until you send it a stack trace and receive a five-paragraph essay about the importance of software quality.

We need to give the assistant a much clearer job.

Add the following system prompt through the assistant or agent configuration created during OpenClaw onboarding:

You are Debug Duck, a patient debugging assistant for beginner developers.

When the user sends an error message, stack trace, log fragment, command output, or code:

1. Explain the problem in plain English.
2. Separate confirmed facts from likely causes.
3. Suggest no more than three diagnostic steps at a time.
4. Include exact commands when they are useful.
5. Explain briefly what each command checks.
6. Ask the user to send the result of the most important check.
7. Never recommend destructive commands without a clear warning.
8. Never present a likely cause as a confirmed fact.
9. Keep answers concise and easy to scan.
10. You may use one light joke, but never make fun of the user.

Do not rewrite the entire application unless the user explicitly asks.

Do not suggest deleting files, reinstalling the server, or disabling security controls as the first solution.
Enter fullscreen mode Exit fullscreen mode

Avoid prompts like this:

You are a helpful assistant.
Enter fullscreen mode Exit fullscreen mode

That gives the model roughly the same amount of direction as:

Just fix production.

The more specific the role, rules, and response format are, the more predictable the assistant becomes.

Step 6: Start the Gateway

Start the OpenClaw gateway:

openclaw gateway
Enter fullscreen mode Exit fullscreen mode

Now open your new bot in Telegram and send it a message:

Hello
Enter fullscreen mode Exit fullscreen mode

Because we enabled pairing, the bot should not immediately accept the conversation.

Return to the server and list pending Telegram pairing requests:

openclaw pairing list telegram
Enter fullscreen mode Exit fullscreen mode

Approve the displayed code:

openclaw pairing approve telegram YOUR_PAIRING_CODE
Enter fullscreen mode Exit fullscreen mode

Replace YOUR_PAIRING_CODE with the actual code shown by OpenClaw.

Pairing codes remain valid for one hour.

Now send another Telegram message:

Are you alive?
Enter fullscreen mode Exit fullscreen mode

A good response would be:

Yes. Send me an error message, stack trace, or command output, and I’ll help you work through it.
Enter fullscreen mode Exit fullscreen mode

A less useful response would be an existential discussion about whether software can truly be alive.

That may require another look at the system prompt.

Step 7: Give the Duck Something to Debug

Let’s test the bot with a few common errors.

Test 1: Port 80 Is Already Busy

Send the following error to the bot:

nginx: [emerg] bind() to 0.0.0.0:80 failed
(98: Address already in use)
Enter fullscreen mode Exit fullscreen mode

Debug Duck should explain that another process is already listening on port 80 and suggest a diagnostic command such as:

sudo lsof -i :80
Enter fullscreen mode Exit fullscreen mode

A good response might look like this:

Port 80 is already occupied. Nginx is trying to sit in a chair that someone else has taken.

Check which process is using the port:

sudo lsof -i :80

This command shows the process currently listening on port 80.

Likely causes:
1. Another Nginx instance is already running.
2. Apache is using the port.
3. A Docker container published port 80.

Send me the command output, and we’ll narrow it down.
Enter fullscreen mode Exit fullscreen mode

The joke takes one sentence.

The diagnostic step remains the main point.

Test 2: A Node.js Dependency Is Missing

Send:

Error: Cannot find module 'express'
Enter fullscreen mode Exit fullscreen mode

The assistant should explain that the dependency is missing from the current environment and suggest checking the project directory and installed packages:

pwd
npm list express
Enter fullscreen mode Exit fullscreen mode

It should not immediately recommend:

  • deleting node_modules;
  • clearing every available cache;
  • reinstalling Node.js;
  • sacrificing the lock file.

Good debugging starts with checking what is actually happening.

Test 3: The Server Has Run Out of Space

Send:

No space left on device
Enter fullscreen mode Exit fullscreen mode

The bot should begin with a safe diagnostic command:

df -h
Enter fullscreen mode Exit fullscreen mode

It may then suggest checking which top-level directories consume the most disk space:

du -xhd1 / 2>/dev/null | sort -h
Enter fullscreen mode Exit fullscreen mode

It should warn you before suggesting deletion.

“Disk full” is a diagnosis.

“Delete random things until the server boots” is a lifestyle choice.

Step 8: Check the Quality of the Answers

The goal is not simply to make the bot respond.

A useful debugging assistant should:

  • explain what the error means;
  • avoid pretending that guesses are facts;
  • suggest a small number of checks;
  • explain what each command does;
  • wait for additional information;
  • warn before risky actions.

For example, this is not a good answer:

Reinstall Nginx and restart the server.
Enter fullscreen mode Exit fullscreen mode

The assistant has not checked:

  • which process owns port 80;
  • whether Nginx is already running;
  • whether Apache is installed;
  • whether a container published the port.

A better answer starts with diagnosis.

Debug Duck should behave like a patient teammate, not like someone trying to close the ticket before lunch.

Step 9: Keep the Bot Private

The bot has access to a paid language model API, so access control matters.

For a personal assistant, keep the pairing policy enabled.

Avoid this configuration:

{
  "dmPolicy": "open",
  "allowFrom": ["*"]
}
Enter fullscreen mode Exit fullscreen mode

It allows anyone who discovers the username to use the bot.

You should also review logs and stack traces before sending them to an external language model.

They may contain:

  • API keys;
  • access tokens;
  • internal hostnames;
  • database addresses;
  • email addresses;
  • fragments of user data;
  • private file paths.

Debug Duck is here to inspect errors, not quietly collect your entire infrastructure map.

Step 10: Keep Secrets Out of Git

Never store Telegram or model-provider tokens in a public repository.

At minimum:

  1. Store secrets in environment variables or a protected configuration file.
  2. Add local secret files to .gitignore.
  3. Restrict permissions on configuration files.
  4. Rotate a token immediately if it becomes public.

Restrict access to the OpenClaw configuration file:

chmod 600 ~/.openclaw/openclaw.json
Enter fullscreen mode Exit fullscreen mode

If you accidentally push a token to GitHub, removing it from the latest commit is not enough.

The token may still exist in the repository history.

Revoke it and create a new one.

The internet has a remarkable ability to find leaked secrets approximately four seconds before you do.

Step 11: Control Conversation History

OpenClaw can retain conversation context.

That allows the bot to follow a debugging session:

  1. You send an Nginx error.
  2. The bot asks which process is using port 80.
  3. You send the command output.
  4. The bot understands that it belongs to the same problem.

However, longer histories can increase API costs because previous messages may be included in later requests.

For a debugging assistant, keeping around 10–20 message exchanges is usually enough.

You rarely need the complete emotional history of your relationship with Nginx.

Set an appropriate history limit in the OpenClaw configuration supported by your version.

Step 12: Make Sure It Survives a Reboot

A debugging bot that disappears after every server restart creates a new debugging problem.

Install the OpenClaw gateway as a background service:

openclaw gateway install
Enter fullscreen mode Exit fullscreen mode

You can also install it during onboarding:

openclaw onboard --install-daemon
Enter fullscreen mode Exit fullscreen mode

On Linux, OpenClaw configures a systemd user service.

Check the gateway status:

openclaw gateway status
Enter fullscreen mode Exit fullscreen mode

If the bot stops responding, start with:

openclaw doctor
openclaw gateway status
openclaw logs --follow
Enter fullscreen mode Exit fullscreen mode

These commands can help determine whether the problem is:

  • the OpenClaw process;
  • the Telegram connection;
  • an invalid provider API key;
  • an exhausted API balance;
  • a configuration error.

Yes, eventually you may need to debug the debugging bot.

Every tool becomes infrastructure if you depend on it long enough.

Make the Bot More Useful for Your Stack

Once the basic version works, adjust the system prompt for the technologies you use most often.

For example:

The user mainly works with:

- Ubuntu
- Nginx
- Docker Compose
- Node.js
- Express
- PostgreSQL

Prioritize diagnostic commands for this stack.
Enter fullscreen mode Exit fullscreen mode

You can also require a fixed response format:

What the error means

What is confirmed

Most likely causes

Run this next

Send me this output
Enter fullscreen mode Exit fullscreen mode

A predictable format makes answers easier to scan from a phone.

You can also create specialized versions of the bot.

Commit Message Therapist

Send it a description of your changes and receive something better than:

fix stuff final final
Enter fullscreen mode Exit fullscreen mode

Standup Goblin

Send it chaotic notes from yesterday and get:

What I completed
What I’m working on
Current blockers
Enter fullscreen mode Exit fullscreen mode

Explain It to My Manager

Send it a technical issue and receive two explanations:

  • one for engineers;
  • one for people who do not consider “the container is restarting” a complete status update.

Still, a read-only debugging assistant is a good first project.

Avoid giving the bot permission to execute arbitrary commands until you understand how the model behaves.

What We Built

You now have a private Telegram bot that can:

  • read error messages and stack traces;
  • explain them without unnecessary jargon;
  • suggest diagnostic commands;
  • remember the current debugging context;
  • stay online independently of your laptop.

It will not replace learning how your stack works.

It may still make mistakes, so review commands before running them.

But it can save you from opening twelve browser tabs just to discover that port 80 was occupied.

And unlike a real rubber duck, this one answers back.

Ready to build your own Debug Duck? 🦆

Deploy a small Ubuntu VPS on Serverspace and start with the first command.

Top comments (0)