Life Tech Hack

[Step 4-A-2/3] Secrets, Environment Variables, and the Bot That Finally Runs (Office Worker Edition)

[Step 4-A-2/3] Secrets, Environment Variables, and the Bot That Finally Runs (Office Worker Edition)

📌 Expert Workflows · Step 4: Cloud Deployment and Its Limits · Edition A (Office Worker) · Part 2 of 3

Scope: This guide helps you distinguish missing configuration, the wrong hosting service type, and a failed connection. The configuration check below was run locally with synthetic values. No live Telegram message, AI request or cloud deployment was performed for this article. BEFORE/AFTER scenarios are illustrative; the final connection checks are for you to perform on your own deployment.

🎯 What You’re Actually Building Here

In part 1 you prepared the project and chose a hosting route. A successful build only shows that the build steps completed. It does not establish that your bot can authenticate, receive a message or call your AI provider.

Today you will create a configuration checklist that reveals missing names without revealing secret values, then use separate checks for Telegram and AI. If you have not deployed yet, finish the local check first. The Render polling route below uses a paid Background Worker; configuring secrets does not turn a free Web Service into an always-on bot.

This is for an operations coordinator whose bot works locally but stops at deployment. The useful result is a diagnosis: is configuration missing, is the service type incompatible, or is a particular connection failing? You can investigate each separately instead of changing every setting at once.

👤 Meet Today’s Builder

Edition A — Dan, operations coordinator. Dan is a fictional composite reader used to explain deployment mistakes, not a report of a completed customer or author deployment. His task is to find out why a successfully built bot does not answer.

The Expert Workflows roadmap links the currently available lessons. This article does not depend on unpublished alternative editions.

🛠️ Before You Start

  • Part 1 preparation complete, with bot.py and requirements.txt; a paid worker is optional for the later cloud check
  • Your own bot token, provider endpoint, model name and API key, kept private; preserve any access restrictions from your existing bot
  • Python available locally; budget time separately for troubleshooting or a cloud deployment

📝 Step 1: Why Secrets Live in the Platform, Not the Code

Here’s the principle, and it’s the same one that’s run through every step of this course wearing different clothes.

A local .env is a plaintext configuration file, not an encrypted vault. Keep it out of Git and shared archives. Python does not load it automatically: the existing bot may use python-dotenv, whereas a hosting platform supplies process environment variables directly.

The program reads environment variables with os.getenv(). Enter the exact variable names the bot reads in the intended service’s configuration. Keeping values out of source control reduces accidental publication; it does not make them invisible to the application, authorised administrators or unsafe logging. Never print tokens, keys or the complete environment.

Keep configuration separate from code, but do not treat every storage mechanism as equally protective. Browser extension storage is not equivalent to a server-side secret store. If a key was ever committed or exposed in a log, revoke or rotate it through its issuer; adding .env to .gitignore does not remove an already exposed credential.

📝 Step 2: Entering Your Secrets

For an existing polling deployment, select the intended Background Worker in Render, then Environment → Add Environment Variable. This is a paid service type: check the current plan before creating one. Enter the names below only if they match your code. Use your provider’s documented endpoint and model; the example URL and model are placeholders.

TELEGRAM_TOKEN     →  (your bot token from BotFather)
AI_API_KEY         →  (your AI provider key)
AI_BASE_URL        →  https://your-provider-url/v1
AI_MODEL           →  your-model-name

Three details that prevent the most common mistakes.

Names must match your code exactly. If your code says os.getenv("AI_API_KEY") and your variable is named API_KEY, the host has the value and your code will never find it. Copy the names from your code character for character.

No quotation marks around the values. In the dashboard you type the raw value — sk-abc123, not "sk-abc123". Quotes that were invisible in a .env file become part of the value here.

Check whitespace. Re-enter accidentally padded values. The diagnostic below flags surrounding whitespace without displaying the value; do not assume every version of your bot calls .strip(). A value passing this check can still be invalid, revoked or lack the required permission.

