24/7 bot hosting without idle sleep
JustRunMy.App containers run without an idle sleep policy and include automatic container restarts, logs, and a web shell. Always-on describes the process model; it does not guarantee uninterrupted service or fix bugs, token failures, or network errors inside your bot.
A good fit for: Bots with persistent connections, long-polling workers, notification relays, and applications that must listen between requests.
Why idle sleep matters for a bot
A website can often wait for the next incoming request. A bot may need to maintain a connection, poll for updates, or send a scheduled notification when no user is visiting a page. A hosting service that suspends an idle process can interrupt those jobs.
An always-on container keeps your worker eligible to run without a traffic-based wake-up step. You do not need artificial web requests to defeat an idle timer on JustRunMy.App. Keep the application configured correctly and provision enough resources for its workload.
Build recovery into the application
Automatic container restart addresses a process that exits. It does not recover unsaved state or prove the bot is still processing messages. Make external requests time out, retry temporary errors with a delay, and save task progress before a restart can erase it.
Store reminders and job status on persistent storage or in your database. Make handlers safe to retry where possible so that a recovered job does not send the same notification twice. Test a restart while a task is pending to see what your application actually recovers.
Check useful behavior, not just a running process
Use logs to confirm successful connections and completed work. For an HTTP bot, a health endpoint can show whether dependencies are reachable. For a background worker, record recent successful jobs or messages and use monitoring appropriate to that signal.
Review disk growth and the account resource limits on the pricing page. Rotate files and remove temporary downloads. A process with exhausted storage or memory can stop being useful even if no idle policy applies.
Deployment checklist
Choose the worker entry point
Run the command that connects to the chat platform or consumes jobs and stays active between events.
Deploy and allocate resources
Use Zip, Git, or Docker and select CPU, RAM, and disk based on a realistic workload.
Make state recoverable
Configure persistent files or a database, timeouts, retry delays, and a way to recognize completed tasks.
Test failure recovery
Restart the bot, verify reconnection and pending work, and inspect logs after the next real message.
Example resource allocations
Monthly USD rates: $1.90 per vCPU, $1.95 per GB RAM, and $0.25 per GB disk. All allocated resources are billed per minute across applications, including idle allocations.
Budget for the entire time resources remain allocated. A bot waiting for an event still needs memory and its running environment; quiet periods do not remove allocation charges.
| Example | vCPU | RAM (GB) | Disk | Monthly estimate |
|---|---|---|---|---|
| Minimal allocation example | 0.15 | 0.15 | 0 GB | $0.58 |
| Lightweight worker example | 0.25 | 0.25 | 0.3 GB | $1.04 |
| More memory for dependencies | 0.25 | 0.5 | 1 GB | $1.70 |
| Larger worker example | 0.5 | 1 | 1 GB | $3.15 |