How to keep a Python script running 24/7

First: what kind of "always running" do you need?

Two common shapes, because they're hosted slightly differently:

• A long-running loop. Your script starts once and stays alive — a while True that polls an API, a queue consumer, a bot that listens for events. It needs a place that runs the process continuously and restarts it if it dies.
• A job on a schedule. Your script runs for a minute every hour (or every day) and then exits. The simplest robust way to host this is to also make it a long-running process — a tiny loop that sleeps until the next run, or the schedule library — so there's one always-on thing instead of a cron you have to wire up.

Either way the requirement is the same: somewhere that keeps a process alive 24/7, restarts it on crash, and doesn't charge you for a whole server to do it.

Why "just leave it on your machine" breaks

A laptop sleeps, reboots, loses Wi-Fi, and gets closed. A free-tier host usually sleeps idle apps or caps your hours, which is exactly the wrong behaviour for something that's meant to run continuously. For anything you actually depend on, you want a host whose entire job is to keep the process up.

Run it in four steps

1. Put your script in a container

It's a short Dockerfile: start from a Python base image, install your dependencies from requirements.txt, and run your script. Roughly:

• FROM python:3.12-slim
• COPY requirements.txt . && RUN pip install -r requirements.txt
• COPY . .
• CMD ["python", "-u", "main.py"]

The -u matters: it makes Python flush output immediately so your logs actually show up. If you don't already build an image, the quickstart walks through it.

2. Keep secrets out of the code

API keys, tokens, and passwords go in environment variables, not in the script. Read them with os.environ and set them when you create the session — never bake them into the image or commit them to git.

3. Deploy it

Point Sinkron at your image and give it a small CPU/RAM footprint — a polling script needs very little. For a background script with no web server, a single runner is right; you don't need a public port unless your script also serves HTTP.

4. It stays up — you pay only while it runs

Sinkron keeps the process alive with automatic restarts if it crashes, and bills by the second. If your balance runs low we email you first; if it hits zero the script stops, so you're never billed past your deposit. Stop it yourself any time and the cost drops to zero.

Write it so it survives a restart

• Assume it can be restarted at any moment. Don't hold important state only in memory; if a run matters, write it somewhere external (a database or object storage) so a restart picks up where it left off.
• Handle errors inside the loop. Wrap the risky part in try/except so one bad API response doesn't kill the whole process — though if it does crash, it'll be restarted for you.
• Don't write to local disk for anything you need to keep. The container filesystem is disposable.

What it costs

A small Python script's footprint is tiny, so it runs for pennies an hour, and you only pay while it's actually running. It's free to sign up and look around. Because you're billed for runtime by the second instead of a flat monthly box, an always-on script usually comes out cheaper than the standard $5 VPS that charges around the clock. See how pricing works or the comparison with a $5 VPS.

When a plain VPS is the better call

Honestly, reach for a VPS instead if your script needs persistent local disk you won't move to external storage, full OS-level control, or it's a heavy, always-busy job rather than a light loop. For the lightweight common case — a small script you just want running reliably and cheaply — this is the lower-effort path. If your script is actually a bot, see the Discord and Telegram guides, or the general small-app guide.