Port 8000 – HTTP Alternate / Django

TCP

Port 8000 is the most common HTTP development server port. Django (manage.py runserver), Python http.server, and many frameworks default to 8000. Development servers on this port have no TLS, no rate limiting, and often debug mode enabled. Never expose port 8000 development servers to the internet.

Port Number

8000

Protocol

TCP

Service

HTTP Development Server

Range

IANA Registered (1024–49151)

Description

Port 8000 is the de facto standard for local HTTP development servers. Django's runserver, Python's http.server module, PHP's built-in server, and Ruby's WEBrick all default to port 8000 or 8080. These servers are designed for development – single-threaded, no TLS, verbose error pages with stack traces. Exposing a development server on port 8000 to the internet is a critical security mistake. Django's debug mode reveals settings, database queries, and source code in error pages. Production deployments should use Gunicorn/uWSGI behind Nginx on ports 80/443 with TLS.

Security risks

1Django DEBUG=True exposure: when DEBUG is enabled (default in development), unhandled exceptions display full stack traces including source code, local variables, settings.py contents (SECRET_KEY, database passwords), SQL queries, and template paths. A single 404 page exposes the entire URL configuration
2python -m http.server filesystem traversal: Python's built-in HTTP server exposes the entire directory tree it's started in. If run in ~/ or /, all files readable by the user are downloadable – .ssh keys, .env files, .git directories with full history
3Django SECRET_KEY in debug traceback: the SECRET_KEY (used for session signing, CSRF tokens, password reset tokens) appears in settings dump on debug error pages. Attacker with SECRET_KEY can forge sessions and bypass CSRF protection
4No request size limiting: development servers accept arbitrarily large uploads/requests, enabling DoS via memory exhaustion. One malformed 10GB POST kills the single-threaded server
5Single-threaded blocking: Django's runserver processes one request at a time. An attacker holding a connection open (slowloris-style) blocks all other users from accessing the application

Firewall guidance

Never expose port 8000 to any network. Always bind explicitly: manage.py runserver 127.0.0.1:8000 or python -m http.server 8000 --bind 127.0.0.1. For remote access during development, use SSH tunneling: ssh -L 8000:localhost:8000 dev-server. Production Django must use Gunicorn/uWSGI behind Nginx on 443 with DEBUG=False.

Diagnosis commands

Check if Django debug mode is active (returns traceback count > 0 means exposed)

shell

curl -s http://localhost:8000/nonexistent-url-for-debug-test 2>&1 | grep -c 'Traceback\|DEBUG'

Check what process owns port 8000 and its bind address

shell

ss -tlnp sport = :8000

Basic connectivity check

shell

curl -s http://localhost:8000/ -o /dev/null -w '%{http_code}'

Identify the exact process and bind address for port 8000

shell

lsof -i :8000 | grep LISTEN

Usage examples

Port 8000 – HTTP Alternate / Django

shell

python3 -m http.server 8000 --bind 127.0.0.1
django-admin runserver 0.0.0.0:8000
curl http://localhost:8000/

Common services on this port

Django runserverPython http.serverPHP built-in serveruvicorn (dev mode)Hugo (default dev server)MkDocs serve

Related ports

8080

HTTP alternate (similar dev usage)

3000

Node.js dev (similar role)

5000

Flask dev (similar role)

443

HTTPS (production)

History

Port 8000 became the Python web development standard through Django's manage.py runserver (2005) which chose it as a round-number alternative to 80. Python's SimpleHTTPServer (now http.server) also defaults to 8000. The convention spread to other frameworks: Hugo (2013), MkDocs (2014), and many API frameworks. Port 8000 is now synonymous with 'development HTTP server' in the Python ecosystem.

FAQ

How do I run Django safely in production?

Never use runserver in production. Stack: Gunicorn (--bind 127.0.0.1:8000 --workers 4) or uWSGI behind Nginx (443 with TLS). Set DEBUG=False, configure ALLOWED_HOSTS, use a proper SECRET_KEY (not the one in git), enable SecurityMiddleware (HSTS, X-Frame-Options), and serve static files via Nginx/CDN (not Django). Use django-admin check --deploy to audit settings.

Is 'python -m http.server' safe for sharing files locally?

Only on trusted networks and only from a dedicated directory (never ~/). It serves ALL files in the directory tree including hidden files (.env, .git). It has no authentication, no TLS, and logs all requests to stdout. For sharing files: use a dedicated tool like transfer.sh or a temporary presigned S3 URL instead.