DEV Community: John Wick

Run Python Bots Without Sleep On Railway With StayPresent

John Wick — Thu, 30 Jul 2026 04:39:43 +0000

Deploy a railway python bot that never sleeps — port binding, health checks, self-ping, and crash recovery using StayPresent.

Run Python Bots Without Sleep On Railway With StayPresent

Railway auto-detects Python projects and gets you deployed in minutes, but a railway python bot — a Discord bot, Telegram bot, or scraper — still runs into the same core issue every PaaS presents: the platform expects an HTTP-facing process, and your bot's event loop or gateway connection doesn't naturally provide one. This guide covers deploying a bot to Railway that stays online, using StayPresent to fill that gap.

How Railway Detects and Runs Python Apps
The $PORT Requirement
Setting Up StayPresent
Health Checks in Railway's Dashboard
Self-Ping for Inactivity-Sensitive Plans
Crash Recovery
Full Working Example
Best Practices
Common Mistakes
FAQs
Conclusion

How Railway Detects and Runs Python Apps

Railway auto-detects a Python project from requirements.txt (or pyproject.toml) and builds a container for it automatically via Nixpacks, without requiring a Dockerfile. It then starts your app and expects it to bind to the port Railway assigns via the PORT environment variable, so its own routing and health checks can reach it.

The `$PORT` Requirement

This is the same pattern seen across virtually every modern PaaS: read PORT from the environment rather than hardcoding it.

import os
import staypresent

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

If your bot never binds to this port at all — which is normal, expected behavior for a Discord or Telegram bot — Railway's health checks (if enabled) will report the deployment as unhealthy, even though your bot might be functioning perfectly on its own.

Setting Up StayPresent

Install the production extra so Waitress handles serving instead of Flask's development server:

pip install staypresent[prod]

Your main.py:

import os
import staypresent

staypresent.web.json({
    "status": "running",
    "service": "my-telegram-bot",
})

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Railway's start command is simply:

python main.py

Health Checks in Railway's Dashboard

If you've enabled Railway's health check feature for a service, you can point it specifically at StayPresent's built-in /health endpoint, which always returns {"status": "ok"} — independent of whatever you've configured at your root route:

staypresent.web.json({"status": "running"})
# /health still returns {"status": "ok"} regardless

This separates platform-level health monitoring from any custom status payload you're serving to humans or your own tooling at /.

Self-Ping for Inactivity-Sensitive Plans

Whether inactivity-based sleeping applies depends on your specific Railway plan and configuration — always check Railway's current pricing and usage documentation before assuming behavior either way. If it does apply to your deployment, staypresent.cron() generates outbound traffic against your own public URL to keep it from being treated as idle:

import staypresent

staypresent.cron(
    "https://my-app.up.railway.app",
    interval=240,
)

As with any platform, this must target the actual public URL — pinging 0.0.0.0 or 127.0.0.1 never leaves the machine and has no effect on inactivity detection.

Crash Recovery

Bots crash for mundane reasons, and Railway won't automatically relaunch a subprocess that dies inside your container unless the container itself exits. StayPresent handles that inner layer directly:

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
    restart_on_crash=True,
    max_restarts=5,
    restart_delay=2.0,
    restart_reset_after=60.0,
)

If restarts are ultimately exhausted, StayPresent exits the whole process with the bot's original exit code — letting Railway's own deployment restart policy act as a final backstop.

Full Working Example

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.cron("https://my-app.up.railway.app", interval=240)

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
    threads=8,
    restart_on_crash=True,
    max_restarts=5,
)

Best Practices

Always read PORT dynamically — Railway assigns it per-deployment and it can differ between environments.
Point any configured health check at /health rather than / if your root route serves something custom.
Keep the prod extra installed for any deployment receiving real traffic, not just keep-alive pings.

Common Mistakes

Hardcoding port=8080 instead of reading os.getenv("PORT", 8080) — this can work in some configurations and silently fail in others depending on how Railway is set up.
Assuming Railway's sleep behavior is identical to Render's. Policies differ between platforms and change over time — verify current behavior in Railway's own docs rather than assuming.
Skipping crash recovery because "Railway restarts crashed deployments anyway." Railway's own restart policy operates at the container level; a bot subprocess crashing inside a still-running container is a separate failure mode StayPresent handles directly.

FAQs

Does Railway require a Dockerfile?
No — Railway can auto-detect and build Python projects via Nixpacks without one, though a Dockerfile is also supported if you prefer explicit control.

Can I reuse the same main.py from a Render deployment?
Yes — since both platforms follow the same $PORT convention, the identical entry point typically works unchanged across both.

Do I need staypresent.cron() on Railway?
Only if your specific plan/configuration is subject to inactivity-based sleeping — check Railway's current documentation for your plan before deciding.

Conclusion

A railway python bot stays online the same way a bot on any modern PaaS does: bind to the assigned port, expose a dedicated health endpoint, and let StayPresent supervise the bot process itself. The setup is close to identical across Railway, Render, Koyeb, and Heroku, which is exactly what makes StayPresent a one-time investment rather than per-platform boilerplate.

pip install staypresent[prod]

StayPresent vs Supervisor vs PM2 for Python Bot Process Management

John Wick — Thu, 30 Jul 2026 04:38:52 +0000

Comparing StayPresent, Supervisor, and PM2 for python process management — setup, crash recovery, HTTP port handling, and when each fits.

StayPresent vs Supervisor vs PM2 for Python Bot Process Management

Supervisor and PM2 are two of the most established tools for python process management — keeping a process running, restarting it on crash, managing logs. Both predate StayPresent by years and are proven, widely-used tools. But neither was built with the specific PaaS-deployment problem in mind: satisfying a hosting platform's HTTP port requirement. Here's how all three actually compare for the common case of deploying a bot.

What Each Tool Is Actually For
Installation and Setup
Configuration Style
Crash Recovery Comparison
The HTTP Port Problem
Logging Comparison
Comparison Table
When Each Tool Is the Right Choice
FAQs
Conclusion

What Each Tool Is Actually For

Supervisor is a mature, Python-based process control system, originally designed for Unix-like systems, that manages arbitrary processes via a config file and a control daemon (supervisord). It's general-purpose — it doesn't care whether the process is Python, Node, or a shell script.

PM2 is a Node.js process manager, widely used for Node apps but also commonly used to run Python scripts, offering restart-on-crash, log management, and a built-in monitoring dashboard.

StayPresent is a Python package, not a system-level daemon — it runs inside your own Python process, launching your bot as a subprocess it directly supervises, while also running an HTTP server specifically to satisfy PaaS hosting requirements.

Installation and Setup

Supervisor requires a system-level install and a separate config file, typically outside your project's own codebase:

; /etc/supervisor/conf.d/mybot.conf
[program:mybot]
command=python bot.py
autorestart=true

sudo apt install supervisor
sudo supervisorctl reread
sudo supervisorctl update

PM2 requires Node.js itself as a dependency, even to run a Python script:

npm install -g pm2
pm2 start bot.py --interpreter python3

StayPresent is a pure Python dependency, installed and configured entirely within your own script:

pip install staypresent[prod]

import staypresent
staypresent.run("bot.py")

Configuration Style

Supervisor's configuration lives in a separate .ini-style file, generally outside version control unless you specifically arrange for it (and outside your application's own deploy artifact on most PaaS platforms, which don't give you system-level config access at all). PM2 configuration can live in an ecosystem.config.js file or be passed via CLI flags. StayPresent's configuration is just Python function arguments, living directly in your own entry-point script:

staypresent.run(
    "bot.py",
    restart_on_crash=True,
    max_restarts=5,
    restart_delay=2.0,
)

This matters specifically on PaaS platforms like Render, Railway, or Koyeb, which typically don't give you access to install and configure a system daemon like Supervisor at all — your deployment is just "run this command," which is exactly the model StayPresent fits into.

Crash Recovery Comparison

All three tools handle crash recovery, though with different granularity:

Supervisor supports autorestart, startretries, and backoff timing, configured per-program in its .ini file.
PM2 supports --restart-delay, max_restarts, and exponential backoff, configured via CLI flags or its ecosystem file.
StayPresent supports restart_on_crash, max_restarts, restart_delay, and restart_reset_after — the last of which specifically resets the crash counter after a period of sustained uptime, avoiding a slow accumulation toward the restart ceiling from unrelated, infrequent crashes.

Functionally, all three solve the core problem. The difference is entirely about where that configuration lives and what environment it assumes.

The HTTP Port Problem

This is the actual differentiator for PaaS deployment specifically. Neither Supervisor nor PM2 has any concept of an HTTP health-check port — they're process managers, full stop. If your hosting platform requires a bound HTTP port to consider a deployment healthy, using Supervisor or PM2 alone still leaves you writing a separate Flask (or equivalent) server yourself, exactly like the "custom Flask server" approach covered in other comparisons.

StayPresent bundles both concerns into one call:

staypresent.web.json({"status": "running"})
staypresent.run("bot.py")  # HTTP server + process supervision, together

Logging Comparison

Supervisor writes process stdout/stderr to log files it manages itself, configurable per-program. PM2 provides its own log aggregation and a pm2 logs command. StayPresent logs its own orchestration events (crashes, restarts, shutdowns) through a dedicated "staypresent" Python logger that never touches the root logger — your bot's own stdout/stderr, meanwhile, is inherited normally from the subprocess, the same as it would be under Supervisor or PM2.

Comparison Table

