Python script hosting: a script that keeps running after you close the laptop
A script that polls an API, watches a feed, posts a summary or works through a queue does not need a server of its own. Point us at the repository, deploy, and it runs in its own sandbox around the clock with its output in a live console.
What the repository needs
- requirements.txt with what the script imports. An empty one is fine for a script that only uses the standard library.
- An entry file named main.py or bot.py, or any filename with a start command such as
python worker.pyon the app's page. - Keys and tokens read from the environment with
os.environ, not from a file in the repository.
Python 3 is picked from the repository, the requirements install into a virtual environment we keep between deploys, and the script starts.
A script that stays, and a script that ends
The runtime expects a process that keeps running, and starts it again when it exits. For a script that is supposed to run forever, that is the behaviour you want. For a script that does one thing and returns, it means it runs again immediately, which is rarely what anybody meant.
So make the schedule explicit. Either keep the process alive with a loop and a sleep, or with APScheduler, and do the work on your own interval; or leave the script as it is and run it with the panel's scheduled commands, which call a command inside the app on a schedule. The cron job page compares the two.
Output, files and data
Anything the script prints goes to the live console, and Python output is unbuffered in this runtime, so a plain print() shows up as it happens with no flushing of your own. Files written under /data are still there after a redeploy, which is where a SQLite database, a CSV or a checkpoint belongs. Everything outside /data is rebuilt from the repository on every deploy.
What 256 MB actually holds
A script that calls APIs and writes rows runs in a few tens of megabytes. pandas and numpy are heavier and a dataframe of any size is heavier still: that is the workload that wants 1 GB at $2 a month, with up to 3 GB more at $1 a gigabyte. The usage chart on the app's page shows the last 24 hours of memory and CPU, and the crash doctor names a memory kill for what it is instead of leaving you an exit code.
Frequently asked questions
Can I run a script that finishes and exits?
You can, but it will be started again, because the runtime keeps apps running. Either loop inside the script or use the panel's scheduled commands to run it on an interval.
Which Python version runs?
Python 3, picked from the repository. Pin what you need in the usual way and the install follows it.
How do I see what the script is doing?
The live console on the app's page shows the install, the start and everything the script prints, and the deploy history keeps the output of earlier runs.
Does a free app sleep?
The process does not. Only a web address sleeps on the free plan, when nobody has opened it for a while, and a worker or a script has no address to sleep. A free app is asked every few days whether it is still in use, and one click in that mail keeps it running. Paid apps are never asked.
Is there a traffic limit?
A free app may move 1 GB a day, counted in and out together, and the Plan and usage tab shows where the day stands. Past the limit the app stops and starts are blocked for 24 hours. Paid apps have no traffic limit.
Where do files and databases live?
Files written under /data survive redeploys; everything else is rebuilt from the repository. Every paid app includes a one-click MySQL database; PostgreSQL, MongoDB and Redis are managed databases on the same private network, never on the public internet.