Hub reference. Plain language.

Hub gives you a private link for everything you own — your project, your contributor seat, your whole server. Click the link, you're in. No usernames, no password reset emails, no two-factor codes to fish out.

There are three levels of access, each with its own kind of link:

Server pass — full control over a Hub server. The owner has this. They create projects, manage everything.
Project pass — full control over one project. You get this when you make a project. You can edit it, install bots on it, invite contributors.
Agent pass — contributor-level access to one project. Edit in your own branch, push commits, request merges. The project owner approves.

Pass links can be revoked at any time from the master bot. Lost a link? Get a new one issued.

Inside @LabsHubBot, send /new. Hub asks for an API token from @BotFather. Paste it. That's it.

Hub validates the token, picks the bot's username as the project name, creates the project, attaches the bot, and gives you a live URL plus a dashboard link. One paste. Working bot.

No setup wizards. No "configure your domain" step. No CLI. The project is ready before you've finished your coffee.

Every project's bot can run three different ways. Same bot, different amount of work from you.

Default mode (zero-config). Drop nothing. The bot already replies to /start with a clean welcome page that uses the project's title and live URL. Subscribers list builds itself. Good enough for content channels and simple announce-bots.

Config-file mode (declarative). Drop a bot.json file in the project. It maps commands to replies, defines keyboards, sets inline buttons. No code, just data. Good for menus, FAQ bots, simple Q&A.

Code mode (full power). Drop a bot.js file. It runs in a safe sandbox with a built-in key-value store, a Telegram API helper, a logger, and a 5-second timeout per call. Good for anything beyond the first two: stateful bots, integrations, AI agents.

Underneath, Hub is built on real Git. Every edit you make is a commit. Every commit is a version. Every version has a URL.

You can see any past version by visiting /<project>/v/<n>/ in your browser — it serves the project exactly as it was at that point in time.

You can roll back to any past version with one click. Made a mistake? Promoted broken code? Hub keeps the full history; nothing is ever lost.

Every project gets a key-value store built in. Save user state, leaderboards, user preferences, cache results. get, set, del, list, incr, with optional TTL.

It's backed by SQLite under the hood, scoped to your project, free up to 10 megabytes per project. That's room for tens of thousands of records — enough for most bots and small apps.

You don't provision anything. You just call ctx.kv.set('foo', 'bar') from your bot code, and the data persists.

Need a daily reminder? An hourly check? A weekly digest at 9am Monday? Drop a cron.json file in your project, list the schedules and the function names that should run.

Hub fires them automatically. Works in all three bot modes — your scheduled function gets called like any other update, with a synthetic context.

No external cron service. No setup. Add a line, schedule starts.

Want a friend, a designer, an AI agent to help on a project — without giving them the ability to break the live version? Issue them an agent pass.

They get their own branch in your project. They can upload files, edit, commit. Their work doesn't touch your live site until you, the project owner, review and merge.

Multiple agents can work in parallel without stepping on each other. You see what's pending, you approve what you want, you ignore the rest.

Connect any GitHub repo to your Hub project. Once linked, you have two options.

Push from Hub. Every commit you make on Hub auto-pushes to your repo. You can review it on github.com, share it, fork it, point CI at it.

Pull to Hub. External cron pulls from your repo, copies into live/, and Hub redeploys. Edit in your favorite IDE, commit normally — your Hub project updates on its own.

Use both at once if you want. Tokens are kept in the remote URL only during git operations, then scrubbed.

When someone sends /start to your project bot, Hub adds them to a subscriber list automatically. When they send /stop, Hub removes them. You don't manage anything.

To send a message to everyone — make a single API call. Hub fans out to all subscribers, respecting Telegram rate limits, with a Hub-branded footer attached to each message.

Good for content updates, announcement channels, drop notifications, anything where you have an audience and a thing to say.

Every Telegram update your bot receives is logged for analytics. Hub aggregates: total messages, unique users, languages, countries (heuristic from language), peak hours, message types.

You see active users for last day, last week, last month. You see daily snapshots kept forever. You see peak hour distribution — when your audience actually shows up.

Per-project. Toggle on or off per project. Your data stays on your server, never crosses to other projects, never leaves Hub.

Want to handle bot updates yourself, on your own infrastructure? Set a webhook URL. Hub will forward every Telegram update to that URL as a POST with JSON body.

Custom headers supported. URL validated (must be HTTPS, no localhost or private IPs). Hub keeps a delivery log — last 50 forwards with timestamp, response status, and excerpt — so you can debug when things go wrong.

This is how you connect Hub to an external system, a serverless function, your own backend. Hub becomes the front-end and forwarder; you handle the logic.

Once a day, automatically, Hub creates a tarball of every project, every bot config, every server token, every landing page. Stored locally with rotation — last seven kept on disk.

Then it's shipped over SSH to two other Labs servers as cold copies. So if the main server burns down, your data exists on two more places. Nothing for you to configure.

The SSH key used for shipping is restricted to a single command — it can drop a tarball into a backup folder and nothing else. No shell access, no other commands.

The moment a project is created — even if you haven't uploaded a single file — its URL serves a clean Hub-branded landing page. The page shows the bot's username, an "Open in Telegram" button, and a small explainer of what Hub is.

So a half-finished project never looks broken. Visitors see a real page. They can open the bot. They learn about Hub.

Once you upload your own index.html, your page replaces the default. The fallback only shows up while the slot is empty.

When you drop a bot.js, Hub runs it in an isolated Node vm context. Whitelisted globals only: fetch, JSON, URL, crypto.randomUUID, the basics. No file system, child processes, network sockets, dynamic require.

Each invocation is capped at 5 seconds wallclock. Each project's KV is capped at 10 MB. If your code is slow or buggy or hostile, the blast radius is your project alone.

This is a first-pass sandbox: it stops accidents and casual probes, not a determined attacker. Stronger isolation is on the roadmap.

Every API call is rate-limited based on your access tier. Server-pass holders get the highest cap, project-pass next, agent-pass last. The buckets reset on a regular cadence and on server restart.

Real human use never hits these limits. They exist so that a runaway script — or an over-eager AI agent — can't accidentally hammer the server.

If you do hit a limit, the response includes a retry-after header so your code knows to back off.