KVM VPS from Rs 149/mo. Mumbai, Noida and Jaipur nodes.

24×7 infrastructure operations Sales +91 98297 14343
vpswala.in
VPSWala 3 min read

FastAPI VPS Requirements: Uvicorn Workers, Memory Tuning & Production Sizing

Learn how to size Linux VPS hardware for FastAPI production deployments with Uvicorn worker calculations, systemd service management, and Nginx proxy tuning.

Deploying FastAPI applications in production requires an infrastructure configuration that fully leverages asynchronous Python capabilities. Built on top of Starlette and Pydantic, FastAPI achieves high request throughput by handling non-blocking network I/O through Python's asyncio event loop. However, ensuring stable production execution under concurrent traffic demands precise sizing of Uvicorn server worker processes, memory headroom calculations, and an optimized reverse proxy layer.

Asynchronous Event Loops vs Multi-Process Worker Scaling

While an asynchronous event loop handles thousands of concurrent idle connections or non-blocking database queries on a single CPU core, Python code execution is constrained by the Global Interpreter Lock (GIL). If an endpoint performs CPU-intensive tasks, such as password hashing, cryptographic verification, image processing, or data serialization, the single-threaded event loop becomes blocked, causing incoming requests to queue up.

According to official FastAPI deployment documentation, scaling across multiple physical or virtual CPU cores requires running multiple worker processes using an ASGI server like Uvicorn. Administrators can manage server workers using either the fastapi CLI or the uvicorn command directly:

# Managing worker processes with FastAPI CLI
fastapi run --workers 4 main.py

# Or managing workers directly with Uvicorn
uvicorn main:app --workers 4 --host 127.0.0.1 --port 8000

A critical rule from official documentation is that the development flag --reload and the production flag --workers are mutually exclusive. Development reloading must never be enabled in production environments because file-watching daemons degrade production execution speed and consume unnecessary memory.

Calculating Uvicorn Workers and Memory Footprint

To determine the optimal number of worker processes, apply the standard formula recommended in production documentation:

Workers = (2 * vCPU Cores) + 1

For example, on a 4-vCPU virtual server, this formula yields 9 worker processes. However, for applications that perform heavy CPU computation or high-throughput database serialization, a 1:1 ratio (1 worker per physical core) is recommended to prevent thread-switching overhead and CPU core contention.

Memory sizing must be calculated per worker process. A lightweight FastAPI application typically consumes 80 MB to 150 MB of RAM per worker at baseline. However, if endpoints load large machine learning models, process Pandas dataframes, or handle large multipart file uploads, memory consumption can rise to 500 MB or more per process. Ensure your virtual server provides sufficient physical RAM to accommodate all active workers plus an additional 1 GB to 2 GB for the Linux OS, Nginx buffers, and database client libraries.

Managing Worker Timeouts and Request Concurrency

In addition to sizing worker counts, configuring request timeouts and concurrency limits prevents runaway queries from monopolizing worker threads. By default, Uvicorn allows long-lived connections, which can lead to slow-client resource exhaustion. In high-traffic environments, configure explicit timeout thresholds:

# Running Uvicorn with explicit connection and timeout limits
uvicorn main:app \
  --workers 4 \
  --timeout-keep-alive 5 \
  --limit-concurrency 1000 \
  --backlog 2048 \
  --uds /run/fastapi.sock

The --limit-concurrency flag sets the maximum number of concurrent HTTP connections before issuing 503 Service Unavailable responses, protecting backend databases from connection pool exhaustion during traffic surges. The --backlog parameter defines the maximum queue length for pending connections at the socket layer.

Process Supervision with systemd

In production, Uvicorn should be managed as a system service using systemd to ensure automatic restarts following unexpected exceptions or server reboots. Create a service file at /etc/systemd/system/fastapi.service:

[Unit]
Description=FastAPI Uvicorn Production Application
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/fastapi-app
Environment="PATH=/var/www/fastapi-app/venv/bin"
ExecStart=/var/www/fastapi-app/venv/bin/uvicorn main:app --workers 4 --uds /run/fastapi.sock
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Using a Unix domain socket (--uds /run/fastapi.sock) rather than a local loopback TCP port (127.0.0.1:8000) reduces network protocol overhead and increases communication throughput between Nginx and Uvicorn.

Nginx Reverse Proxy Configuration

Nginx acts as the public-facing gateway, handling SSL/TLS termination, request buffering, static asset delivery, and DDoS mitigation before forwarding requests to Uvicorn:

server {
    listen 80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # SSL certificates and security headers
    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location / {
        proxy_pass http://unix:/run/fastapi.sock;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off;
        proxy_buffering on;
        proxy_buffers 16 16k;
        proxy_buffer_size 32k;
    }
}

Note: If your application utilizes Server-Sent Events (SSE) or WebSockets, ensure proxy_buffering off; and HTTP/1.1 upgrade headers are configured for those specific location blocks.

FastAPI Production Hardware Sizing Matrix

Concurrency Level Expected Request Volume Recommended VPS Allocation Uvicorn Worker Layout
Microservice / Staging Under 100 requests/sec KVM VPS: 2 vCPU, 4 GB RAM, RAID NVMe 2 to 4 Workers, Unix Domain Socket
Production Web API 100 to 1,000 requests/sec KVM VPS: 4 to 8 vCPU, 8 GB to 16 GB RAM 8 Workers, Nginx Caching & Buffers
High-Throughput / Data Pipeline 1,000+ requests/sec AMD Ryzen 9 9950X: 8 to 10 vCPU, 32 GB DDR5 10 to 16 Workers on Zen 5 High-Clock Cores

VPSWala delivers developer-centric KVM Cloud VPS hosting starting at Rs 149 per month, alongside high-frequency AMD Ryzen 9 9950X instances featuring Zen 5 cores boosting up to 5.7 GHz with DDR5 memory pools. All plans include full root access and GST invoicing. Explore plans on KVM Cloud VPS or evaluate performance instances on AMD Ryzen 9950X VPS.


Sources

Not sure which size?

Send the stack, get a size.

Tell us the operating system, application stack, current traffic, database size and where it hurts today. You get a sizing recommendation, the matching plan and a price.

Related

More on this.

Get sizing help See VPS plans