Feature	Supervisor	PM2	StayPresent
Requires system-level install	Yes	Yes (+ Node.js)	No — pure Python package
Works on most PaaS platforms	Rarely (no daemon access)	Rarely (no daemon access)	Yes, by design
Built-in HTTP health endpoint	No	No	Yes
Config location	Separate `.ini` file	CLI / ecosystem file	Python code in your script
Crash counter reset after uptime	No	Partial (backoff-based)	Yes (`restart_reset_after`)
Language dependency	Python-agnostic	Requires Node.js	Native Python

When Each Tool Is the Right Choice

Supervisor remains an excellent choice on a VPS or bare-metal server where you have full system access and want to manage several unrelated processes (not just Python) under one consistent tool. PM2 makes sense if you're already running a Node.js stack alongside a Python script and want one process manager for both. StayPresent is the better fit specifically for PaaS deployments — Render, Railway, Koyeb, Heroku — where you don't have system daemon access at all, and where the HTTP port requirement is the actual problem you're solving, not just process supervision in isolation.

FAQs

Can I use Supervisor or PM2 together with StayPresent?
On a VPS, yes — Supervisor or PM2 could supervise the outer python main.py process (which itself runs StayPresent), giving you a second, outer restart layer on top of StayPresent's own bot-subprocess supervision.

Does StayPresent replace Supervisor entirely on a VPS?
Not necessarily — Supervisor's system-level features (managing multiple unrelated services, log rotation, a control CLI) go beyond what StayPresent aims to do, which is specifically bot-process supervision plus an HTTP port.

Is PM2 a reasonable choice for a pure-Python project?
It works, but it introduces a Node.js dependency purely to manage a Python process — StayPresent avoids that entirely for projects that are otherwise pure Python.

Conclusion

Supervisor and PM2 are solid, mature tools for python process management in environments where you control the underlying system. But most PaaS platforms don't grant that kind of access, and neither tool addresses the HTTP-port health-check requirement those platforms impose. StayPresent solves both problems together, as a pure Python dependency that fits directly into your bot's own entry point.

pip install staypresent[prod]

Run Python Bots Without Sleep On Koyeb With StayPresent

John Wick — Thu, 30 Jul 2026 04:36:50 +0000

Deploy a koyeb python bot with proper health checks, port binding, and crash recovery using StayPresent — Git and Docker deploy paths covered.

Run Python Bots Without Sleep On Koyeb With StayPresent

Koyeb supports deploying straight from a Git repository or from a Dockerfile, and like most serverless-leaning PaaS platforms, it evaluates your service's health through HTTP checks against a port it expects your app to bind. A koyeb python bot — a Discord bot, Telegram bot, or background worker — needs that same small HTTP layer every other platform in this series requires, and StayPresent provides it with the same one-line setup regardless of which Koyeb deploy path you use.

Two Ways to Deploy on Koyeb
The Port Binding Requirement
Setting Up StayPresent
Configuring Koyeb's Health Check Path
Self-Ping Considerations
Crash Recovery
Full Working Example (Git-Based)
Full Working Example (Docker-Based)
Best Practices
Common Mistakes
FAQs
Conclusion

Two Ways to Deploy on Koyeb

Koyeb supports two primary deployment paths for a Python service: a Git-based buildpack deploy, where Koyeb detects and builds your app automatically from requirements.txt, and a Dockerfile-based deploy, where you provide the full container definition yourself. Both ultimately run the same command you specify and expect the same thing from it: a bound HTTP port.

The Port Binding Requirement

Koyeb injects a PORT environment variable, exactly like Render, Railway, and Heroku:

import os
import staypresent

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Without something bound to that port, Koyeb's health checks will report the service as unhealthy — independent of whether your bot itself is running perfectly fine internally.

Setting Up StayPresent

For a Git-based deploy, add the production extra to requirements.txt:

staypresent[prod]

And set your main.py:

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Koyeb's run command:

python main.py

Configuring Koyeb's Health Check Path

By default, a platform's health check often targets /. StayPresent's built-in /health endpoint — which always returns {"status": "ok"} regardless of what's configured at your root route — is generally the better target, since it stays stable even if you later change what / serves:

staypresent.web.json({"status": "running", "version": "1.0"})
# /health remains {"status": "ok"} independently

In Koyeb's service settings, set the health check path explicitly to /health rather than relying on the default.

Self-Ping Considerations

Koyeb's specific behavior around scaling-to-zero or idle handling depends on the service type and plan you've configured — check Koyeb's current documentation for your particular setup rather than assuming. If your deployment is subject to any form of inactivity-based scaling you want to avoid, staypresent.cron() can generate outbound traffic against your own public URL:

staypresent.cron("https://my-app.koyeb.app", interval=240)

Crash Recovery

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
    restart_on_crash=True,
    max_restarts=5,
    restart_delay=2.0,
)

If restarts are ultimately exhausted, StayPresent exits the process with the bot's original exit code, letting Koyeb's own deployment-level restart behavior serve as a final backstop.

Full Working Example (Git-Based)

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
    restart_on_crash=True,
    max_restarts=5,
)

# requirements.txt
staypresent[prod]
python-telegram-bot

Full Working Example (Docker-Based)

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]

main.py is identical to the Git-based example above — the deploy mechanism changes, the StayPresent configuration doesn't.

Best Practices

Set the health check path to /health explicitly in Koyeb's dashboard rather than leaving it on a default that may target /.
Use the Docker deploy path if your bot has system-level dependencies (e.g. ffmpeg) that a buildpack deploy won't install automatically.
Keep main.py platform-agnostic (reading PORT from the environment, targeting the correct public URL for cron()) so the same file works unchanged if you later move to Render or Railway.

Common Mistakes

Leaving the health check path on a default that doesn't match what your root route actually serves, causing false-negative health failures.
Assuming a Git-based deploy and a Docker-based deploy require different StayPresent configuration. They don't — only the deployment mechanism around main.py changes.
Forgetting ffmpeg, ImageMagick, or other system packages a bot might depend on, which a plain Git buildpack deploy won't install — this calls for the Docker path instead.

FAQs

Does Koyeb require a Dockerfile?
No — Git-based buildpack deploys work for standard Python projects without one; Docker is only needed for more customized environments.

Can I use the exact same main.py across Koyeb, Render, and Railway?
Yes, as long as PORT is read from the environment and any self-ping URL is configured per-platform.

Does /health need to be manually created?
No — it's provisioned automatically by StayPresent unless you explicitly register your own response there.

Conclusion

A koyeb python bot, whether deployed via Git or Docker, needs the same thing every PaaS bot deployment needs: a bound HTTP port and a reliable health check target. StayPresent provides both with an identical, minimal setup regardless of which Koyeb deploy path you choose.

pip install staypresent[prod]

StayPresent vs Pulsetic vs Custom Flask Server for Python Bots

John Wick — Thu, 30 Jul 2026 03:41:59 +0000

Comparing StayPresent, Pulsetic, and a hand-rolled Flask server for keeping a python bot alive — external monitoring vs in-process supervision.

StayPresent vs Pulsetic vs Custom Flask Server for Python Bots

A comment on an earlier comparison post asked how StayPresent stacks up against Pulsetic specifically, rather than UptimeRobot — a fair question, since Pulsetic has grown into a genuinely feature-rich external monitoring service in its own right. This post covers the same three-way comparison — an external monitor, a hand-rolled Flask server, and StayPresent — but with Pulsetic's specific feature set in view.

What Pulsetic Actually Is
What Each Approach Solves
Monitoring Depth: Where Pulsetic Pulls Ahead
Crash Recovery: Where Pulsetic Can't Help
Status Pages vs a Bot Status Endpoint
Cost and Free-Tier Limits
Comparison Table
Using Pulsetic and StayPresent Together
FAQs
Conclusion

What Pulsetic Actually Is

Pulsetic is an external website and service uptime monitor, checking your endpoint from multiple global locations every 30 seconds and alerting through phone calls, SMS, email, Slack, and other channels when something goes down. Beyond bare uptime, it supports HTTP, ping, port, keyword, and heartbeat monitoring, along with SSL certificate expiration alerts and scheduled maintenance windows for planned deploys. It also offers customizable status pages with custom domains and password protection, aimed more at communicating uptime to end users than at keeping a background process alive.

What Each Approach Solves

Pulsetic is purely external — it never runs inside your bot's process. It watches your endpoint from the outside and tells you (and optionally your users, via a status page) when something's wrong.

A custom Flask server runs inside your process, alongside your bot, purely to give a hosting platform something to health-check. It doesn't monitor from the outside or alert anyone by itself.

StayPresent also runs inside your process, but goes further than a bare Flask server: it manages your bot as a supervised subprocess, restarts it on crash, and can optionally self-ping your own public URL to prevent host-side inactivity sleep.

These aren't fully overlapping tools — Pulsetic answers "is my bot reachable, and who do I tell if it isn't," while StayPresent answers "how do I keep my bot itself running, and satisfy my host's port requirement in the process."

Monitoring Depth: Where Pulsetic Pulls Ahead

If your priority is genuinely rich external monitoring — response-time trends over time, detailed uptime reports with response times from different locations worldwide, and alerting across several channels at once — Pulsetic goes considerably deeper than anything StayPresent attempts. StayPresent's ping()/cron() are intentionally simple: a GET request, a status code, an elapsed time, and an optional success/failure callback. They're built for keep-warm behavior, not for the kind of historical reporting and multi-location checking Pulsetic specializes in.

Crash Recovery: Where Pulsetic Can't Help

This is the same limitation any external monitor shares: Pulsetic can tell you your bot went down, but it has no mechanism to bring it back up — it doesn't run inside your process and has no access to your bot's subprocess. StayPresent restarts a crashed bot automatically:

