# How to put a Django site online without a server

https://netrun.io/en/blog/sayt-na-django

_October 5, 2026 · 4 min read_

> To put a Django site online, list Django and gunicorn in requirements.txt, add the site address to ALLOWED_HOSTS, move SECRET_KEY into environment variables, and upload the code. Gunicorn should listen on the port from the PORT variable, and styles and images need STATIC_ROOT and the collectstatic command. Netrun detects Python, builds the project and gives you an HTTPS link — no server of your own, no nginx and no manual certificate.

- Django answers with 400 Bad Request when a request comes to an address that is not in ALLOWED_HOSTS.
- SECRET_KEY and the database connection string do not belong in settings.py: Netrun stores them encrypted and passes them to the app as environment variables.
- A published Django site runs on gunicorn, listening on 0.0.0.0 and the port from the PORT environment variable.
- With DEBUG = False Django does not serve static files itself, so you need STATIC_ROOT, collectstatic and something to serve the files, such as the WhiteNoise library.
- On Netrun an SQLite database file belongs in the persistent /data folder, otherwise it disappears on the next publish.

Normally, to show a Django site to the world, you have to rent a server, install Python and a database on it, run gunicorn, set up nginx as a proxy, serve static files separately, get an SSL certificate and remember to renew it. And keep an eye out so the process does not crash overnight. For a portfolio, a pet project or your first real app, that is far too much manual work.

With Netrun the infrastructure stays on us: you upload your project code and answer a couple of questions about secrets, while the platform handles building, running, HTTPS and restarts. It figures out on its own that this is Python and deploys the app. Below we will walk through how to prepare a Django project and put it online in a few minutes.

## 1. List your dependencies

Create a requirements.txt file in the root of your project and list your packages in it, including Django itself and gunicorn — the server that keeps your app running. You do not need to include the venv folder with installed libraries in the archive: Netrun builds the environment from this list on its own.

## 2. Allow the domain in your settings

In settings.py, add ".netrun.io" to ALLOWED_HOSTS so Django accepts requests from your future address. For the very first run you can temporarily set "*", and then narrow it down to your own domain.

## 3. Keep secrets out of your code

Do not leave SECRET_KEY and your database connection string (DATABASE_URL) right in settings.py — read them from environment variables, that is, from values set outside the code. When you set up the project, Netrun asks for these values and injects them as secrets, so they never sit in your code or in the archive.

## 4. Listen on the port from the environment

Do not hardcode the port in your code. Netrun passes the right port through an environment variable (usually PORT), and your gunicorn start command should read it from there. That way your app becomes reachable at the link you get without any manual network setup.

## 5. Do not forget static files

Django serves CSS, scripts and images from the collected static folder. Make sure STATIC_ROOT is set in your settings and that static files are collected with the collectstatic command — then your styles and images will be in place instead of disappearing on the published site.

## 6. Upload the project and get your link

Upload your code as a ZIP archive or import it from a GitHub repository — a private one works too. Answer the questions about secrets, and Netrun builds and publishes the site. Build progress and logs are visible in the dashboard in real time, and the public link opens over HTTPS right away.

Done: your Django site lives on the internet behind a secure link, and you did not have to touch a server, nginx or certificates. If something crashes, Netrun restarts the project on its own. On the Free plan the site sleeps while it is idle and wakes up on the first request — the first response is then a bit slower; for a project that needs to answer without pauses, the paid plan with always-on running is a better fit. [Try Netrun](https://netrun.io/).

Related guides: [a site on Python](https://netrun.io/blog/sayt-na-python-v-internete), [a Flask app](https://netrun.io/blog/flask-prilozhenie).

## Common questions

### Why does Django return 400 Bad Request?

Most likely the site address is missing from ALLOWED_HOSTS. Add the address Netrun gave you, plus your own domain if you connected one. You can set "*" temporarily, but for the long run list the specific addresses.

### Why did the styles disappear on the published site?

With DEBUG = False Django does not serve CSS and images itself. Set STATIC_ROOT, collect the static files with collectstatic and add something to serve them, such as the WhiteNoise library: it serves static files straight from the app, with no separate nginx.

### Where should I keep the SQLite database for Django?

In the persistent /data folder: point DATABASES to a path like /data/db.sqlite3. Everything in /data survives code updates and restarts, while files outside it disappear on the next publish. You can download or upload the database file in the Data tab.

### Can I connect PostgreSQL to Django?

Yes: an external database through a connection string in secrets (the dj-database-url library makes it easy to parse), or your own as a service in docker-compose next to the app. Netrun does not offer a managed database service.

### Should DEBUG be off on the published site?

Yes. With DEBUG = True a visitor who hits an error sees details about your code and settings. It is handy to read DEBUG from an environment variable: on locally, off on the published site.