![[Step 4-A-1/3] Getting Your Bot Off Your Laptop — Free Cloud Hosting, Explained (Office Worker Edition)](https://lifetechhack.com/wp-content/uploads/2026/09/expert-957-hosting.png)
📌 Expert Workflows · Step 4: Deploy Your AI App for Free · Edition A (Office Worker) · Part 1 of 3
Review date: 12 September 2026. This lesson explains hosting choices for the Step 3 polling bot, prepares its files, and provides a local preflight experiment. Hosted deployment and live delivery have not been performed for this article.
🎯 The Reason This Matters
A locally running Telegram bot stops polling when its process or network connection stops. Moving it to a host can remove dependence on your laptop, but the host must support the application’s actual runtime and traffic pattern.
Right now, when you sleep your machine, walk out on Friday, or restart for an update, the bot goes silent — and the people using it experience that as broken, not asleep. No amount of clever code fixes it, because the problem isn’t the code. The problem is where the code runs.
The key decision is polling worker versus HTTP web service. The completed Step 3 project uses polling and does not listen on an HTTP port. This article gives a complete preparation and worker-deployment checklist. Free web hosting is not a promise of an always-on free bot.
👤 Whose Shoes You’re In
Edition A — Office Worker. The examples are instructional, not a report of a real employee, team rollout or successful cloud deployment.
Use the published curriculum for the available project path.
🛠️ Prerequisites
- Your working bot from Step 3, in a folder
- A free GitHub account — deployment platforms pull your code from here
- About 45 minutes
- A budget decision before creating a hosted service. The unchanged polling path on Render requires a paid worker; the local preflight below requires no hosting account or payment.
📝 Step 1: What “Deploying” Actually Means
Let’s dissolve the intimidating word first. Deploying means putting your code on a computer that someone else keeps running, so it doesn’t depend on yours.
A host provides a managed environment for your process. Availability still depends on the service type, plan, restart behavior, quotas and your application. A successful build does not establish a running bot.
A connected Git repository can supply the code. Automatic deployment depends on the selected branch and platform settings; confirm the deployed commit instead of assuming every push restarts the service.
Check three settings explicitly: process lifetime, restart behavior and environment-variable storage. Also choose a supported Python runtime compatible with your tested dependencies.
📝 Step 2: Choosing a Platform
The following account and service limits were checked against primary documentation on 12 September 2026. Recheck them before creating a service.
Render: free web services sleep after 15 minutes without inbound traffic and receive 750 workspace hours per calendar month. Free instances are intended for experiments, not production. Background workers are not a free service type. See Render’s free-instance limits.
Railway: its documented trial provides a one-time $5 credit for up to 30 days, then reverts to a Free plan with $1 monthly credit. Unverified accounts can have restricted outbound network access. Credits do not prove sufficient runtime for your bot; inspect your account’s verification and usage. See Railway’s trial documentation.
Choose by architecture. Keep the Step 3 polling code and use an approved worker host if its cost is acceptable. If your budget is zero, complete the local checks first; do not create a paid service. A web-service path requires an implemented HTTP/webhook design and separate tests, not just a different start command.
The specific failure: Render web services must bind an HTTP port. Running only python bot.py from Step 3 does not do that. Outbound polling also does not constitute inbound traffic for a free web service’s idle rule. Adding a health page alone does not establish reliable bot hosting. See web-service port requirements and worker services.
📝 Step 3: The Files a Host Needs
Start with the complete Step 3 files: bot.py copied from bot_part3.py, and operations.py beside it. Add requirements.txt and .gitignore. Keep the original test files when reproducing the earlier experiment.
requirements.txt lists every package your bot needs, so the host can install them. Create it in your project folder:
python-telegram-bot
python-dotenv
openai
After installing and testing dependencies in an isolated virtual environment, capture its versions with a UTF-8 output file. This avoids PowerShell 5.1 redirecting native output to UTF-16:
python -c "import subprocess, sys; from pathlib import Path; Path('requirements.txt').write_bytes(subprocess.check_output([sys.executable, '-m', 'pip', 'freeze']))"Review the result for unrelated packages, local paths and private package URLs. A frozen list records installed versions; it does not by itself prove compatibility with another Python version or operating system. Test a clean installation before deploying.
Worker start command: the polling project starts with:
python bot.py
Enter this in the worker service’s Start Command field. Do not assume a Procfile is interpreted by every host.
📝 Step 4: Getting Your Code to GitHub
Create .gitignore before staging. It should contain separate lines for .env, .venv/ and __pycache__/. Inspect the files, then stage only the required project files:
git init
git check-ignore .env
git ls-files .env
git add bot.py operations.py requirements.txt .gitignore
git diff --cached
# Review the diff before the next command.
git commit -m "Prepare polling worker project"Then create an empty repository on GitHub and follow its “push an existing repository” instructions.
Check tracking as well as ignore rules. git ls-files .env must print nothing. An ignore rule does not remove an already tracked secret. Review the staged diff before committing; never publish real credentials as evidence.
If a credential has already been shared or pushed, revoke it at the issuer and replace it. Removing the line from the latest file does not erase Git history. Do not share the original repository while investigating an exposure.
📝 Step 5: The First Deploy
Worker route, only after accepting its current cost: create a Background Worker, connect the intended repository and branch, choose the Python runtime, set Build Command to python -m pip install -r requirements.txt and Start Command to python bot.py. Before starting, add TELEGRAM_TOKEN, AI_API_KEY, AI_BASE_URL and AI_MODEL through the host’s environment settings. Use the provider’s documented endpoint/model. Do not upload .env.
Stop the local poller before starting one hosted instance with the same token. Watch the build and runtime logs separately. In a private test chat try /help, /status, and one synthetic /summarize request. A status reply checks only that command path; confirm the AI reply separately. If testing fails, stop the hosted worker before restarting the local copy.
Reconstructed failure example. The following dependency error is an instructional scenario. The local experiment later in the article tests missing distributions and files without contacting a host.
⚠️ Troubleshooting — “ModuleNotFoundError” in the cloud
(Teaching scenario — a common mistake reconstructed for learning, not a personal claim.)
🔴 BEFORE
The build log ran through installation, then the bot crashed on startup:
ModuleNotFoundError: No module named 'telegram'
The local environment can contain a package absent from the host’s installation list. Compare the build environment with the interpreter you actually tested.
🤔 Cause
The import name telegram belongs to the python-telegram-bot distribution used by this tutorial. Listing a different package named telegram is not an equivalent fix.
Other causes include a failed installation, wrong working directory or wrong interpreter. Read the actual log before changing dependencies.
🟢 AFTER
After correcting and testing the virtual environment, capture its dependencies again:
python -c "import subprocess, sys; from pathlib import Path; Path('requirements.txt').write_bytes(subprocess.check_output([sys.executable, '-m', 'pip', 'freeze']))"For this project verify that python-telegram-bot, openai and python-dotenv appear. Then install from the file in a clean environment and run the project’s tests. Do not claim a successful cloud run from a local dependency list.
Review and commit the dependency change, then push to the connected branch. Confirm whether automatic deployment is enabled or start a manual deployment:
git add requirements.txt
git commit -m "Add missing dependencies"
git push
Observed preflight result: a synthetic requirements file containing telegram instead of python-telegram-bot was flagged. A UTF-16 file was also rejected with an explicit encoding message. These checks diagnose those inputs; they do not install packages.
⚠️ The Part People Skip (Don’t)
You may have a bot building successfully, and it’s tempting to call it done. Two things to understand before part 2, because both will bite silently otherwise.
Configuration is a separate step. Git should carry code, while the host supplies environment variables. Missing values can stop startup or cause a provider failure. Check variable names and existence without printing secret values.
A build that succeeds isn’t a bot that runs.The build log going green means the packages installed. It says nothing about whether your bot actually connected to Telegram, found its token, or started polling — the same verify-one-layer-at-a-time discipline fromthe very first build in Step 1applies here exactly. “Build succeeded” and “bot is working” are two different claims, and conflating them is how people spend an hour confused about why a “successfully deployed” bot answers nothing.
✅ What You Have Now
You have a hosting decision, a reproducible file preflight and a complete checklist for the existing polling worker. Record a hosted build, runtime start and private Telegram/AI reply as separate results. The local experiment below does not fill those live-result fields.
If paid hosting is unsuitable, the useful result today is a checked local package and a clear explanation of why a free web service cannot run the unchanged bot.
💡 Go One Level Deeper
Read the first relevant build or runtime error. Confirm the deployed commit, Python runtime, install command and start command. Keep credentials and message content out of screenshots and shared logs.
❓ This Week’s Task
Run the preflight against a copy of your Step 3 project. Resolve findings, inspect Git tracking, and decide whether the worker cost and data destination are acceptable. Deploy only after that decision, then record each live check and stop the test service when finished.
Reproducible hosting preflight — 12 September 2026
Download the preflight tool, seven-check experiment and recorded results (ZIP)
SHA-256: a5436016add641bbcbc959db70a7f9dc62df2694aae4abc3e5c310cf95fd3ca4.
Extract the package and run python verify.py. Actual result on Python 3.11.4: 7/7 checks passed, using real temporary files and Python syntax parsing. No host account, credentials or network calls were used.
| Test input | Observed result |
|---|---|
| Polling project + Render web service | Architecture mismatch flagged |
| Complete files + worker selection | Local file checks passed, deployment explicitly unverified |
| Missing operations.py | Missing helper flagged |
| Invalid Python syntax | Source error flagged |
| telegram instead of python-telegram-bot | Missing required distribution flagged |
| UTF-16 requirements.txt | Encoding error flagged |
| .gitignore without .env | Exclusion warning returned |
From the extracted tool folder, use python preflight.py "PATH_TO_YOUR_BOT_FOLDER" --service render-web to reproduce the polling mismatch, or --service render-worker for the worker file checks. Exit code 1 means findings; 0 means only these limited checks passed.
The tool reads files without importing or starting your bot. It is specific to this tutorial, not a full dependency or security audit. It does not inspect Git history, find every secret, validate credentials, measure cost, install packages or verify cloud uptime. The separate Step 3 download contains the complete bot and its offline tests.
🔗 Next in This Series
Further secrets and hosting lessons are not required to understand this checklist. Use the current published roadmap; do not assume an unlinked later part is already available.
✍️ About the author & how this was made
Written and edited byG. Troy, editor of Life Tech Hack. The site is an independent AI-education blog; its approach draws on hands-on work across engineering, design, and several other industries, and every article is checked against primary sources (official docs, specs, and vendor guidance) before publishing. Where a claim depends on a price, feature, or policy that can change, the relevant source is linked inline.
AI tools may be used to help draft or organise material; the final content is human-reviewed and edited, and unsupported claims or invented quotations are removed. This reflects the site’s editorial standards and Google’s guidance on helpful, people-first content.