Deploy Django on Vultr

Problem statement

Vultr offers inexpensive cloud compute instances in many regions, which makes it a good home for a Django app that needs a predictable monthly cost and full control. But a fresh instance is just Ubuntu with a root login: you must secure it, install the stack, connect a database, add HTTPS, and plan backups yourself. This guide walks through a production-ready single-server setup on Vultr and points out the Vultr-specific pieces: plan choice, the Vultr Firewall, private networking, snapshots, and managed databases.

1. Create a Cloud Compute instance with Ubuntu 24.04 LTS, at least 2 GB RAM, in the region nearest your users, with your SSH key.
2. Attach a Vultr Firewall Group allowing 22 (your IP), 80, and 443.
3. Create a deploy user, disable root and password SSH login, enable ufw and unattended upgrades.
4. Install PostgreSQL (or use Vultr Managed Databases), Python venv, Gunicorn under systemd, and Nginx.
5. Point DNS at the instance IP and run Certbot.
6. Enable automatic backups and take a snapshot before risky changes.

Step-by-step solution

1. Create the instance

In the Vultr console choose Cloud Compute, the Regular or High Performance type, Ubuntu 24.04 LTS, and a plan with at least 2 GB RAM for Django plus PostgreSQL on one machine (1 GB works for small sites with swap). Add your SSH public key, enable IPv6 if you will configure it, and turn on Auto Backups at creation time.

2. Lock down the network

Create a Firewall Group under Network → Firewall with inbound rules:

• TCP 22 from your IP address only.
• TCP 80 and 443 from anywhere (IPv4 and IPv6).

Link it to the instance. The Vultr Firewall filters traffic before it reaches the server; keep ufw on the instance as a second layer.

3. Secure the server

ssh root@<ip>
adduser --disabled-password deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

In /etc/ssh/sshd_config set PermitRootLogin no and PasswordAuthentication no, then systemctl reload ssh. Enable the host firewall and updates:

ufw allow OpenSSH && ufw allow 'Nginx Full' && ufw enable
apt update && apt install -y unattended-upgrades && dpkg-reconfigure -plow unattended-upgrades

4. Install the stack

sudo apt install -y python3-venv python3-dev build-essential libpq-dev postgresql nginx
sudo -u postgres psql -c "CREATE ROLE myapp LOGIN PASSWORD 'change-me';" -c "CREATE DATABASE myapp OWNER myapp;"
sudo mkdir -p /srv/app && sudo chown deploy:deploy /srv/app

As deploy, clone the code, create a virtualenv, install requirements, write /etc/myapp/env with DJANGO_SETTINGS_MODULE, SECRET_KEY, DATABASE_URL, and ALLOWED_HOSTS, then run migrate and collectstatic. Configure Gunicorn as a systemd service on a Unix socket and Nginx as the reverse proxy, exactly as in Deploy Django With Gunicorn and Nginx on Ubuntu.

For larger apps, Vultr Managed Databases for PostgreSQL take backups, upgrades, and failover off your hands. Attach the instance and database to the same VPC and connect over the private address, with sslmode=require.

5. DNS and HTTPS

Create an A record (and AAAA if IPv6 is configured) pointing at the instance, either at your registrar or in Vultr DNS. Then:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Add SECURE_PROXY_SSL_HEADER and the secure cookie settings in Django.

6. Backups and snapshots

Vultr Auto Backups capture the whole disk on a schedule, and snapshots are manual images you can restore or use to create new instances. They are not a substitute for database backups: take regular pg_dump backups and copy them to Vultr Object Storage or another provider, because a disk image taken mid-write may not restore a consistent database.

Verification check: curl -I https://example.com returns 200 over HTTP/2, python manage.py check --deploy is clean, systemctl status gunicorn nginx postgresql shows all active, and a test restore of last night's pg_dump into a scratch database succeeds.

Explanation

Vultr instances are standard KVM virtual machines, so the Django stack is the same as on any Ubuntu VPS. What Vultr adds is infrastructure around the machine: a network firewall that drops unwanted traffic before it reaches the instance, private VPC networking for connecting app servers to databases without crossing the internet, disk-level backups and snapshots, and managed databases. Using those pieces deliberately gives a small team a production setup with a clear upgrade path from one instance to several.

Edge cases / notes

• Bandwidth. Plans include a monthly transfer allowance; serve large media from object storage or a CDN to stay within it.
• Outbound email. Some providers restrict SMTP ports on new accounts; use an email API provider (SES, Postmark) over HTTPS.
• Resizing. You can upgrade a plan in place; downgrading disk size is not possible, so start modestly.
• Bare metal plans exist for heavy workloads but take longer to provision and lack snapshots.

Next steps

• Follow the detailed stack setup in Deploy Django With Gunicorn and Nginx on Ubuntu.
• Harden the instance with the Django Server Hardening Checklist.

FAQ

What Vultr plan do I need for Django?

A 2 GB Cloud Compute instance runs a small Django app with PostgreSQL. Larger apps move the database to a managed service.

Is the Vultr Firewall enough?

Use it plus ufw on the instance. Two layers protect you if one is misconfigured.

Are Vultr snapshots a database backup?

No. Use pg_dump or managed database backups for consistent data recovery.

Should I use Vultr Managed Databases?

For production apps where you do not want to run PostgreSQL upgrades, backups, and failover yourself, yes.