Render offers Save and deploy, Save, rebuild, and deploy, and Save only. Save only does not update the running service until its next deploy. Choose the appropriate option and inspect the resulting logs. See Render’s environment-variable instructions.

Local check: catch configuration mistakes without printing secrets

Save this as config_check.py beside your bot. It uses only Python’s standard library. It reads the current process environment, not a .env file. In a fresh terminal with none of these variables set, python config_check.py should list four missing names and exit with status 1. On a host, run it as a preflight before the bot, for example python config_check.py && python bot.py. This checks names and formatting only; it does not validate endpoint syntax, key validity, permissions, model availability or network access.

"""Offline presence check. Never authenticates or prints configuration values."""
import os
import sys

REQUIRED = ('TELEGRAM_TOKEN', 'AI_API_KEY', 'AI_BASE_URL', 'AI_MODEL')

def check_config(env):
    problems = []
    for name in REQUIRED:
        value = env.get(name, '')
        if not value.strip():
            problems.append(f'{name}: missing or blank')
        elif value != value.strip():
            problems.append(f'{name}: surrounding whitespace; re-enter the value')
        elif value.startswith(('"', "'")) or value.endswith(('"', "'")):
            problems.append(f'{name}: surrounding quote; re-enter the raw value')
    return problems

if __name__ == '__main__':
    issues = check_config(os.environ)
    print('\n'.join(issues) if issues else 'Configuration shape OK; credentials and connectivity NOT tested.')
    sys.exit(1 if issues else 0)

Local verification, 13 September 2026, Python 3.11.4: six isolated subprocess cases used synthetic values. No Telegram, AI or hosting calls were made. Each case checked the exit status and confirmed that supplied values were absent from the output.

Input Observed result
All four names present Exit 0; configuration shape OK, connectivity explicitly not tested
Missing TELEGRAM_TOKEN Exit 1; missing token name reported
API_KEY instead of AI_API_KEY Exit 1; expected key name reported missing
Whitespace-only key Exit 1; blank value reported
Quoted key Exit 1; surrounding quote reported
Key with trailing space Exit 1; surrounding whitespace reported

What this changes: if this check fails, fix configuration before changing networking or prompts. If it passes but the bot stays silent, investigate runtime and authentication separately. A synthetic or revoked key can pass this check, so do not treat exit 0 as a successful deployment.

📝 Step 3: Confirming It Actually Connects

Stop the local polling process and any duplicate instance before testing the cloud worker. Send /start from an authorised Telegram account and check for the expected response. Then send one non-sensitive AI request and check the expected AI behaviour separately. A command reply proves neither AI connectivity nor that the replying instance is your cloud worker; correlate it with the intended deployment’s logs.

If a check fails, record the time, deployment version and redacted error category. Missing configuration, Telegram authentication, provider authentication or billing, and competing polling processes require different fixes. Do not paste a full token-bearing request URL into a screenshot or support message.

Illustrative troubleshooting scenarios: The following symptoms explain two different failure categories. They are not captured Render logs or claims about a particular dashboard badge. Actual wording and status transitions can differ.

⚠️ Dan’s Error Log #2 — The bot that built fine and did nothing

(Teaching scenario — a common mistake reconstructed for learning, not a personal claim.)

🔴 BEFORE

BEFORE: the build step completes, but the bot exits before it can handle a message. The configuration check reports a missing token.

Example diagnostic output from the check below:

TELEGRAM_TOKEN: missing or blank

🤔 Cause

The bot cannot authenticate without its token. A fail-fast check should identify the missing variable name while keeping the secret value out of logs. Missing configuration is different from a present but rejected token.

A build status is not an end-to-end test. Do not infer the precise cause from a green badge, and do not assume the platform will keep showing Live after a process exits. Use the current runtime logs and a controlled message test together.

🟢 AFTER

AFTER: enter the correctly named variable in the intended service and deploy the change. Repeat the configuration check, then the connection checks. Keep these results distinct:

  • Build result: dependencies and build commands completed.
  • Runtime result: the intended process remains running and handles the tested message.

