Deploy and Host Nanobot on Railway

Nanobot is a lightweight, self-hosted AI gateway and orchestration layer — a single service that routes requests across multiple LLM providers (OpenAI, Gemini, Groq) with automatic fallback, and connects them to messaging channels like Telegram. Instead of hardcoding a different integration for every model and every chat platform, you configure everything through a web dashboard and Nanobot handles the routing, key management, and logging in one place.

What This Template Deploys

One container. Nanobot stores all configuration, provider keys, and logs on a persistent volume at /data, so there's no separate database to run — but the volume is required, or your settings reset on every redeploy.

About Hosting Nanobot

Nanobot sits between your applications or chat channels and multiple AI providers, acting as a single control point. Rather than wiring OpenAI into one service, Gemini into another, and rebuilding a Telegram bot from scratch each time, you point everything at Nanobot and manage providers, keys, models, and channels from its dashboard.

The whole thing runs as one Docker container that exposes three things: a basic-auth-protected admin dashboard, a gateway API that routes requests, and a background worker that processes incoming messages. Railway builds it from the included Dockerfile via railway.toml, assigns a public URL, and handles networking and uptime.

The one requirement that matters: attach a Railway volume at /data. All configuration and state — provider keys, model selections, channel settings, logs — live there. Without the volume, every redeploy wipes your setup and you reconfigure from scratch. And because that data includes your provider API keys, set a strong ADMIN_PASSWORD before exposing the dashboard: an unprotected instance is an open door to your API credits.

Typical cost: ~$5/month on Railway's Hobby plan for the single container. Nanobot is MIT-licensed and free; you pay only for the LLM providers you route to.

How It Compares

OpenRouter is the simplest but routes through their gateway with a markup. LiteLLM is more configurable for pure API proxying. Nanobot's niche is the dashboard-plus-messaging combo — a self-hosted router that also gives you a working Telegram bot backend without extra code.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — Nanobot builds from its Dockerfile automatically (~2 minutes)
2. Attach a volume mounted at /data — critical, or your config won't persist
3. Set ADMIN_USERNAME and ADMIN_PASSWORD for the dashboard login
4. Open your Railway public URL, log in, and add provider API keys under the AI Providers tab
5. Optionally enable Telegram under Channels with a BotFather token, then start the gateway and send a test message

No database to provision, no per-provider code, no separate bot server.

Common Use Cases

• Multi-LLM gateway — switch and fall back across OpenAI, Gemini, and Groq from one endpoint, configured in the dashboard
• Telegram AI bot backend — connect a BotFather token and get a working AI chat bot without building the integration yourself
• Internal AI API hub — give multiple internal services one centralized, key-managed access point to your AI providers
• Model benchmarking — route the same prompts to different providers and compare responses and latency
• Messaging integrations — extend to WhatsApp bridge, Feishu, and other channels from a single backend
• Cost and key control — keep all provider keys in one managed place instead of scattered across apps

Configuration

Attach a volume at /data. All configuration, provider keys, and logs live there. Without it, every redeploy resets your entire setup. This is the single most important step.

Set a strong ADMIN_PASSWORD. The dashboard holds your provider API keys. On a public Railway URL, weak or default credentials expose them to anyone who finds the instance.

Provider API keys (OpenAI, Gemini, Groq) and channel tokens (Telegram, etc.) are added through the dashboard after deploy, not as environment variables — so they're managed in the UI and stored on the volume.

Dependencies for Nanobot Hosting

• Railway account — Hobby plan (~$5/month) runs the single container
• A persistent Railway volume mounted at /data (required)
• At least one LLM provider API key (OpenAI, Gemini, or Groq)
• Optional: a Telegram bot token from BotFather for the messaging channel

Deployment Dependencies

• Nanobot Template Repository
• Railway Volumes Documentation
• Telegram BotFather

Implementation Details

The template runs Nanobot as a single container built from its Dockerfile through railway.toml. The service exposes a basic-auth-protected admin dashboard at /, a gateway API for routing requests, a background worker for message processing, and a /health endpoint that Railway uses for health checks.

All configuration and state persist to /data, which must be backed by a Railway volume — provider keys, model selections, channel configuration, and logs are stored there rather than in a database. Because keys are entered through the dashboard and saved to the volume, the deployment has no provider secrets in its environment variables; the only required variables are the dashboard credentials.

The gateway can be started, stopped, and restarted through the dashboard or its API endpoints (/api/gateway/start, /stop, /restart), and provider and channel configuration is read and written via /api/config. This keeps runtime management in the UI rather than requiring redeploys to change providers or models.

Frequently Asked Questions

Does my configuration survive a redeploy? Only if a volume is mounted at /data. Provider keys, model settings, channel configuration, and logs all live there. Without the volume, every redeploy resets the instance to a blank state.

How do I add provider API keys? Through the dashboard after deploy, not as environment variables. Log in, open the AI Providers tab, and add your OpenAI, Gemini, or Groq keys. They're saved to the /data volume.

Which providers are supported? OpenAI, Gemini, and Groq out of the box, with automatic fallback between them. Select models per provider or specify a custom model ID in the dashboard.

How do I connect a Telegram bot? In the Channels tab, enable Telegram and paste a bot token from BotFather. Set allowed users to * for everyone or specific comma-separated user IDs, then start the gateway.

Is my instance secure? It's protected by basic auth via ADMIN_USERNAME and ADMIN_PASSWORD. Use strong credentials — the dashboard stores your provider keys, so an open instance exposes your API credits.

My bot isn't responding — what do I check? Confirm your provider API keys are valid, a default provider is selected, and the gateway is started. The dashboard's Logs view shows routing and provider errors.

Do I need a separate database? No. Nanobot stores everything on the /data volume, so there's no database service to run — just make sure the volume is attached.

Why Deploy Nanobot on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Nanobot on Railway you get a self-hosted AI gateway in one click — multi-provider routing with fallback, a config dashboard, and a Telegram-ready messaging backend, all in a single container with a persistent volume for your settings. Centralize your AI providers, skip the per-integration code, and keep your keys on infrastructure you own.