Python Deploy
Vinza Store Python Deploy
Python Deploy
Premium Runtime
pythondjangoflaskfastapiwsgiasgi
Get this app
Free with Starter, Profesional & Enterprise · See plans
$29.00
One-time — permanent license, 1 server.
Rp 435.000 charged
$2.99/mo
Cancel anytime.
Rp 45.000/mo charged

Deploys Django, Flask and FastAPI applications as per-domain systemd services and manages the Python interpreters available on the server. A deploy writes a systemd unit that runs gunicorn (WSGI), a uvicorn worker (ASGI/FastAPI) or daphne (Django Channels) from the app's virtualenv as a chosen Linux user, picks a free port if none is given, and configures the reverse proxy in front of it — nginx, Apache2 or OpenLiteSpeed. The unit can be previewed before it is written, and the WSGI/ASGI module can be auto-detected from the project directory.

Virtualenv handling is part of the plugin: it reports venv status, creates one, installs packages or applies a requirements.txt, and lists what is installed. A bootstrap action creates the venv and a minimal project skeleton for the chosen framework in one step, patching Django's ALLOWED_HOSTS with the site's hostnames, which is what the website create form uses. The interpreter manager works like the PHP-FPM version picker: it lists installed Python versions, installs additional ones via install_version.sh, removes them (the system default is protected), and each app records the version its venv was built from.

Deployed apps can be started, stopped, restarted and reloaded, and their journal logs read from the panel. Web rules per site cover static and media aliases and a directory-indexing toggle, written into the web server config. A website_deleting hook stops and removes an app's unit before its website is torn down, and because actions carry the domain, the action API resolves that site's node and runs the venv build there instead of on the panel.

Deploy and everything that mutates are admin-only; tenants may only list available Python versions. Uninstalling the plugin deliberately leaves deployed services running — removing the tooling should not take a live site offline, so apps must be removed individually first.

Min Panel Version
1.0.0
Platform
Ubuntu 20.04+ / 22.04+ / 24.04+
License
Paid license required
Hooks
website_deleting
Permissions
websites.manage
VinzaPanel handles installation automatically via the Vinza Store. Make sure the panel agent has internet access to download dependencies.
1.0.17 — New icon in the shared flat style. 1.0.16 — Limits tab: an admin sets memory caps (MemoryHigh / MemoryMax) and a CPU quota for the app and for its background worker, and Gunicorn's --max-requests (+ jitter), --threads (gthread workers) and --preload; the website owner sees them read-only. A newly deployed app recycles its workers after 1000 requests (jitter 100); apps already running keep their unit until an admin saves limits. A drop-in (…service.d/*.conf) that overrides ExecStart or the memory settings is shown as a warning on the Limits tab and in Edit deployment. 1.0.15 — Confirmation prompts use the panel's own dialog (with a title and a clear action button) instead of the browser's confirm() box. 1.0.14 — An app deployed in a folder below the site root (e.g. <site>/webapp) is managed from that folder: its virtualenv, packages and module are found there, and "Save & re-deploy" is no longer disabled with "Set up the virtualenv first" while the app runs. 1.0.13 — Security: app and worker logs in ~/logs are opened by the app itself (as the account), not by systemd as root; log files are prepared only inside the real log folder and read as the account, so a symlink in the home cannot point root at another file. Existing worker units are converted on update. 1.0.12 — Deploys restart the app's background workers marked “Restart after a deploy” in Supervisor (supervisor 1.0.6+) once the deploy succeeds. 1.0.11 — Requests send the panel’s own CSRF token: the cookie was matched by a pattern that also took any cookie whose name ends in “csrftoken” (another app on the same host), and the request was refused with 403. 1.0.10 — Environment variables: a per-app editor (Configuration → Environment) saved to an owner-only env file the service loads with EnvironmentFile=; names are validated, values are hidden after saving and the app can be restarted on save. Deploy from Git (new Git tab): link a repository + branch (private repositories use the site account's deploy key, shared with Git Manager); "Deploy now" fetches the branch, resets the app folder to it, creates the venv when missing, installs requirements.txt and runs your post-deploy commands (migrate, collectstatic, …), then restarts the app — every step runs as the site's account, with its output in a deploy log. Push to deploy: a per-app webhook URL and HMAC secret for GitHub, GitLab or Bitbucket; unsigned requests and pushes to other branches are ignored. Releases: the last deploys are listed and the last 5 successful ones can be rolled back to; rollback checks the commit out again and reinstalls (migrations are not reversed). Background worker: a Celery/RQ command run as its own service next to the app (Configuration → Worker), with start/stop/restart/logs, restarted on every Git deploy. 1.0.9 — Security: the requirements.txt, starter files and Django settings the plugin writes into a site are now confined to the site owner's home. A symlink planted in the site folder could make them land on a system file, owned by the site account. 1.0.8 — Deploying makes sure the site account can write its app logs in ~/logs (an ACL, adding the acl package where a node lacks it) — on such a node the service failed with "isn't writable". 1.0.7 — A Python without its venv package (python<ver>-venv) is recognised as such: the version list flags it and installing that version adds the package, instead of reporting "already installed" while every virtualenv failed on ensurepip. 1.0.6 — Website owners can deploy their own Python sites: the Deploy card shows on the Advanced tab of a Python site for its owner (scoped to that site, within the versions and packages the admin allows). The runtime manager in the sidebar stays admin-only. 1.0.5 — The deploy form now fills in the module for Flask (app:app) and FastAPI (main:app) apps, including the skeletons this plugin creates, and finds Django's wsgi/asgi modules on tenant sites (detection now reads the folder through the agent; the panel cannot read a tenant's home). "Reload" no longer kills a Daphne app: only Gunicorn reloads in place, everything else is restarted. 1.0.4 — Deployed apps get an "Edit settings" action that opens the deploy form prefilled with the settings the app is running with (server, module, workers, port, virtualenv); app path, user and service name are shown read-only. Re-deploying with port 0 now keeps the app's current port instead of moving it to a new one; tick "Pick a new free port instead" to get a new one.

Use VinzaPanel's REST API to download and install this app programmatically.

Download app files
HTTP
POST /plugins/api/download/python-deploy/
Content-Type: application/json

{
  "panel_version": "1.0.0"
}
Example response
JSON
{
  "success": true,
  "plugin_id": "python-deploy",
  "version": "1.0.17",
  "download_url": "..."
}