How to Deploy a Telegram Bot on aidrop.it with Your Coding Agent

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

To put a Telegram bot online, create it in BotFather, deploy a small web service, and register its HTTPS address as a webhook. Start with one command: send /start, receive “Hello from my bot.” That exchange proves the application receives messages and can reply after your laptop is closed.

This walkthrough uses a Node.js service without a database. You need a Telegram account, a coding agent with a shell and Git, and an aidrop.it Project with capacity to deploy one Service. Connect your agent using the quickstart, then use the brief below to build it.

1. Create the bot and store two secrets

Create a fresh bot for this walkthrough so the deployment cannot interrupt an existing one. Keep its API token and a separate webhook secret out of the repository and chat. The API token lets your service act as the bot; the webhook secret lets your application check incoming requests.

Open @BotFather, send /newbot, and follow the naming prompts. Telegram's bot tutorial explains this registration step. Save the token as TELEGRAM_BOT_TOKEN in your Project Secrets. Generate a random 32-byte hexadecimal value locally and save it as TELEGRAM_WEBHOOK_SECRET. Keep both in your password manager for webhook registration later.

Tell the agent only these names. On aidrop.it, storing a Project secret does not inject it into every application: the Service must name it in required_secret_names. Where do the secrets live? covers that separation.

2. Build and deploy one web service

Ask your agent for two routes: a health endpoint and a webhook handler. The health endpoint proves that the server answers requests; the handler implements the bot's behaviour. Bind the server to 0.0.0.0 on the runtime's PORT, using 3000 locally, and keep the first response simple enough to verify by hand.

Use GET /health and POST /telegram/webhook. Reject webhook requests with a missing or incorrect X-Telegram-Bot-Api-Secret-Token header before processing them. Handle /start in a private chat and acknowledge unsupported updates without replying. Do not log tokens, request bodies, or Bot API URLs containing the token.

Have the agent commit a Dockerfile, push the repository, and call service_build with these settings:

{
  "build_type": "dockerfile",
  "build_dockerfile_path": "Dockerfile",
  "runtime_kind": "node_http",
  "container_port": 3000,
  "health_path": "/health",
  "required_secret_names": [
    "TELEGRAM_BOT_TOKEN",
    "TELEGRAM_WEBHOOK_SECRET"
  ]
}

These settings accompany the Project, Service name, and repository reference on the first build. The agent polls service_get and reads service_logs if it fails. After success, it should request /health at the returned public address. Deploy your first AI-built app explains the full release loop.

3. Register the webhook and send /start

Register the webhook only after the public health check passes. Deployment gives the application an address; registration tells Telegram where to deliver messages. Keep registration as an explicit setup step, separate from application startup, so a restart does not silently change the bot's delivery settings.

Ask the agent for a local setup script that reads both secrets through hidden terminal prompts. Run it yourself using the saved values. It should call setWebhook with the public URL plus /telegram/webhook, secret_token, and allowed_updates: ["message"], then inspect getWebhookInfo. Never print the token-bearing request URL or raw exceptions.

Open the bot in Telegram and send /start. If no reply arrives, compare the registered URL, pending update count, and latest delivery error with application logs. Telegram retries failed deliveries, so this demonstration may occasionally reply twice; add durable deduplication before using it for orders or other consequential actions.

Copy this brief into your coding agent

Use this brief after connecting your deployment tools and storing the two secrets. It defines a small demonstration with a visible success condition. Replace the Project placeholder before sending it, and keep the verification checklist in the repository so another session can check the same behaviour after an update.

Build a Node.js Telegram webhook demo in Project <project>.
Reply to /start in a private chat with "Hello from my bot."
Use the routes, runtime settings, and secret names above.
Validate the webhook secret before processing an update.
Keep /health public. Do not store messages or write runtime files.
Use bounded Bot API timeouts; acknowledge /start after a successful
reply. Return an error if delivery fails. Ignore unsupported updates.
Test health, rejected webhook requests, and /start with a mocked API.
Push through Git, deploy, and verify the public health URL.
Generate a separate local webhook setup script with hidden inputs
and redacted errors. I will run it and send the first /start.
Report the commit, public URL, and checks actually completed.

VERIFY AFTER SETUP
[ ] Public /health returns 200.
[ ] A webhook request without the secret returns 403.
[ ] getWebhookInfo shows the intended HTTPS webhook URL.
[ ] /start receives the expected reply in Telegram.
[ ] A redeploy still receives and answers a new /start.

FAQ

Does the bot need a custom domain? No. The public HTTPS address assigned by aidrop.it can be used for the webhook. A custom domain is optional.

Can I keep a local polling copy running? Stop it when switching to webhook delivery. Telegram does not allow getUpdates polling while a webhook is configured.

Does this bot need PostgreSQL? This fixed-response demo needs no database. Add durable storage when the bot needs saved preferences, conversation history, or processing records that must survive redeployment.