staypresent.run(
    "bot.py",
    restart_on_crash=True,
    max_restarts=5,
    restart_delay=2.0,
)

A team relying on Pulsetic alone still needs to be the one who notices the alert and manually restarts the service — or pairs it with something like StayPresent that actually manages the process.

Status Pages vs a Bot Status Endpoint

Pulsetic's status pages with logos, brand colors, and a custom domain are built for communicating with end users during an incident — genuinely useful if your bot has a customer-facing component people check on. StayPresent's web.json()/web.html() responses are a much lighter-weight equivalent: a status payload or dashboard served directly from your bot's own process, useful for your own debugging rather than public-facing incident communication. If you need the latter, Pulsetic's status pages are the more purpose-built tool; if you just need somewhere to glance at your bot's own internal state, StayPresent's built-in responses are enough on their own.

Cost and Free-Tier Limits

Pulsetic's free tier covers 50 monitors and 5-minute check intervals, with faster intervals and advanced features starting around $7.50 a month. StayPresent is MIT licensed and free regardless of scale — but it's solving a different problem, so the comparison isn't quite apples-to-apples: Pulsetic's pricing reflects the cost of running a global monitoring network from the outside, while StayPresent's functionality runs entirely inside a process you already control.

Comparison Table

Feature	Pulsetic	Custom Flask	StayPresent
Runs inside your bot's process	No	Yes	Yes
Multi-location external checks	Yes	No	No
Crash recovery for your bot	No	Manual	Built-in
Self-ping / keep-warm	N/A (is the external checker)	Manual	Built-in
Public-facing status pages	Yes	Manual	Basic (`web.html`/`web.json`)
SSL certificate monitoring	Yes	No	No
Free tier	Yes, limited	N/A	Fully free (MIT)

Using Pulsetic and StayPresent Together

These tools aren't mutually exclusive, and combining them covers more ground than either alone: point Pulsetic at StayPresent's /health endpoint for genuine external, multi-location alerting and SSL monitoring, while StayPresent's own restart_on_crash and cron() handle the parts Pulsetic structurally can't — actually restarting a crashed bot process and generating keep-warm traffic from inside your own deployment.

staypresent.web.json({"status": "running"})
# Point Pulsetic's monitor at https://your-app.example.com/health

staypresent.run(
    "bot.py",
    restart_on_crash=True,
    max_restarts=5,
)

FAQs

Does Pulsetic replace StayPresent's keep-alive HTTP server?
No — Pulsetic checks a URL from the outside; it doesn't provide anything for your hosting platform's own port-binding health check to reach. You still need something like StayPresent (or a custom server) running inside your deployment for that.

Can Pulsetic restart a crashed bot?
No — external monitors like Pulsetic can only detect and alert on downtime, not restart the underlying process, since they have no access to it.

Is Pulsetic worth using if I already have StayPresent's cron() self-ping?
They serve different purposes — cron() is about preventing host-side inactivity sleep; Pulsetic is about knowing (and telling others) when something is actually broken, from an outside vantage point.

Conclusion

Pulsetic and StayPresent aren't really competing for the same job. Pulsetic is a genuinely capable external monitoring and status-page service; StayPresent is an in-process bot supervisor and keep-alive HTTP server. For a python bot deployment, the strongest setup is usually both together — StayPresent keeping the bot itself alive and restarting it on crash, Pulsetic watching from the outside and telling you (or your users) when something still goes wrong.

pip install staypresent[prod]

Security Notes for Serving Static Files with StayPresent

John Wick — Thu, 30 Jul 2026 03:35:04 +0000

What to know about python static file security when using StayPresent's web.html/markdown — directory exposure, path traversal, and URL filtering.

Security Notes for Serving Static Files with StayPresent

Serving a status dashboard or a rendered README with web.html()/web.markdown() is convenient precisely because it automatically picks up neighboring CSS, JS, and images with no extra configuration. That same convenience has a security dimension worth understanding clearly before you point it at a directory. This covers python static file security as it applies specifically to StayPresent: what's protected automatically, and what's still your responsibility to manage.

The Directory-Wide Exposure Behavior
Why This Is Intentional
Path Traversal Protection
The One-Time Directory Warning
Markdown-Specific Protections: Escaping
Markdown-Specific Protections: URL Scheme Filtering
What's Rejected vs What's Allowed
Structuring Directories Safely
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

The Directory-Wide Exposure Behavior

When you call web.html("templates/index.html") or web.markdown("docs/guide.md"), StayPresent doesn't just serve that one file — it serves every file in that file's directory, not only the specific CSS/JS/image files actually referenced from the page. This is what makes relative asset links (href="style.css", src="images/logo.png") work automatically without any extra configuration on your part.

The consequence: if a .env file, your bot's own source code, or a .git/ directory happens to sit in that same directory, it becomes downloadable by anyone who requests it by name — whether or not anything on the page actually links to it.

templates/
├── index.html
├── style.css        <- intentionally public, referenced from index.html
├── .env              <- NOT referenced anywhere, but still reachable

Why This Is Intentional

This isn't an oversight — it's what makes web.html()/web.markdown() usable with zero configuration for the overwhelming majority of legitimate cases (a template directory containing only the page and its assets). Requiring an explicit allowlist of every servable file for every deployment would defeat the "read fresh from disk" simplicity that makes these two functions useful in the first place. StayPresent's own documentation notes that an opt-in allowlist restricting exposure to only referenced files is being considered for a future release — but as things stand, the responsibility for directory contents is on you.

Path Traversal Protection

What StayPresent does protect against automatically is path traversal — a request trying to escape the target directory entirely, via ../ sequences, absolute paths, or similar tricks. Static asset lookups use send_from_directory internally, which refuses to serve any path that would resolve outside the intended directory. So while every file inside templates/ is reachable, nothing outside it is, regardless of how a request tries to reference it.

The One-Time Directory Warning

StayPresent logs a one-time WARNING-level message through the "staypresent" logger the first time html() or markdown() exposes a given directory as a static-asset fallback — specifically as a reminder that this exposure is directory-wide:

import logging

logging.getLogger("staypresent").setLevel(logging.WARNING)
# ... elsewhere ...
staypresent.web.html("templates/index.html")
# WARNING logged once: directory 'templates/' is now servable as static assets

This warning fires once per directory per process, not once per request — it's meant to catch your attention during development or the first deploy, not spam your logs continuously.

Markdown-Specific Protections: Escaping

Beyond directory exposure, web.markdown() has its own layer of protection specific to rendering user-authored (or at least file-authored) content into HTML. Plain text — and every recognized Markdown construct — is HTML-escaped before rendering, applied exactly once per character, including inside link/image URLs and titles. A .md file containing literal <script> tags, or stray <, >, & characters, cannot inject markup into the rendered page. Only a fixed list of recognized block-level raw-HTML tags (the kind used for centered logo/badge headers) is ever passed through unescaped — arbitrary inline HTML is not.

Markdown-Specific Protections: URL Scheme Filtering

Escaping alone doesn't stop an executable destination — a link that's syntactically valid Markdown but points somewhere dangerous. web.markdown() checks link/image URLs against a scheme blocklist independently of escaping:

javascript: and vbscript: — rejected for both links and images, since these run arbitrary script directly.
file: — rejected for both, since it enables local filesystem access.
data: — rejected for links specifically (it can smuggle a full HTML document, including script, into a single click), but still allowed for images, since inline data: images are a common and inert pattern for embedding small icons.

A rejected URL falls back to plain, already-escaped text:

[click me](javascript:alert(1))

renders as the plain text click me — not a working link.

What's Rejected vs What's Allowed

URL type	Links	Images
`http(s)://`	Allowed	Allowed
Relative (`/path`, `./file`)	Allowed	Allowed
Anchor (`#section`)	Allowed	Allowed
`data:`	Rejected	Allowed
`javascript:` / `vbscript:`	Rejected	Rejected
`file:`	Rejected	Rejected

Structuring Directories Safely

The practical takeaway is directory hygiene: keep the directory passed to web.html()/web.markdown() limited to files you're genuinely comfortable being publicly reachable.

# Safer structure
public/
├── dashboard.html
├── style.css
├── logo.png

secrets/
├── .env
├── credentials.json

As long as secrets/ isn't the directory (or a parent of the directory) passed to web.html()/web.markdown(), path traversal protection keeps it unreachable regardless of what's inside public/.

Full Example

import logging
import staypresent

logging.getLogger("staypresent").setLevel(logging.WARNING)

# 'public/' contains only dashboard.html, style.css, and logo.png —
# nothing sensitive lives alongside it.
staypresent.web.html("public/dashboard.html")

staypresent.run("bot.py")

Best Practices

Treat any directory passed to web.html()/web.markdown() as fully public — audit its contents the same way you'd audit a directory served by a real static file server.
Keep secrets, .env files, and source code in a separate directory tree entirely, never alongside a served template or Markdown file.
Leave "staypresent" logging at WARNING or above in production specifically so the one-time directory-exposure notice doesn't get lost in INFO-level noise.

Common Mistakes

Putting a template file directly in a project's root directory, which then exposes the entire project — source files, config, everything — as static assets.
Assuming Markdown rendering sanitizes destinations the same way it escapes text. Escaping and scheme filtering are two separate protections — both matter, and both are handled, but it's worth understanding they're not the same mechanism.
Relying on "nothing links to it" as a security boundary. Every file in the directory is reachable by direct request, whether or not the rendered page itself contains a link to it.

FAQs

Does this affect web.text() or web.json()?
No — directory-wide static asset exposure only applies to web.html() and web.markdown(), since only those two serve files from disk in the first place.

