How Do You Move From a Home-Made Telegram Forwarding Script to a Cloud Service?

The script works, and it has worked for months. And still the machine rebooted on Tuesday and nobody noticed until the destination had gone quiet for a day. Moving the job is less about features and more about no longer being the on-call engineer for a script.

Nothing to keep running

Forwarding runs on the service's servers around the clock. The computer or VPS that hosted the script can be switched off and stay off: delivery does not depend on anything being awake at your end, and there is nothing to update or restart after a crash.

No API keys, no chat identifiers

The script almost certainly began with an api_id, an api_hash and a list of numeric chat identifiers pasted by hand. The service needs none of that: you connect with your phone number and the login code, then pick the source and the destination from a list of your own chats, by name.

The rule that stops itself and tells you why

A script fails quietly: the destination refuses the post, the script retries or crashes, and the gap is discovered days later. In the service, when a destination refuses three deliveries in a row for a reason that cannot resolve itself, such as a removed write permission or a chat that no longer exists, the rule stops trying and shows the reason next to the rule in the dashboard. Restore the permission, switch the rule back on, and delivery resumes.

The things the script never had

None of these is hard to write on its own. They are hard to keep working together, which is what the script was quietly accumulating.

  • Edit sync: when the source edits a message, the copy in your destination is edited in place, within a seven-day window.
  • Delete sync: a message deleted at the source removes the copy too.
  • Duplicate detection: overlapping sources stop meaning the same post arriving twice.

Bringing the backlog across

The script may have left a backlog: posts published before the move that belong in the destination. That is a history import, and it is the one feature where the honest answer starts with a warning. Bulk forwarding is the riskiest thing you can ask a Telegram account to do: hundreds of requests in a row look like automation, and Telegram answers first with rate limits and then with restrictions on the account itself. The account being restricted is yours.

The caps exist because of that risk: 500 deliveries per source channel, 1,500 deliveries a day, and one import of 50 during the 7-day trial. Test with the last few messages before committing to a bigger job.

What happens when the trial ends

Every new account starts on a 7-day trial. When it ends, the account moves to the Free plan, and the rule that delivered most recently keeps running: one rule, one destination, around the clock. The others are paused rather than deleted, and they come back on by themselves if you subscribe.

Common questions

Do I need Telegram API keys to switch?

No. You connect with your phone number and the login code, exactly like logging into Telegram, and pick every source and destination from a list of your own chats.

Can I move the old messages too?

With a history import, up to 500 deliveries per source channel and 1,500 a day, and one import of 50 during the trial. Bulk sending carries a real risk of Telegram limiting the account, which is what the caps protect against.

What happens to my rules when the trial ends?

You move to the Free plan. The rule that delivered most recently keeps running; the others are paused rather than deleted and return automatically if you subscribe.

The destination broke. Will the service retry endlessly?

No. After three refusals for a reason that cannot resolve itself, the rule stops and shows the reason in the dashboard, which protects the account. Restore the permission and switch the rule back on.

Try Phantom Forwarder free

7-day trial, unlimited rules. Cloud-based, anonymous, nothing to install.

Related

More guides