Skip to main content
Servbase currently supports Python application deployment for:
  • Flask
  • Django
  • FastAPI

​
Global requirements

Your effective deployment root must contain:
  • requirements.txt
Servbase creates a virtual environment and installs dependencies from that file.

​
Flask and FastAPI

For Flask and FastAPI, provide one of these modules in the deployment root:
  • app.py
  • main.py
Expose the application object as app. Examples:

​
Django

For Django:
  • manage.py must exist in the deployment root
  • a valid wsgi.py must be discoverable
  • if multiple WSGI modules exist, the deployment may require disambiguation
During deploy, Servbase runs:
These Django-only steps apply when the deployment resolves to Django.

​
Root folder behavior

Servbase can auto-flatten a source package when the archive contains a single top-level folder. Detection becomes less reliable when framework files are nested deeper than the effective deploy root.

​
Runtime actions

Python apps support:
  • deploy
  • rebuild
  • restart
Restart requires a healthy latest deployment.

​
Gunicorn behavior

For Flask and Django apps that run with Gunicorn, Servbase supports customer-facing settings for:
  • worker count
  • optional worker class
Current worker caps by performance tier: Supported worker-class input is validated server-side. Common valid values include:
  • sync
  • gevent
  • gthread
  • eventlet
  • tornado
or a valid dotted Python path.
Gunicorn worker-class settings apply only to supported Python frameworks that actually run under Gunicorn. FastAPI is not documented as a Gunicorn-managed path in the current customer flow.

​
Rebuild source behavior

If the Python app is not connected to GitHub, rebuild normally uses the current workspace contents. If the Python app is connected to GitHub, rebuild can be run from either:
  • GitHub — re-clone and rebuild from the repository source
  • Workspace — rebuild using the files currently present in the Servbase workspace