Django Hosting
Django hosting, properly configured
Point us at your WSGI module and we handle the virtualenv, gunicorn, static files and HTTPS — so you can get back to building.
Deployment is the least interesting part of Django
The Django docs are excellent right up until "deploying", at which point you are reading about gunicorn workers, static file collection and reverse proxies instead of writing views.
We take the standard Django deployment and make it a form. Give us the app root and the WSGI path, and you get a supervised gunicorn process behind nginx with a free certificate on your own domain.
Django Hosting
What you get
WSGI-aware
Give us myproject.wsgi and we wire up gunicorn correctly the first time.
Requirements installed
Your requirements.txt is installed into a clean virtualenv on every deploy.
PostgreSQL ready
The database Django users actually want, alongside MySQL if you prefer.
Managed process
gunicorn runs under systemd, restarted on crash and after reboots.
HTTPS included
Free Let's Encrypt certificates that renew themselves.
Terminal access
Run migrations and management commands from the browser terminal.
How it works
- 1Upload or clone your project into your account.
- 2Create an app: runtime Django, app root, WSGI path.
- 3Run migrations and collectstatic from the terminal.
- 4Attach your domain and issue SSL.
Where it runs
On our own hardware, inside Nepal
Not a reseller account on someone else's platform. Your Django workload runs on machines we own and operate in Kathmandu — which is why the round trip below is what it is.
- NVMe storage on every plan
- Isolated account per customer, at the OS level
- Nightly backups you can restore yourself
Typical round-trip a visitor inside Nepal sees, by server location. Your results will vary by network and route.
Give the WSGI module path, not a file path
The app entry field wants the dotted module path to your WSGI module — myproject.wsgi — not a filename. We append the :application part ourselves.
# Entry point to enter in the panel: myproject.wsgi
DEBUG = False
ALLOWED_HOSTS = ["yourdomain.com", "www.yourdomain.com"]
# collectstatic writes here; nginx serves it directly, which is
# faster than routing static files through Django.
STATIC_ROOT = BASE_DIR / "staticfiles"
STATIC_URL = "/static/"While you are there
After the first deploy, open the browser Terminal and run migrate and collectstatic. Leaving DEBUG on, or omitting your domain from ALLOWED_HOSTS, is the most common reason a fresh Django deploy returns a 400.
If a deploy still will not come up, the panel reads the service log and explains the cause in plain language — you do not have to interpret systemd output yourself.
Under the hood
- Runtime
- Python 3 with per-app virtualenv
- Server
- gunicorn behind nginx
- Database
- PostgreSQL or MySQL
- Static files
- Served directly by nginx after collectstatic
- Management
- Browser terminal for migrate, createsuperuser and friends
Plans
Plans are being updated — see all hosting.
Common questions
How do I run migrations?+
Open the Terminal in the panel, activate your virtualenv and run python manage.py migrate — exactly as you would locally.
Where do static files go?+
Run collectstatic into a folder under your web root; nginx serves them directly, which is faster than serving them through Django.
Is DEBUG off?+
That is your settings file, and it should be. Set DEBUG=False and configure ALLOWED_HOSTS for your domain before going live.
Ready when you are
Set up in minutes, with support from people in your timezone.