Configuration shape, process health, Telegram delivery and AI response are separate observations. Passing one does not establish the others.

Practical note: A useful diagnostic reports AI_API_KEY: missing or blank, not the value. That gives a colleague enough information to correct the setting without sharing the credential.

⚠️ Dan’s Error Log #3 — “No open ports detected”

(Teaching scenario — a common mistake reconstructed for learning, not a personal claim.)

🔴 BEFORE

BEFORE: a polling-only bot is assigned to a Web Service. The following is an illustrative port-check error, not a captured result from this review:

Port scan timeout reached, no open ports detected.

The Python process may start, but the web deployment cannot satisfy its listening-port requirement.

🤔 Cause

A Web Service must accept HTTP traffic on a listening port. A polling bot makes outbound requests to Telegram and does not automatically open a web server. Supplying its API keys does not solve that mismatch.

This is a genuinely confusing one, because nothing in your code is wrong. It’s a mismatch between what kind of thing your botisand what kind of service you told the platform to expect.

🟢 AFTER

AFTER: use a Background Worker for the existing polling implementation. Use the intended repository and branch, python -m pip install -r requirements.txt as the build command and python bot.py as the start command, if those are your actual filenames. Keep only one polling consumer for this bot token.

Cost boundary: Render does not offer a Free instance for Background Workers. Adding a tiny HTTP endpoint beside a polling loop may satisfy a port check but does not remove free web-service sleep or usage limits. A webhook application is a separate implementation, not a setting that can be applied to this polling code. See Render’s current free-service limits. If you do not want paid hosting, keep the local exercise and mark cloud deployment as not performed.

Practical note: Decide the service type before debugging credentials. Missing configuration and an incompatible service type can occur together; resolving one does not resolve the other.

⚠️ Why This Isn’t Finished

If your own cloud checks passed, record exactly what worked and when. One response establishes a tested path at that moment, not continuous availability.

Apply the correct limit to the correct service. The 15-minute idle rule concerns Render Free Web Services and inbound traffic, not the paid worker route above. A polling-only bot cannot rely on a Telegram message to wake that web service. Part 3 explains the delivery and reliability implications.

Use multiple observations. Runtime logs help diagnose failure, but an end-to-end message test checks what the reader actually cares about. Keep tokens and private message contents out of diagnostic output.

Deployments can interrupt work. A deploy or restart can interrupt an in-flight request. If automatic deploys are enabled, changes to the connected branch may trigger this. Test changes at a suitable time and record the version you tested.

✅ What You Have Now

You have a way to check configuration without disclosing it, a service-type decision and separate tests for Telegram and AI. For the separation of configuration from code, see the Twelve-Factor App configuration principle.

This article’s verified result is the local diagnostic below. Your own cloud result remains unverified until you perform and record the deployment checks; a successful local check alone does not justify saying the bot runs without your laptop.

💡 If You Want to Push It

Practise a missing-variable case in a disposable local environment using synthetic values. Do not deliberately break a worker used by colleagues. Restore the setting and confirm that only the variable name, never the secret, appears in the output.

❓ Do This Before Next Time

If you choose the paid deployment route, stop the local instance, send a non-sensitive test from your phone, and correlate the response with the cloud logs. Record Telegram and AI results separately. If you have not deployed, write “local configuration checked; cloud not tested” and continue when you are ready.

🔗 Next in This Series

[Step 4-A-3/3] Keeping It Awake — The Free-Tier Sleep Problem and What to Do About It follows this configuration lesson. It examines idle behaviour, queued messages and hosting choices. It is scheduled separately; this lesson does not require an unpublished page to complete the local check.

✍️ About the author & how this was made

Written for Life Tech Hack by G. Troy with AI-assisted editing and a local, synthetic configuration test. The test scope and result appear below; no author cloud-deployment experience is claimed here.

See the site’s editorial standards. Provider-specific instructions are linked to primary documentation; recheck current plans before choosing a paid service.