Introduction

The Django development server is local by default. To reach it from outside your machine, you need two things: Django must listen on a non-loopback address, and traffic from the outside world must have a path to your machine. The safest short-term approach is usually a tunnel such as ngrok or Cloudflare Tunnel, not direct exposure of the dev server to the public internet.

Make Django Listen on the Network

By default, runserver often binds to 127.0.0.1, which means only the local machine can connect. Bind it to 0.0.0.0 so other machines can reach it.

python manage.py runserver 0.0.0.0:8000

You also need to allow the hostnames or IPs Django will accept.

1ALLOWED_HOSTS = [
2    "localhost",
3    "127.0.0.1",
4    "my-public-host.example.com",
5    "203.0.113.25",
6]

If ALLOWED_HOSTS is wrong, Django may reject the request even if networking is correct.

Local Network Versus Public Internet

If you only need access from another device on the same Wi-Fi network, you often do not need internet exposure at all. Start Django on 0.0.0.0, find your machine's LAN IP, and open:

http://192.168.1.20:8000

That is much safer than opening router ports or publishing the app publicly.

Tunneling Is Usually the Best External Option

A tunneling service creates a public URL that forwards traffic to your local port.

With ngrok:

python manage.py runserver 0.0.0.0:8000
ngrok http 8000

ngrok gives you a public HTTPS URL that forwards to your local Django server.

This approach avoids router configuration and usually works even behind NAT or restrictive home networks.

Direct Port Forwarding

If you want true public access without a tunnel, configure your router to forward an external port to your machine's internal IP and Django port.

The rough flow is:

1. give your development machine a stable LAN IP
2. run Django on 0.0.0.0:8000
3. forward router port 8000 to that machine
4. allow the traffic in the host firewall
5. access the app through your public IP or DNS name

This works, but it is the riskiest option because the Django development server is not a hardened public web server.

Important Security Warning

Django's built-in development server is not intended for production exposure. It is convenient for debugging, not for internet-facing deployment.

If you expose it publicly, at minimum:

• keep DEBUG = False unless you fully trust the audience
• use strong random secrets
• avoid testing with real credentials or production data
• prefer temporary tunnels over permanent router exposure

If the app needs ongoing public access, deploy it behind a real web server such as Nginx with Gunicorn, or use a managed platform.

Firewall and OS Checks

Even after binding Django correctly, the OS firewall can block inbound traffic.

On the server machine, confirm the port is listening:

python manage.py runserver 0.0.0.0:8000

Then test from another machine. If it still fails, check host firewall rules and router settings.

HTTPS and Public URLs

Tunnels are convenient partly because they give you HTTPS automatically. That matters for webhooks, OAuth callbacks, and browser features that require secure origins.

If you expose the server through plain port forwarding, you usually have only HTTP unless you build a full reverse-proxy setup with certificates.

A Practical Recommendation

For demos, webhook testing, or temporary outside access:

• run Django on 0.0.0.0
• set ALLOWED_HOSTS correctly
• use a tunnel

For a real shared environment, deploy the app properly instead of publishing the dev server.

Common Pitfalls

A common mistake is running python manage.py runserver without 0.0.0.0, which keeps the server bound to localhost only.

Another mistake is forgetting ALLOWED_HOSTS, which causes Django to reject otherwise valid requests.

Developers also often confuse LAN access with public internet access. Reaching the app from another phone on the same Wi-Fi is much easier than exposing it globally.

Summary

• Bind Django to 0.0.0.0 instead of localhost.
• Set ALLOWED_HOSTS for the hostnames or IPs that will reach the app.
• Use a tunneling service for short-term public access whenever possible.
• Port forwarding works, but it exposes the development server directly and is riskier.
• For ongoing public use, deploy Django behind a real production server stack.