Creating a Python Virtual Environment (venv) on Hosting: Setup, Activation and cron

Every Python project, whether a website, a Telegram bot or a daily report script, depends on external libraries. Locally you just run pip install, but on hosting you cannot install packages system-wide, and you should not need to. A virtual environment solves this by creating a separate Python and library set inside your project folder.

Why a virtual environment

A server may have one shared Python managed by the administrator. If every project installed packages there, an upgrade for one project could easily break another. A venv gives each project its own isolated box with its own pip and library versions, and creating one needs no admin rights. Take a bakery in Namangan whose owner wants a short Telegram report on yesterday's orders every morning. The developer wrote a small script using requests and openpyxl; it runs on hosting via cron, with its libraries in a venv inside the project.

Creating and activating the venv

Connect over SSH, go to the project folder and create the environment. If several Python versions exist, choose explicitly, because a venv stays on the version that created it.

cd ~/report
python3 --version
python3 -m venv venv
source venv/bin/activate
python -m pip install --upgrade pip

Once active, the prompt shows (venv) and which python should point to venv/bin/python in your project. Leave it with deactivate. On Windows, activation is venv\Scripts\activate.

Managing libraries with requirements.txt

# on your computer
pip freeze > requirements.txt

# on the server, inside the active venv
pip install --no-cache-dir -r requirements.txt

pip freeze pins exact versions, so the server gets the same set as your machine. --no-cache-dir avoids filling your disk quota with the pip cache; if a cache already built up, pip cache purge clears it.

A venv cannot be copied from another computer

Uploading a locally created venv folder over FTP is a common mistake. A venv contains absolute paths to the Python that created it, and some libraries include binaries compiled for that operating system; a Windows venv even has a different folder layout. Upload only the code and requirements.txt, build the venv on the server, and add venv/ to .gitignore.

Using the venv in cron without activation

cron does not run source venv/bin/activate, and it does not need to: calling the venv's Python by its full path is enough. For the bakery report at 7:30 every day:

30 7 * * * /home/login/report/venv/bin/python /home/login/report/daily.py >> /home/login/report/daily.log 2>&1

The venv's interpreter already knows where its packages live, so no PATH tricks or wrapper scripts are required, and the same approach works for systemd units and shell scripts. Paths are examples; find your home directory with echo $HOME. The server's time zone may differ from Uzbekistan time, so adjust the hour if needed. The redirect at the end sends errors to a log file. On shared hosting you add this line in the ISPmanager scheduler section.

Common errors

On some Debian and Ubuntu systems, creating a venv fails with ensurepip is not available, meaning the venv module is packaged separately. On your own VPS install it with sudo apt install python3-venv; on shared hosting ask support. After a Python upgrade an old venv may break; delete it, recreate it and reinstall from requirements.txt. Python support, SSH access and available versions depend on your plan, so check them in the sayt.uz cabinet or with support. Scheduled scripts can run fine on shared hosting, but a bot that must run around the clock belongs on a VPS.