Can I disable static asset serving entirely?
Not currently — it's inherent to how html()/markdown() work. The mitigation is directory hygiene, not a configuration flag.

Does the URL scheme blocklist apply to web.html() too?
No — that specific protection is part of the Markdown renderer. web.html() serves whatever HTML you've written as-is, so any sanitization of links/scripts inside a raw .html file is your own responsibility.

Conclusion

Python static file security with StayPresent comes down to two layers: what's protected automatically (path traversal, HTML escaping, dangerous URL schemes in rendered Markdown) and what's still on you (directory contents). Understanding the difference — and keeping served directories limited to genuinely public files — is what keeps a convenient zero-config feature from becoming an accidental information leak.

pip install staypresent[prod]

How StayPresent's Logging Works (Without Breaking Yours)

John Wick — Thu, 30 Jul 2026 03:33:42 +0000

A guide to python isolated logging with StayPresent's dedicated logger — no root logger mutation, what gets logged, and how to configure it.

How StayPresent's Logging Works (Without Breaking Yours)

A surprisingly common way for a third-party package to quietly break your application's logging is by calling logging.basicConfig() somewhere in its own code — which mutates the root logger and can silently change formatting, duplicate output, or override handlers you already configured for your own loggers. StayPresent avoids this entirely through python isolated logging: everything it logs goes through its own dedicated logger, never the root one.

The Problem with logging.basicConfig()
StayPresent's Dedicated Logger
What Gets Logged, and at What Level
Adjusting Verbosity
Attaching Your Own Handler
Logging During Multi-Bot Runs
Logging During Shutdown
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

The Problem with `logging.basicConfig()`

logging.basicConfig() configures the root logger, which every other logger in your process falls back to unless it's explicitly configured otherwise. If your bot calls it once at startup, and a dependency somewhere else in your stack calls it again, whichever call happens first usually "wins" silently — no error, just unexpected formatting or duplicate log lines that are hard to trace back to their cause. A well-behaved library avoids touching the root logger at all, and instead logs through its own named logger.

StayPresent's Dedicated Logger

StayPresent logs exclusively through a logger named "staypresent", configured with a single dedicated StreamHandler and logger.propagate = False. It never calls logging.basicConfig(), and it never touches the root logger in any way. This means it cannot clobber, duplicate, or reformat log output your own script has already configured for its own, unrelated loggers — StayPresent's logs and your bot's logs coexist without interfering with each other.

What Gets Logged, and at What Level

The "staypresent" logger reports on:

