Django auto-detection
The platform finds django in requirements.txt and builds the project itself - no Dockerfile, no manual wsgi setup.
Your Django project is ready, but you don't want to deal with servers, wsgi and nginx? Connect the repo - Dada Cloud detects django in requirements.txt, builds the project and runs it. PostgreSQL is created next to it, an HTTPS domain is issued right away. Free tier, servers in Russia.
The platform finds django in requirements.txt and builds the project itself - no Dockerfile, no manual wsgi setup.
A managed database is created next door, DATABASE_URL appears in the environment - point settings.py at it.
The project gets a name.dada-tuda.ru address with a certificate. Remember to add it to ALLOWED_HOSTS.
The app must listen on 0.0.0.0 and the PORT env variable, defaulting to 8000.
The process restarts automatically after a failure.
Your first project can run for free, no card required.
Six steps from a repo to a working address - database, static files and migrations included.
requirements.txt must list django - that is what the platform reads to recognise the project and pick port 8000. Add gunicorn there too, plus dj-database-url and whitenoise if you use them.
Name the app and connect a GitHub repo - or upload a zip if you don't use git. Every push builds a new version.
The managed database is one click away and DATABASE_URL lands in the environment. Read it in settings.py, for example with dj-database-url.
SECRET_KEY, DEBUG=False and your host list are set in the console. Add the issued address to ALLOWED_HOSTS or Django answers with a 400.
A start command like manage.py migrate --noinput && manage.py collectstatic --noinput && gunicorn project.wsgi --bind 0.0.0.0:$PORT covers all three at once. The platform runs it verbatim.
In a minute or two the project is live at name.dada-tuda.ru over HTTPS. A custom domain takes a couple of minutes, the certificate is automatic.
Real platform tiers, and an honest comparison with renting your own VPS.
| Tier | Price | What you get |
|---|---|---|
| Free | 0 ₽/mo | One project with a database and a domain, no card required. The limit is resources, not a trial clock. |
| Startup | 990 ₽/mo | 5 apps, 2 databases, 7-day backups - a site with real users plus a Celery worker. |
| Business | 2,900 ₽/mo | 20 apps, 10 databases, 30-day backups, priority support. |
| Your own VPS | comparable on hardware | A VPS is cheaper per unit of hardware. But gunicorn under systemd, nginx, certificates, database backups and restarts after a crash cost your time. |
Three places a Django deploy usually trips.
Django answers 400 for any host missing from ALLOWED_HOSTS. Add both the issued name.dada-tuda.ru address and your custom domain if you attach one.
A MEDIA_ROOT on the local disk is wiped on every build. Keep user uploads in object storage and put only collected static on the app disk.
The platform never guesses when to touch your schema. Put manage.py migrate in the start command so every deploy brings the database up to date.
On Dada Cloud: connect the repo, the platform detects Django, builds and runs the project. No server, wsgi or nginx to configure.
Create a managed PostgreSQL next to the project - the platform injects DATABASE_URL into the environment; read it in settings.py (for example with dj-database-url).
Add the issued domain to ALLOWED_HOSTS and run the app on 0.0.0.0 with the PORT env variable (default 8000).
The way you always do - manage.py migrate on start or manually. The platform does not interfere with your start command.
Yes - the first project with PostgreSQL and a domain runs on the free tier, no card required.
Run manage.py collectstatic --noinput at build or start time and serve the result with WhiteNoise - one dependency and one line in MIDDLEWARE. User media belongs in object storage: the local disk is wiped on every build.
Yes, for a production run: add gunicorn to requirements.txt and start with gunicorn project.wsgi --bind 0.0.0.0:$PORT. runserver is a development tool and will not hold up under traffic.
In the app's environment variables, set in the console and injected at start. Read them with os.environ in settings.py so secrets never enter the repo.
Run the Celery worker as a separate app in background-worker mode - no public domain is issued for it. The web app and the worker live in one project and share the same database.
Create an account and deploy your first app. The Free plan costs $0.