Standalone, Docker & Cloud Deployments

While Hurricane provides first-class, premier integration for Kubernetes clusters, it is fundamentally a Django-Native Application Server.

You do not need Kubernetes to take advantage of Hurricane's Rust-powered performance, built-in edge security shields, native static asset streaming, and health probe endpoints. Hurricane runs seamlessly on single-container Docker setups, cloud PaaS platforms, and traditional virtual machines.

1. Docker Compose (Zero-Nginx Single Service)

In standard Django setups, developers often spin up multiple containers: Django, Gunicorn, and an Nginx reverse proxy just to serve static files.

With Hurricane's native static file streaming and built-in rate limiting, you do not need an Nginx container:

version: "3.9"

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: secretpassword
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5

  web:
    build: .
    command: >
      python manage.py serve
      --port=8000
      --static
      --media
      --check-migrations-apply
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://postgres:secretpassword@db:5432/myapp
      HURRICANE_FAST_404: "auto"
      HURRICANE_RATE_LIMIT: "true"
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      # Hurricane isolates probes on port 8001 by default (port + 1)
      test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8001/alive')"]
      interval: 10s
      timeout: 2s
      retries: 3

volumes:
  postgres_data:

Why This Is Better:

• One Web Container: Eliminates Nginx configuration files, socket volumes, and permission mismatches.
• Automated Healthchecks: Docker's healthcheck directly queries Hurricane's /alive probe.
• Preflight Migration Safety: --check-migrations-apply automatically verifies database connectivity and applies schema migrations before accepting HTTP requests.

2. Virtual Machines & Bare Metal (Systemd)

If you deploy Django directly to virtual private servers (Hetzner, DigitalOcean, AWS EC2, Linode) using systemd, Hurricane replaces Gunicorn, Uvicorn, and local Nginx reverse proxies.

Create a systemd service file at /etc/systemd/system/django.service:

[Unit]
Description=Django Hurricane Application Server
After=network.target postgresql.service

[Service]
Type=simple
User=django
Group=django
WorkingDirectory=/var/www/myapp
EnvironmentFile=/var/www/myapp/.env

# Execute Hurricane directly from your Python virtualenv
ExecStart=/var/www/myapp/.venv/bin/python manage.py serve \
    --port=80 \
    --static \
    --media \
    --check-migrations-apply

Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable --now django.service

Inspect service health:

curl -I http://localhost/alive
curl -I http://localhost/ready

3. Cloud PaaS (Fly.io, AWS ECS, Render)

Modern Cloud application platforms rely on standard HTTP health check probes to verify container status and route traffic. Hurricane's built-in probes integrate naturally with these platforms.

Fly.io Deployment

Fly.io uses fly.toml to configure application health checks and HTTP service routing:

app = "my-django-app"
primary_region = "fra"

[http_service]
  internal_port = 8000
  force_https = true
  auto_stop_machines = false
  auto_start_machines = true
  min_machines_running = 1

  [[http_service.checks]]
    interval = "10s"
    timeout = "2s"
    grace_period = "5s"
    method = "GET"
    path = "/alive"

  [[http_service.checks]]
    interval = "15s"
    timeout = "2s"
    method = "GET"
    path = "/ready"

In your Dockerfile, start Hurricane with combined ports:

CMD ["python", "manage.py", "serve", "--port=8000", "--probe-port=8000", "--static"]

AWS ECS / Fargate with Application Load Balancer (ALB)

When registering Hurricane containers into an AWS ECS Target Group behind an Application Load Balancer:

• Target Port: 8000 (HTTP)
• Health Check Path: /ready
• Health Check Interval: 15 seconds
• Healthy Threshold: 2
• Unhealthy Threshold: 3

During rolling ECS task deployments, the ALB automatically polls /ready. If database connection pools are not ready or if request queues saturate, Hurricane returns HTTP 400, prompting the ALB to route traffic to healthy tasks until the new task is fully ready.

Port Strategy: Combined vs. Isolated Probes

Hurricane supports two probe port modes to match your deployment architecture:

In standalone and Cloud PaaS deployments, running on a single combined port simplifies firewall rules, ingress configurations, and container port mapping while retaining the full benefits of /alive, /ready, /startup, and /metrics.