Web server startup — whether waitress or the Flask dev-server fallback is being used, and which host/port it bound to.
Each bot process starting, crashing, restarting, exhausting its restart budget, or exiting cleanly.
Signal-triggered shutdowns (SIGINT/SIGTERM), including a previously-installed handler being chained afterward, if one exists.
Unexpected web-server thread failures, both at startup and later during the run.
Cron pinger start/stop events (at INFO) and individual failed pings (at WARNING, via ping()'s own logging).
A one-time WARNING per directory, the first time web.html()/web.markdown() exposes it as a static-asset fallback.

Adjusting Verbosity

Because it's a normal, named Python logger, you configure it exactly like any other:

import logging

logging.getLogger("staypresent").setLevel(logging.DEBUG)

Turn it down in a quiet production environment:

logging.getLogger("staypresent").setLevel(logging.WARNING)

This setting only affects StayPresent's own log output — it has no effect on your bot's separate loggers, and vice versa.

Attaching Your Own Handler

Since it's a real logger object, you can attach additional handlers — to forward StayPresent's events to a file, a monitoring service, or a Discord webhook, for example:

import logging

file_handler = logging.FileHandler("staypresent.log")
file_handler.setFormatter(logging.Formatter("%(asctime)s %(levelname)s %(message)s"))

logging.getLogger("staypresent").addHandler(file_handler)

This adds to StayPresent's existing dedicated StreamHandler rather than replacing it, so console output and your new handler both receive events unless you explicitly remove the default one.

Logging During Multi-Bot Runs

When running several bots at once, log lines identify which bot they refer to using a label — normally just the filename (bot[0] 'worker.py'), or the dotted module path for bot_module-based bots (bot[0] 'mypkg.bot'). If two bots share an identical filename, StayPresent automatically switches to logging the full file path for every bot sharing that name, specifically so crash/restart messages stay distinguishable in the logs rather than becoming ambiguous.

Logging During Shutdown

On SIGINT/SIGTERM, the shutdown sequence itself is logged — including whether a previously-installed signal handler is being chained afterward. active_cron_handles() is also checked during shutdown, and any pinger still running at that point is logged purely for visibility (it isn't stopped or waited on, since cron pingers run on daemon threads that exit automatically with the process).

Full Example

import logging
import staypresent

# Turn up StayPresent's own logs for a specific debugging session
logging.getLogger("staypresent").setLevel(logging.DEBUG)

# Your bot's own logger, configured completely independently
bot_logger = logging.getLogger("mybot")
bot_logger.setLevel(logging.INFO)
bot_logger.addHandler(logging.StreamHandler())

staypresent.web.json({"status": "running"})
staypresent.run("bot.py")

Both loggers coexist cleanly — turning StayPresent's level up or down has zero effect on mybot's own output.

Best Practices

Turn "staypresent" up to DEBUG temporarily when diagnosing a deployment issue (a bot that won't stay up, a crash loop), then back down once resolved.
Attach a FileHandler or remote-logging handler to "staypresent" if you want restart/crash events specifically forwarded somewhere durable, separate from your bot's own application logs.
Don't call logging.basicConfig() in your own bot script expecting it to also configure StayPresent's output — it won't, by design; configure "staypresent" directly instead.

Common Mistakes

Assuming logging.basicConfig() in your own code affects StayPresent's logs. It doesn't — StayPresent never falls back to root logger configuration, since it never propagates to the root logger at all.
Setting the level on the wrong logger. logging.getLogger("staypresent"), not logging.getLogger() (the root logger) or your own bot's logger name, controls StayPresent's verbosity specifically.
Expecting bot subprocess output to appear through the "staypresent" logger. Your bot runs as a separate subprocess with its own stdout/stderr — "staypresent" logs StayPresent's own orchestration events, not your bot's internal application logs.

FAQs

Does StayPresent ever call logging.basicConfig()?
No, never — this is a deliberate design choice specifically to avoid interfering with logging you've already configured elsewhere in your application.

Can I completely silence StayPresent's logs?
Yes — set the level above CRITICAL, or remove/replace its handlers directly if you want full control over its output destination.

Does the logging level affect what StayPresent actually does?
No — logging is purely observational. Crash recovery, restarts, and shutdown behavior all happen the same way regardless of what level "staypresent" is set to.

Conclusion

Python isolated logging is a small design detail that saves real debugging time — StayPresent's dedicated "staypresent" logger means you can turn its verbosity up or down, attach your own handlers, and trust that none of it touches the logging you've already built for your bot's own code.

pip install staypresent[prod]

Graceful Shutdown and Signal Handling in StayPresent

John Wick — Thu, 30 Jul 2026 03:32:12 +0000

How python graceful shutdown works in StayPresent — SIGINT/SIGTERM handling, install_signal_handlers, and chaining your own signal handler.

Graceful Shutdown and Signal Handling in StayPresent

Deploy platforms and container orchestrators don't just kill your process when they want it to stop — they send a signal first and expect your application to clean up. A bot that ignores SIGTERM risks corrupted state, orphaned subprocesses, or a database write cut off mid-transaction. This guide covers exactly how python graceful shutdown works inside StayPresent, and how to hook your own cleanup logic into it.

Why Signals Matter for Deployment
What Happens on SIGINT/SIGTERM by Default
Shutdown During a Restart Backoff
Chaining Your Own Signal Handler
Disabling StayPresent's Signal Handling
Signals and the Main Thread Requirement
Multi-Bot Shutdown Behavior
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

Why Signals Matter for Deployment

When Render, Railway, Docker, or systemctl stop needs your process to shut down — for a redeploy, a scale-down event, or a manual stop — the standard mechanism is a SIGTERM signal, giving the process a window to shut down cleanly before a harder SIGKILL follows. Ctrl+C in a terminal sends SIGINT, the interactive equivalent. Handling both properly is what separates "the bot stopped" from "the bot stopped correctly."

What Happens on SIGINT/SIGTERM by Default

By default (install_signal_handlers=True, StayPresent's own default), receiving SIGINT or SIGTERM triggers a clean, coordinated teardown:

import staypresent

staypresent.run("bot.py")
# Ctrl+C -> web server and bot process both shut down cleanly

Both the web server and every running bot subprocess are terminated as part of this sequence — not just one or the other.

Shutdown During a Restart Backoff

There's a subtle race condition this has to handle correctly: what if a signal arrives while a crashed bot is sitting in its restart_delay backoff, waiting to respawn? StayPresent synchronizes shutdown and the pending respawn so that exactly one of them wins:

Either the respawn is cancelled before it happens, or
Shutdown terminates the freshly-respawned process too.

Either way, a shutdown can never leave an untracked, un-terminated bot process running in the background — which is exactly the kind of leak that's easy to introduce with hand-rolled process supervision and hard to notice until your host's process count creeps up over time.

The restart_delay wait itself is also interruptible — a signal arriving during it wakes the bot's monitor thread immediately, rather than shutdown being held up waiting out the full backoff period.

Chaining Your Own Signal Handler

If your own script already registers a handler for SIGINT/SIGTERM before calling run(), StayPresent doesn't silently discard it:

import signal
import staypresent

def my_cleanup(signum, frame):
    print("Flushing local cache before shutdown...")

signal.signal(signal.SIGTERM, my_cleanup)

staypresent.run("bot.py")
# On SIGTERM: StayPresent's own cleanup runs first (terminating bot
# processes, logging active cron pingers), THEN my_cleanup runs.

This ordering matters: StayPresent's own teardown (bot processes, server, cron pinger visibility) happens first, and your previously-installed handler is called afterward — so your cleanup code can safely assume the bots are already stopped by the time it runs.

Disabling StayPresent's Signal Handling

Set install_signal_handlers=False if your script wants full, exclusive control over shutdown signaling — for example, if you're embedding staypresent.run() inside a larger application that already has its own signal-handling framework:

staypresent.run(
    "bot.py",
    install_signal_handlers=False,
)

With this set, StayPresent won't install any SIGINT/SIGTERM handling of its own at all — shutdown behavior becomes entirely whatever your own code implements.

Signals and the Main Thread Requirement

Python signal handlers can only be registered on the main thread — this is a Python/OS-level constraint, not something StayPresent can work around. If run() is called from a non-main thread, a warning is logged and graceful signal handling is simply skipped rather than raising an exception:

import threading
import staypresent

def start():
    staypresent.run("bot.py")  # WARNING logged, signal handling skipped

threading.Thread(target=start).start()

Multi-Bot Shutdown Behavior

With multiple bots (via bot_file as a list, bot_module as a list, or bots), a SIGINT/SIGTERM terminates the web server and every running bot process, not just one. Each bot's own crash-recovery-vs-shutdown race is handled independently and safely, using the same synchronization described above.

Full Example

import signal
import staypresent

def notify_shutdown(signum, frame):
    print("Bot(s) shutting down, notifying monitoring...")

signal.signal(signal.SIGTERM, notify_shutdown)
signal.signal(signal.SIGINT, notify_shutdown)

staypresent.web.json({"status": "running"})

staypresent.run(
    bots=[
        {"file": "telegram_bot.py"},
        {"file": "worker.py"},
    ],
    restart_on_crash=True,
)

Best Practices

Register your own signal handlers before calling staypresent.run(), so they get chained rather than needing to be re-registered afterward.
Keep chained cleanup handlers fast — a slow handler delays how quickly the process actually exits after StayPresent's own teardown finishes.
Only set install_signal_handlers=False if you have a concrete reason to manage signals yourself; the default handles the bot-process-and-server coordination correctly out of the box.

Common Mistakes

Registering a signal handler after calling run(). StayPresent only chains handlers that were already installed before run() starts — anything registered afterward simply replaces StayPresent's own handler rather than being chained to it.
Assuming install_signal_handlers=False means "no shutdown happens." It just means StayPresent won't install its own signal handling — your own code is then fully responsible for triggering and coordinating a clean shutdown.
Calling run() from a background thread and being surprised graceful shutdown doesn't work. This is a hard Python constraint on where signal handlers can be registered, not a bug — call run() from the main thread if you need signal handling.

FAQs

Does SIGKILL trigger graceful shutdown?
No — SIGKILL can't be caught by any process, StayPresent included. It terminates immediately with no cleanup opportunity at all, which is why platforms typically send SIGTERM first and only escalate to SIGKILL after a grace period.

What happens to cron() pingers on shutdown?
They run on daemon threads and aren't explicitly stopped by run()'s shutdown sequence — they're simply logged for visibility and then torn down automatically when the process exits, since daemon threads don't block process exit.

Can I trigger the same shutdown sequence programmatically, without an actual OS signal?
Not directly — shutdown is driven by the signal handler itself; sending your own process a real SIGTERM (e.g. via os.kill(os.getpid(), signal.SIGTERM)) is the supported way to trigger it from within your own code.

Conclusion

Python graceful shutdown isn't just about catching Ctrl+C — it's about correctly coordinating a signal against an in-flight restart, terminating every bot process (not just one), and giving your own cleanup code a reliable place to run. StayPresent handles all three by default, while still leaving room to chain your own handler or opt out entirely.

pip install staypresent[prod]

A Deep Dive on StayPresent's ping() and cron() Keep-Warm API

John Wick — Thu, 30 Jul 2026 03:06:26 +0000

Everything about the python self ping scheduler in StayPresent — ping(), cron(), CronHandle, callbacks, and active_cron_handles().

A Deep Dive on StayPresent's ping() and cron() Keep-Warm API

Most guides on keep-warm pinging stop at "call cron() every few minutes." That covers the basic case, but StayPresent's python self ping scheduler has more nuance worth understanding — return values, callback safety, CronHandle lifecycle management, and how it interacts with graceful shutdown. This is the deep-dive reference.

ping(): The Synchronous Building Block
Return Value in Detail
Host Resolution Rules
cron(): Scheduling Repeated Pings
Callbacks: on_success and on_failure
The CronHandle Object
Discovering Handles with active_cron_handles()
Interaction with Graceful Shutdown
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

`ping()`: The Synchronous Building Block

cron() is really just ping() called on a schedule, so understanding ping() first makes everything else straightforward:

import staypresent

result = staypresent.ping("https://my-bot.onrender.com")

Signature: staypresent.ping(host: str, port: int = None, path: str = "/", timeout: float = 10.0, https: bool = None) -> dict

It sends a single, blocking HTTP GET and returns immediately with the outcome — there's no background thread involved at all for a bare ping() call.

Return Value in Detail

{
    "url": "https://my-bot.onrender.com/",
    "ok": True,
    "status_code": 200,
    "elapsed": 0.42,
    "error": None,
}

ok is True for any 2xx or 3xx response — not just a bare 200.
elapsed is in seconds, rounded to 3 decimal places.
error is None on success, or a short description on failure (an HTTP error status, a timeout, a DNS failure, connection refused, etc.).

result = staypresent.ping("https://my-bot.onrender.com")
if not result["ok"]:
    print("Something's wrong:", result["error"])

Host Resolution Rules

host is flexible by design — a bare hostname/IP, a "host:port"-style string, or a full URL:

If host is a full URL, port/path/https are ignored — and if you passed non-default values for any of them anyway, a warning is logged so the mismatch doesn't go unnoticed.
"0.0.0.0" and "::" are treated as "127.0.0.1", since they're bind addresses, not something you can actually send an outgoing request to.
https defaults to True for anything that isn't a local address, and False for "127.0.0.1"/"localhost"/"::1" — matching what staypresent.run() itself serves locally, so a quick local sanity check (staypresent.ping("127.0.0.1", port=8080)) works with zero extra configuration.

`cron()`: Scheduling Repeated Pings

import staypresent

handle = staypresent.cron("https://my-bot.onrender.com", interval=300)

Signature:

staypresent.cron(
    host: str,
    port: int = None,
    path: str = "/",
    interval: float = 300.0,
    repeat: bool = True,
    timeout: float = 10.0,
    https: bool = None,
    on_success=None,
    on_failure=None,
) -> CronHandle

host/port/path/https are validated immediately, at call time — a bad value raises right away rather than only failing silently on the very first scheduled tick, which would otherwise be much harder to notice. interval must be > 0. repeat=False pings exactly once instead of forever, useful for a one-shot delayed warm-up rather than continuous keep-alive.

Callbacks: `on_success` and `on_failure`

staypresent.cron(
    "https://my-bot.onrender.com",
    interval=240,
    on_success=lambda r: print(f"warm ping ok ({r['elapsed']}s)"),
    on_failure=lambda r: print(f"warm ping failed: {r['error']}"),
)

Both callbacks receive the same result dict ping() itself returns. Critically, an exception raised inside either callback is caught, logged, and swallowed — it can never kill the background pinger thread. This means a buggy on_success handler degrades to "this particular callback silently didn't do its job" rather than "keep-warm pinging stopped entirely because of an unrelated bug in a logging callback."

The `CronHandle` Object

cron() returns a CronHandle you can use to manage that specific pinger:

handle = staypresent.cron("https://my-bot.onrender.com", interval=240)

handle.is_running   # True/False
handle.url           # the URL this cron job pings
handle.stop(wait=False, timeout=None)  # stop pinging; safe to call more than once

stop() is idempotent — calling it multiple times, or on a handle that's already stopped, doesn't raise.

Discovering Handles with `active_cron_handles()`

Plenty of real code discards cron()'s return value entirely for a pure fire-and-forget keep-warm pinger:

staypresent.cron("https://my-bot.onrender.com")  # no assignment at all

That's completely fine — active_cron_handles() still finds it later, since StayPresent's own registry holds a reference to every handle regardless of whether you kept one:

for handle in staypresent.active_cron_handles():
    print(handle.url, handle.is_running)

A handle stays in the registry until its .stop() is called (or its thread otherwise exits) — a discarded return value never causes a keep-warm job to silently vanish from introspection.

Interaction with Graceful Shutdown

Cron pingers run on daemon background threads, so they're never registered with staypresent.run()'s own shutdown handling the way bot processes are. In practice this is fine: daemon threads are torn down automatically the moment the process exits, with no cleanup needed. staypresent.run() does call active_cron_handles() during its own Ctrl+C/SIGTERM shutdown sequence and logs any pingers still active at that point — purely for visibility, since it neither stops nor waits on them.

Full Example

import os
import staypresent

def log_failure(result):
    print(f"keep-warm ping failed: {result['error']}")

staypresent.web.json({"status": "running"})

handle = staypresent.cron(
    "https://my-bot.onrender.com",
    interval=240,
    on_failure=log_failure,
)

staypresent.run(
    "bot.py",
    port=int(os.getenv("PORT", 8080)),
)

Best Practices

Use on_failure to surface keep-warm ping failures somewhere visible (logs, a monitoring channel) — a silently failing keep-warm pinger looks identical to a healthy one until your service unexpectedly goes to sleep.
Prefer a bare ping() call for a one-off manual health check (e.g. in a debugging script), and cron() only for actual ongoing keep-warm behavior.
If you need to stop pinging dynamically (e.g. during a maintenance window), keep the returned CronHandle around and call .stop() rather than trying to kill the thread yourself.

Common Mistakes

Assuming a callback exception stops the pinger. It doesn't — it's caught and logged, which is good for resilience but means a silently broken callback might go unnoticed if you're not checking logs.
Pinging "0.0.0.0" expecting it to reach the public internet. It's treated as "127.0.0.1" — a purely local loopback check, not an external ping.
Losing track of a CronHandle and assuming there's no way to stop it later. active_cron_handles() recovers it even if you never stored the return value yourself.

FAQs

Does cron() guarantee pings happen exactly every interval seconds?
Pings run one at a time — if a ping takes a while to time out, the gap before the next one grows accordingly rather than piling up parallel requests, so under failure conditions the effective interval can run longer than configured.

Can I run several cron() pingers at once?
Yes — each call returns its own independent CronHandle, and active_cron_handles() returns all of them.

Does ping() block my whole application?
Only the calling thread, for up to timeout seconds. Use cron() if you need pinging to happen in the background without blocking your main script.

Conclusion

StayPresent's python self ping scheduler is more than "hit a URL every few minutes" — ping()'s detailed return value, cron()'s exception-safe callbacks, and CronHandle/active_cron_handles() together give you real visibility and control over keep-warm behavior, instead of a black-box background thread you just have to trust.

pip install staypresent[prod]

Serving Multiple Endpoints from One Bot with StayPresent

John Wick — Thu, 30 Jul 2026 03:01:41 +0000

How to host multiple flask style endpoints for different bots or status pages using StayPresent's path parameter, get_all, and remove.

Serving Multiple Endpoints from One Bot with StayPresent

A single root route is fine for a simple keep-alive check, but as soon as you're running more than one bot, or want a separate status page from your machine-readable health payload, you need multiple endpoints on the same server. StayPresent supports this natively through a path argument on every response function, without needing to reach for raw Flask routing.

Why One Route Isn't Enough
Registering Responses at Custom Paths
Path Normalization Rules
Trailing Slashes and Static Assets
Inspecting Every Registered Path
Removing a Registered Path
What Happens When Paths Collide
Full Example: Per-Bot Status Pages
Best Practices
Common Mistakes
FAQs
Conclusion

Why One Route Isn't Enough

If you're running two bots via staypresent.run(bots=[...]), a single JSON blob at / quickly becomes cramped — you end up manually merging both bots' status into one payload. It's cleaner to give each bot its own endpoint, and keep / as a simple top-level summary or the default keep-alive response.

Registering Responses at Custom Paths

text(), json(), html(), and markdown() all accept an optional path argument, defaulting to "/":

import staypresent

staypresent.web.json({"status": "online"}, path="/")
staypresent.web.text("bot #2 is alive", path="/bot2")
staypresent.web.html("dashboard.html", path="/dashboard")
staypresent.web.markdown("CHANGELOG.md", path="/changelog")

Each of these is served completely independently — a request to /bot2 has no relation to whatever is configured at /.

Path Normalization Rules

Paths are normalized automatically to avoid subtle, silent bugs:

Surrounding whitespace is stripped — " /status" and "/status " (easy to introduce via an f-string) are treated the same as "/status", rather than silently registering a route nothing will ever match.
The path must start with /.
Repeated slashes are collapsed.
A trailing slash is stripped, so "/status/" and "/status" refer to the same route.

Paths must not contain ? or # — those belong in a query string or fragment, not a route, and StayPresent raises ValueError if they appear. path itself must be a non-empty string; anything else raises TypeError, and an empty or whitespace-only string raises ValueError.

Trailing Slashes and Static Assets

For html()/markdown() registered at any path other than "/", a bare request to that path is automatically redirected (HTTP 308) to a trailing-slash version. A request to /dashboard redirects to /dashboard/. This is what lets relative asset links inside the file — href="style.css", src="images/logo.png" — resolve against that file's own directory instead of its parent. text()/json() responses don't need this since they don't reference any static assets.

Static asset lookups themselves use the longest matching path prefix across every registered html()/markdown() route, so overlapping mounts resolve unambiguously — a request for /dashboard/style.css is served from dashboard.html's own directory, never mistakenly from the root page's directory.

Inspecting Every Registered Path

Three helpers let you introspect what's currently configured, which is useful both for debugging and for building your own tooling on top:

staypresent.web.paths()
# ['/', '/bot2', '/changelog', '/dashboard']

staypresent.web.get_all()
# {'/': {'type': 'json', 'value': {...}}, '/bot2': {...}, ...}

staypresent.web.get("/bot2")
# {'type': 'text', 'value': 'bot #2 is alive'}

Both get() and get_all() return an independent deep copy of the current state — mutating the returned dictionary has no effect on what's actually being served. To change the live response, call text()/json()/html()/markdown() again.

Removing a Registered Path

staypresent.web.remove("/bot2")
# True  (it was registered and is now removed)

staypresent.web.remove("/bot2")
# False (nothing was registered there)

This is useful for a bot that's been shut down or decommissioned but whose status endpoint you don't want to keep serving stale data at.

What Happens When Paths Collide

Registering the same path twice is completely normal and silent — it's exactly how you update a live response, like calling json() again with fresh data to refresh a status endpoint:

staypresent.web.json({"status": "starting"})
# ... later ...
staypresent.web.json({"status": "running"})   # no warning, this is expected usage

What does get logged is the response type at a path changing — e.g. a path held "json" and a later call registers "text" there instead. That's a much stronger signal that two different call sites weren't aware they were both claiming the same path:

staypresent.web.json({"status": "online"}, path="/status")
# elsewhere in the code...
staypresent.web.text("Online", path="/status")
# WARNING logged: path '/status' changed from 'json' to 'text'

Nothing is blocked either way — the newest registration always wins — this only affects what gets logged.

Full Example: Per-Bot Status Pages

import staypresent

staypresent.web.json({"status": "running", "bots": ["telegram", "discord"]})
staypresent.web.json({"status": "online", "queue_depth": 0}, path="/telegram")
staypresent.web.json({"status": "online", "shard": 0}, path="/discord")

staypresent.run(bots=[
    {"file": "telegram_bot.py"},
    {"file": "discord_bot.py"},
])

Each bot's own status can then be checked independently — /telegram, /discord, and the summary at / — all from a single deployment and port.

Best Practices

Reserve / for either the default keep-alive response or a top-level summary, and give each bot its own dedicated path.
Use web.paths() during development to sanity-check exactly what's currently registered before deploying.
If a bot shuts down permanently, call web.remove() on its path rather than leaving a stale status response behind.

Common Mistakes

Accidentally reusing a path between two unrelated bots without noticing — watch for the WARNING log line about a response-type change, since that's the signal something's colliding.
Forgetting the trailing-slash redirect for html()/markdown() and hardcoding a bare path (without the slash) as a link target elsewhere, causing an unnecessary extra redirect hop.
Building a path with untrimmed whitespace from user input or an f-string and assuming it silently fails — it doesn't; normalization handles it, but it's worth understanding why " /status" and "/status" behave identically.

FAQs

Can I register a path other than /health for health-style checks?
Yes — any path is fair game; /health is only special in that it has a built-in default when nothing else is registered there.

Does removing a path affect other registered paths?
No — web.remove() only affects the specific path you pass; everything else stays exactly as configured.

Is there a limit to how many paths I can register?
No documented limit — register as many independent responses as your deployment needs.

Conclusion

Serving multiple endpoints from one bot — or from several bots sharing one deployment — doesn't require reaching for raw Flask routes. StayPresent's path argument, combined with get_all(), paths(), and remove(), gives you a small but complete routing layer without leaving the staypresent.web module.

pip install staypresent[prod]

Fixing "Attempted Relative Import" Errors with StayPresent's bot_module

John Wick — Thu, 30 Jul 2026 02:59:08 +0000

How to fix the python attempted relative import error when deploying a packaged bot, using StayPresent's bot_module parameter instead of bot_file.

Fixing "Attempted Relative Import" Errors with StayPresent's bot_module

If your bot is structured as a proper Python package — with relative imports like from . import handlers scattered across its modules — you've probably hit this the moment you tried to run it directly:

ImportError: attempted relative import with no known parent package

This is one of the most common attempted relative import errors developers run into when deploying a packaged bot, and it has nothing to do with your bot's logic — it's purely about how the script gets launched. This guide covers why it happens and how StayPresent's bot_module parameter fixes it without restructuring your project.

Why the Error Happens
python file.py vs python -m module
Using bot_module
Multiple Module-Based Bots
Mixing File-Based and Module-Based Bots
What's Different From bot_file
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

Why the Error Happens

Python treats a script run directly (python bot.py) as a top-level module with no package context — it has no __package__, so any from . import something inside it (or inside anything it imports) fails immediately, because there's no "parent package" for the dot to refer to. This has nothing to do with your file structure being wrong; it's purely a consequence of how the interpreter was invoked.

`python file.py` vs `python -m module`

Running python mypkg/bot.py executes the file as a standalone script. Running python -m mypkg.bot instead executes it as a module inside its package, with __package__ set correctly — which is exactly what relative imports need to resolve.

project/
├── mypkg/
│   ├── __init__.py
│   ├── bot.py        # uses `from . import handlers`
│   └── handlers.py

python mypkg/bot.py       # ImportError: attempted relative import
python -m mypkg.bot       # works correctly

Using `bot_module`

staypresent.run()'s bot_file parameter runs your bot the same way python <file> would — which means it inherits this exact limitation. bot_module runs it the way python -m <module> would instead:

import staypresent

staypresent.run(bot_module="mypkg.bot")

No changes to your bot's own code are needed — the fix is entirely in how StayPresent launches it.

Multiple Module-Based Bots

Just like bot_file, bot_module accepts a list for multiple bots, each independently supervised:

staypresent.run(bot_module=["mypkg.bot", "mypkg.worker"])

bot_args/env apply identically to every module in the list, exactly as they would with bot_file.

Mixing File-Based and Module-Based Bots

Inside the bots parameter, use "module" instead of "file" per entry — and you can freely combine both styles in the same call:

import staypresent

staypresent.run(bots=[
    {"file": "telegram_bot.py", "args": ["--verbose"]},
    {"module": "discord_bot.worker", "env": {"SHARD": "0"}},
])

Each entry must set exactly one of "file"/"module" — setting both, or neither, raises TypeError.

What's Different From `bot_file`

A few important differences to be aware of:

No existence check up front. A file path can be checked for existence before anything starts; a module path genuinely can't be verified as importable without actually importing it — which would mean running its parent packages' __init__.py as a side effect inside the orchestrating process, something StayPresent deliberately avoids. A missing or misspelled module isn't caught until that bot subprocess actually starts and Python itself reports No module named '...' — which is then handled through the normal crash/restart logic like any other failure.
Working directory matters. The subprocess is launched from the same working directory as your orchestrating script. bot_module="mypkg.bot" needs to be resolvable from wherever you actually run your main.py, exactly as if you'd typed python -m mypkg.bot from that same location yourself.
Log labels use the dotted module path. Instead of a filename, log lines show something like bot[0] 'mypkg.bot'. If two bots share the exact same module string, there's no further-qualifying fallback the way there is for file paths (no "directory" to disambiguate with) — those log lines are distinguished only by their bot[i] index.

Full Example

import os
import staypresent

staypresent.web.json({"status": "running"})

staypresent.run(
    bot_module="mypkg.bot",
    port=int(os.getenv("PORT", 8080)),
    restart_on_crash=True,
    max_restarts=5,
)

Best Practices

If your bot already runs correctly locally via python -m mypkg.bot, use bot_module in staypresent.run() rather than trying to work around relative imports with sys.path hacks.
Keep your deployment's working directory consistent between local testing and production — if python -m mypkg.bot only works from a specific directory locally, that same constraint applies to your hosting platform's start command.
Since module paths aren't validated up front, watch your logs closely on the very first deploy of a module-based bot to catch a typo'd module path quickly.

Common Mistakes

Passing a file path to bot_module (e.g. bot_module="mypkg/bot.py") instead of a dotted module path ("mypkg.bot") — this will fail the same way running python -m mypkg/bot.py would from the command line.
Assuming bot_module validates the module exists before starting, and being surprised when a typo only surfaces as a crash-and-restart cycle rather than an immediate, upfront error.
Running the orchestrating script from the wrong directory, so mypkg.bot can't be found even though the code itself is correct.

FAQs

Do I need to change my bot's code to use bot_module?
No — if your bot already works when launched with python -m, no code changes are needed at all.

Can I mix bot_file and bot_module at the top level of run()?
No, they're mutually exclusive at the top level — use the bots list if you need both styles in the same deployment.

Why doesn't StayPresent just validate the module up front like it does for files?
Verifying a module is importable requires actually importing it, which means executing its package's __init__.py as a side effect — something StayPresent avoids doing inside the process that's supposed to just be orchestrating, not running, your bot's code.

Conclusion

The attempted relative import error is one of the most common surprises when deploying a properly packaged bot. bot_module solves it by launching your bot exactly the way python -m would, with no restructuring of your project and no sys.path workarounds required.

pip install staypresent[prod]

Turn Your README Into a Live Website with StayPresent's Markdown Renderer

John Wick — Thu, 30 Jul 2026 02:57:06 +0000

How to serve a markdown to html python page — README, changelog, or docs — with zero dependencies using StayPresent's built-in renderer.

Turn Your README Into a Live Website with StayPresent's Markdown Renderer

Most bots already have a README.md or CHANGELOG.md sitting in the repo, fully written and maintained, but invisible to anyone who isn't looking at the source code. StayPresent's web.markdown() turns any markdown to html python file into a styled, GitHub-like web page — served directly from your bot's own HTTP server, with zero extra dependencies.

Why Serve Markdown Directly
Basic Usage
What the Renderer Supports
Light, Dark, and Auto Theming
Favicon, Title, and Description
Security: Escaping and URL Filtering
What It Doesn't Support
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

Why Serve Markdown Directly

A CHANGELOG.md is genuinely useful to end users and other developers — but only if they can actually read it without cloning the repo. Since StayPresent's HTTP server already exists for keep-alive purposes, serving that same Markdown file as a proper web page costs nothing extra and requires no separate documentation site or static site generator.

Basic Usage

import staypresent

staypresent.web.markdown("CHANGELOG.md")
staypresent.run("bot.py")

Like html(), the file is read and re-rendered fresh on every request — editing CHANGELOG.md on disk is reflected the next time someone loads the page, with no restart required.

Signature:

staypresent.web.markdown(
    file_path: str,
    path: str = "/",
    mode: str = "auto",
    favicon: str = None,
    title: str = None,
    description: str = None,
) -> None

file_path must exist at call time — a typo raises FileNotFoundError immediately rather than only 404ing once a browser requests the page.

What the Renderer Supports

Everything is handled by StayPresent's own built-in renderer — no markdown package or any other dependency is required. It covers the constructs people actually use in real READMEs and docs:

ATX and Setext headings (levels 1–6), each with a stable, GitHub-compatible anchor id.
Bold, italic, bold-italic, and strikethrough.
Inline code spans, including multi-backtick spans.
Links, images, and bare autolinks — including URLs with a single level of balanced parentheses.
Unordered and ordered lists, including nesting, multi-paragraph items, tight/loose rendering, custom start numbers, and GitHub-style task-list checkboxes (- [ ] / - [x]).
Nested blockquotes.
Fenced and indented code blocks, with language-tag syntax highlighting hooks.
GitHub-flavored pipe tables, including per-column alignment.
Horizontal rules and hard line breaks.
Raw HTML passthrough for recognized block-level tags — which is what makes a centered logo/badge header at the top of a README render correctly.
Backslash escapes for literal punctuation.

Nested inline content — a code span or bold text inside a link, or an image inside a link (the common "clickable badge" pattern) — is fully supported:

[![badge](badge.svg)](https://example.com)

renders as a proper clickable image link, not broken markup.

Light, Dark, and Auto Theming

mode controls how the rendered page handles color scheme:

staypresent.web.markdown("guide.md", mode="dark")

mode="auto" (default): the page includes <meta name="color-scheme" content="light dark"> with no forced theme — the visitor's own OS/browser preference decides.
mode="light" / mode="dark": forces that theme for every visitor via a data-theme attribute, regardless of their own system setting.

mode is case-insensitive and whitespace-tolerant (" Dark " works fine); anything outside "light"/"dark"/"auto"/None raises ValueError.

Favicon, Title, and Description

staypresent.web.markdown(
    "docs/guide.md",
    path="/docs",
    favicon="favicon.png",
    title="Project Docs",
    description="Everything you need to get started.",
)

favicon accepts either a direct URL (used as-is) or a relative path next to file_path — resolved the same way neighboring static assets already are, and checked for existence immediately, just like file_path itself.
title sets both <title> and an og:title Open Graph tag, falling back to the Markdown file's own filename if omitted.
description adds a <meta name="description"> tag plus og:description — useful for link-preview cards when the page gets shared in a chat app or on social media.

Security: Escaping and URL Filtering

Plain text and every recognized Markdown construct is HTML-escaped before rendering, so a .md file containing <script> tags or stray </>/& characters can't inject markup into the page — only a fixed list of recognized block-level raw-HTML tags is ever passed through unescaped.

Link and image destinations are additionally checked against a scheme blocklist, independent of the escaping above: javascript: and vbscript: are rejected outright for both links and images, file: is rejected for both, and data: is rejected for links specifically (while still permitted for images, since inline data: images are a common, inert pattern). A rejected URL simply falls back to plain, escaped text rather than becoming a working link.

Neighboring files are exposed the same way html() exposes them. Everything in file_path's directory becomes servable as a static asset — not only the files actually referenced from the page. Keep the Markdown file's directory limited to files you're comfortable being publicly reachable; StayPresent logs a one-time WARNING the first time a directory gets exposed this way.

What It Doesn't Support

This is a lightweight renderer, not a full CommonMark implementation. It intentionally does not support: footnotes, definition lists as distinct syntax, custom containers/admonitions, LaTeX/math, reference-style links ([text][ref] + a separate [ref]: url line), or blockquote lazy continuation. For any of these, pre-render your Markdown with a different tool and serve the resulting HTML with web.html() instead.

Full Example

import staypresent

staypresent.web.markdown(
    "README.md",
    path="/",
    mode="auto",
    title="My Bot",
    description="A Telegram bot for X, Y, and Z.",
)
staypresent.web.markdown(
    "CHANGELOG.md",
    path="/changelog",
    mode="dark",
)

staypresent.run("bot.py")

Best Practices

Keep .md files intended for public serving in a directory that contains only files you're fine exposing — the whole directory becomes reachable, not just the file you called markdown() on.
Use mode="auto" unless you have a specific brand reason to force a theme — it respects the visitor's own preference with zero extra effort.
Set title/description for any page you expect to get linked or shared, so previews render sensibly instead of falling back to a bare filename.

Common Mistakes

Expecting reference-style links ([text][ref]) to work. They don't — only the inline [text](url) form is supported; rewrite reference-style links before serving.
Placing sensitive files in the same directory as a publicly served .md file. They become reachable via the same static-asset mechanism, regardless of whether anything links to them.
Assuming a relative favicon resolves against the current working directory. It resolves relative to file_path's own directory, not the process's cwd.

Conclusion

Turning markdown to html in Python doesn't require pulling in a templating engine or a separate documentation build step. staypresent.web.markdown() renders your existing README.md or CHANGELOG.md into a clean, GitHub-styled page — complete with theming, favicon, and link-preview metadata — using nothing beyond what StayPresent already ships with.

pip install staypresent[prod]

Multiple Bots in One Process with StayPresent

John Wick — Thu, 30 Jul 2026 02:53:01 +0000

How to run multiple python bots in a single process using StayPresent's bot_file list and bots parameter, with independent crash recovery for each.

Running Multiple Bots in One Process with StayPresent

If you're managing a Telegram bot pipeline with several workers, or a Discord bot that runs alongside a separate polling worker, deploying each one as its own hosting service quickly gets expensive and repetitive. StayPresent's multi-bot support lets you run multiple python bots from a single staypresent.run() call, each fully and independently supervised, while sharing one HTTP server and one deployment.

Why Run Multiple Bots Together
The Simple Way: A List of Files
Per-Bot Configuration with bots
How Independent Supervision Works
Shared Failures vs Independent Failures
Log Labels When Filenames Collide
Full Example
Best Practices
Common Mistakes
FAQs
Conclusion

Why Run Multiple Bots Together

A common real-world setup is a Telegram ingestion bot and a separate upload/processing worker that share a queue or database — logically two processes, but deployed together because they belong to the same service. Running each as a separate hosting deployment means twice the port-binding boilerplate, twice the health checks, and twice the deployment overhead for something that's conceptually one unit.

The Simple Way: A List of Files

bot_file accepts either a single string or a list of strings:

import staypresent

staypresent.run(["telegram_bot.py", "discord_bot.py"])

Both scripts launch as independent subprocesses, sharing the same bot_args/env if provided.

Per-Bot Configuration with `bots`

When each bot needs different arguments or environment variables, use bots — a list of dicts, one per bot:

import staypresent

staypresent.run(bots=[
    {"file": "telegram_bot.py", "args": ["--verbose"]},
    {"file": "discord_bot.py", "env": {"SHARD": "0"}},
    {"file": "worker.py"},
])

bots is mutually exclusive with bot_file/bot_args/env — passing both raises TypeError, so there's no ambiguity about which configuration style is active. Each entry requires a "file" key; "args" and "env" are optional per entry.

How Independent Supervision Works

Every bot in the list gets its own restart counter and its own dedicated monitoring thread. A crash in one bot — and any subsequent restart attempts — has zero effect on the others. If your Telegram bot hits an unhandled exception and restarts three times, your Discord bot keeps running the entire time, completely unaffected.

Before anything starts, every bot file listed is validated to exist — a missing file raises FileNotFoundError immediately, before any process launches. And if the very first launch attempt of any bot fails outright (a bad interpreter path, the system running out of file descriptors), StayPresent terminates any bots that already started and raises the failure immediately, so you never end up with orphaned, untracked processes left running in the background.

Shared Failures vs Independent Failures

staypresent.run() waits for every bot to finish — or fail permanently — before returning or exiting the process. If a bot exhausts its max_restarts budget, it's marked permanently failed, but the other bots keep running normally. Only once every bot has finished does StayPresent decide the process's own exit code: non-zero if any bot ended in a permanently-failed state, and specifically the exit code of the lowest-indexed failing bot if more than one failed — deterministic, regardless of which bot's monitor thread happens to finish first.

staypresent.run(
    bots=[
        {"file": "critical_bot.py"},
        {"file": "optional_worker.py"},
    ],
    max_restarts=5,
)

If optional_worker.py permanently fails but critical_bot.py keeps running fine, the whole process only exits (with optional_worker.py's exit code) once critical_bot.py itself eventually finishes too.

Log Labels When Filenames Collide

Bots are tracked by their position in the list, not by filename — two bots can share the exact same filename (shard_a/bot.py and shard_b/bot.py) with no functional conflict. But identical filenames in the logs would make crash/restart messages ambiguous, so StayPresent detects the collision automatically and logs each bot's full file path instead of just the filename in that case:

bot[0] 'shard_a/bot.py' crashed, restarting...
bot[1] 'shard_b/bot.py' crashed, restarting...

Bots with non-colliding filenames still get the shorter, plain filename label.

Full Example

import os
import staypresent

staypresent.web.json({"status": "running", "bots": 3})

staypresent.run(
    bots=[
        {"file": "telegram_bot.py", "args": ["--verbose"]},
        {"file": "discord_bot.py", "env": {"SHARD": "0"}},
        {"file": "queue_worker.py"},
    ],
    port=int(os.getenv("PORT", 8080)),
    max_restarts=5,
    restart_delay=2.0,
)

Best Practices

Use bots (not bot_file + shared env) whenever different processes genuinely need different configuration — it keeps the config next to the file it applies to instead of implicitly shared.
Give each bot its own status endpoint with web.text()/web.json() at a distinct path so you can check any individual bot's state without guessing which one a shared root response refers to.
Keep a "critical" bot and "optional" bots in mind when tuning max_restarts — a bot you can't afford to lose deserves a higher budget than a background helper.

Common Mistakes

Mixing bot_file and bots in the same call. This raises TypeError immediately — pick one style per run() call.
Assuming one bot's crash stops the others. It doesn't — each bot is supervised entirely independently, which is often surprising the first time you see it in the logs.
Forgetting that run() only returns once every bot is done. If one bot runs forever and another exits cleanly, the process is still alive waiting on the first.

FAQs

Can I mix bot_file-style and bot_module-style bots?
Yes, inside bots — set "file" for some entries and "module" for others, freely mixed in the same list.

Does each bot get its own restart budget?
Yes — max_restarts, restart_delay, and restart_reset_after apply per bot, not shared across the whole group.

What if I only need one bot?
bot_file="bot.py" still works exactly as before — multi-bot support doesn't change single-bot usage at all.

Conclusion

Whether you're pairing a Telegram ingestion bot with a processing worker, or running several unrelated scripts side by side, StayPresent lets you run multiple python bots from one deployment, one port, and one run() call — with each bot's crashes, restarts, and logs kept fully independent of the others.

pip install staypresent[prod]

DEV Community: John Wick

Run Python Bots Without Sleep On Railway With StayPresent

Run Python Bots Without Sleep On Railway With StayPresent

Table of Contents

How Railway Detects and Runs Python Apps

The $PORT Requirement

Setting Up StayPresent

Health Checks in Railway's Dashboard

Self-Ping for Inactivity-Sensitive Plans

Crash Recovery

Full Working Example

Best Practices

Common Mistakes

FAQs

Conclusion

StayPresent vs Supervisor vs PM2 for Python Bot Process Management

StayPresent vs Supervisor vs PM2 for Python Bot Process Management

Table of Contents

What Each Tool Is Actually For

Installation and Setup

Configuration Style

Crash Recovery Comparison

The HTTP Port Problem

Logging Comparison

Comparison Table

When Each Tool Is the Right Choice

FAQs

Conclusion

Run Python Bots Without Sleep On Koyeb With StayPresent

Run Python Bots Without Sleep On Koyeb With StayPresent

Table of Contents

Two Ways to Deploy on Koyeb

The Port Binding Requirement

Setting Up StayPresent

Configuring Koyeb's Health Check Path

Self-Ping Considerations

Crash Recovery

Full Working Example (Git-Based)

Full Working Example (Docker-Based)

Best Practices

Common Mistakes

FAQs

Conclusion

StayPresent vs Pulsetic vs Custom Flask Server for Python Bots

StayPresent vs Pulsetic vs Custom Flask Server for Python Bots

Table of Contents

What Pulsetic Actually Is

What Each Approach Solves

Monitoring Depth: Where Pulsetic Pulls Ahead

Crash Recovery: Where Pulsetic Can't Help

Status Pages vs a Bot Status Endpoint

Cost and Free-Tier Limits

Comparison Table

Using Pulsetic and StayPresent Together

FAQs

Conclusion

Security Notes for Serving Static Files with StayPresent

Security Notes for Serving Static Files with StayPresent

Table of Contents

The Directory-Wide Exposure Behavior

Why This Is Intentional

Path Traversal Protection

The One-Time Directory Warning

Markdown-Specific Protections: Escaping

Markdown-Specific Protections: URL Scheme Filtering

What's Rejected vs What's Allowed

Structuring Directories Safely

Full Example

Best Practices

Common Mistakes

FAQs

Conclusion

How StayPresent's Logging Works (Without Breaking Yours)

How StayPresent's Logging Works (Without Breaking Yours)

Table of Contents

The Problem with logging.basicConfig()

StayPresent's Dedicated Logger

What Gets Logged, and at What Level

Adjusting Verbosity

Attaching Your Own Handler

The `$PORT` Requirement

The Problem with `logging.basicConfig()`

`ping()`: The Synchronous Building Block

`cron()`: Scheduling Repeated Pings

Callbacks: `on_success` and `on_failure`

The `CronHandle` Object

Discovering Handles with `active_cron_handles()`

`python file.py` vs `python -m module`

Using `bot_module`

What's Different From `bot_file`