docs: document RUNPOD_ALLOW_IP IP allowlisting for Pods and Serverless

pods/configuration/expose-ports.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Expose ports"
 description: "Learn how to make your Pod services accessible from the internet using HTTP proxy and TCP port forwarding"
 ---
@@ -15,19 +15,19 @@
 uvicorn main:app --host 0.0.0.0 --port 4000
 ```
 
 The external port users connect to will be different, depending on your chosen exposure method.
 
 ## HTTP access via Runpod proxy
 
 Runpod's HTTP proxy provides the easiest way to expose web services from your Pod. This method works well for REST APIs, web applications, and any HTTP-based service.
 
 ### Configure external HTTP ports
 
 To configure HTTP ports during Pod deployment, click **Edit Template** and add a comma-separated list of ports to the **Expose HTTP Ports (Max 10)** field.
 
 To configure HTTP ports for an existing Pod, navigate to the [Pod page](https://www.console.runpod.io/pods), expand your Pod, click the hamburger menu on the bottom-left, select **Edit Pod**, then add your port(s) to the **Expose HTTP Ports (Max 10)** field.
 
 You can also configure HTTP ports for a Pod template in the [My Templates](https://www.console.runpod.io/user/templates) section of the console.
 
 ### Access your service
 
@@ -61,16 +61,30 @@
 This architecture introduces important limitations:
 
 - **100-second timeout**: Cloudflare enforces a maximum connection time of 100 seconds. If your service doesn't respond within this time, the connection closes with a `524` error.
 - **HTTPS only**: All connections are secured with HTTPS, even if your internal service uses HTTP.
 - **Public accessibility**: Your service becomes publicly accessible. While the Pod ID provides some obscurity, implement proper authentication in your application.
 
 Design your application with these constraints in mind. For long-running operations, consider:
 - Implementing progress endpoints that return status updates.
 - Using background job queues with status polling.
 - Breaking large operations into smaller chunks.
 - Returning immediate responses with job IDs for later retrieval.
 
+### Restrict access by IP address
+
+By default, anyone who knows your Pod's proxy URL can reach your service. To limit access to specific source IP addresses, set the `RUNPOD_ALLOW_IP` environment variable on your Pod to a comma-separated list of IP addresses or IP address ranges:
+
+```bash
+RUNPOD_ALLOW_IP=203.0.113.7,198.51.100.0/24
+```
+
+The proxy checks the source IP of each request against this list before forwarding it to your Pod. Requests from addresses that aren't on the list receive a `400 Bad Request` response with an empty body. If the variable is empty or unset, the proxy allows all IP addresses.
+
+You can set `RUNPOD_ALLOW_IP` in a template or on an existing Pod under **Environment Variables**. See [Environment variables](/pods/templates/environment-variables#runpod-reserved-variables) for details.
+
+`RUNPOD_ALLOW_IP` only applies to ports exposed through the HTTP proxy. It doesn't restrict [TCP ports exposed via public IP](#tcp-access-via-public-ip), including SSH. To restrict access on TCP ports, configure a firewall inside your container or add authentication to your application.
+
 ## TCP access via public IP
 
 <Warning>
 Pods do not support UDP connections. If your application relies on UDP, you'll need to modify your application to use TCP-based communication instead.
@@ -78,7 +92,7 @@
 
 For services requiring direct TCP connections, lower latency, or protocols other than HTTP, use TCP port exposure with public IP addresses.
 
 ### Configure TCP ports
 
 In your Pod or template configuration, follow the same steps as for [HTTP ports](#configure-external-http-ports), but add ports to the **Expose TCP Ports** field. This enables direct TCP forwarding with a public IP address.
 
@@ -102,20 +116,20 @@
 
 ### Requesting symmetrical ports
 
 To request symmetrical mapping, specify port numbers above 70000 in your TCP configuration. These aren't valid port numbers, but signal Runpod to allocate matching internal and external ports.
 
 After Pod creation, check the **Connect** menu to see which symmetrical ports were assigned under **Direct TCP Ports**.
 
 ### Accessing port mappings programmatically
 
 Your application can discover assigned ports through environment variables. For example, if you specify `70000` and `70001` in your Pod configuration, you could use the following commands to retrieve the assigned ports:
 
 ```bash
 echo $RUNPOD_TCP_PORT_70000
 echo $RUNPOD_TCP_PORT_70001
 ```
 
 You can use these environment variables in your application configuration to automatically adapt to assigned ports:
 
 **Python example:**
 ```python
@@ -140,13 +154,14 @@
 ### Security considerations
 
 - **Implement authentication**: Both HTTP proxy and TCP access make your services publicly accessible. Always implement proper authentication and authorization in your applications.
+- **Restrict access by IP**: For HTTP proxy ports, set [`RUNPOD_ALLOW_IP`](#restrict-access-by-ip-address) to limit access to known IP addresses or ranges. This doesn't cover TCP ports.
 - **Use HTTPS for sensitive data**: While the proxy automatically provides HTTPS, TCP connections do not. Implement TLS in your application when handling sensitive data over TCP.
 - **Validate input**: Public endpoints are targets for malicious traffic. Implement robust input validation and rate limiting.
 
 ### Performance optimization
 
 - **Choose the right method**: Use HTTP proxy for web services and TCP for everything else. The proxy adds latency but provides automatic HTTPS and load balancing.
 - **Handle timeouts gracefully**: Design your application to work within the 100-second proxy timeout or use TCP for long-running connections.
 - **Monitor your services**: Implement health checks and monitoring to ensure your exposed services remain accessible.
 
 ### Configuration tips
@@ -159,7 +174,7 @@
 
 Different types of applications benefit from different exposure methods:
 
 - **Web APIs and REST services**: Use HTTP proxy for automatic HTTPS and simple configuration.
 - **WebSocket applications**: TCP exposure often works better for persistent connections that might exceed timeout limits.
 - **Database connections**: Use TCP with proper security measures. Consider using Runpod's global networking for internal-only databases.
 - **Development environments**: HTTP proxy works well for web-based IDEs and development servers.
@@ -168,11 +183,12 @@
 
 Try these fixes if you're having issues with port exposure:
 
 - **Service not accessible via proxy**: Ensure your service binds to `0.0.0.0` (all interfaces) not just `localhost` or `127.0.0.1`.
+- **400 Bad Request with an empty body from the proxy URL**: Your IP address isn't in the Pod's [`RUNPOD_ALLOW_IP`](#restrict-access-by-ip-address) list. Add your address or remove the variable.
 - **524 timeout errors**: If your service takes longer than 100 seconds to respond, consider using TCP or restructuring your application for faster responses.
 - **Connection refused**: Verify your service is running and listening on the correct port inside the Pod.
 - **Port already in use**: Check that no other services in your Pod are using the same port.
 - **Unstable connections**: For Community Cloud Pods, implement reconnection logic to handle IP address changes.
 
 ## Next steps
 

pods/templates/environment-variables.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Environment variables"
 description: "Configure Pods with environment variables for settings, secrets, and runtime information. See setup and usage details for Runpod Pods."
 ---
@@ -16,7 +16,7 @@
 2. Click **Add Environment Variable** and enter the key-value pair.
 
 **In Pod templates:**
 1. Navigate to [My Templates](https://www.console.runpod.io/user/templates).
 2. Create or edit a template and add variables in the **Environment Variables** section.
 
 **Using secrets:**
@@ -83,18 +83,26 @@
 | `RUNPOD_POD_HOSTNAME` | Server hostname. |
 | `RUNPOD_GPU_COUNT` | Number of GPUs available. |
 | `RUNPOD_CPU_COUNT` | Number of CPUs available. |
 | `RUNPOD_PUBLIC_IP` | Public IP address (if available). |
 | `RUNPOD_TCP_PORT_22` | Public port mapped to SSH. |
 | `RUNPOD_VOLUME_ID` | Attached network volume ID. |
 | `RUNPOD_API_KEY` | Pod-scoped API key. |
 | `PUBLIC_KEY` | Authorized SSH public keys. |
 | `CUDA_VERSION` | Installed CUDA version. |
 | `PYTORCH_VERSION` | Installed PyTorch version. |
 
+## Runpod-reserved variables
+
+Runpod reads these variables if you set them. They change how Runpod handles your Pod rather than configuring your application:
+
+| Variable | Description |
+| --- | --- |
+| `RUNPOD_ALLOW_IP` | Comma-separated list of IP addresses or IP address ranges allowed to reach your Pod's HTTP proxy ports, such as `203.0.113.7,198.51.100.0/24`. Requests from other addresses receive a `400` response. Doesn't apply to TCP ports. See [Restrict access by IP address](/pods/configuration/expose-ports#restrict-access-by-ip-address). |
+
 ## Best practices
 
 - **Use secrets for sensitive data**: Never hardcode API keys or passwords. Use [Runpod secrets](/pods/templates/secrets).
 - **Validate required variables**: Check that critical variables are set before your application starts.
 - **Provide defaults**: Use fallback values for non-critical configuration.
 - **Use descriptive names**: Prefer `DATABASE_PASSWORD` over `DB_PASS`.
 - **Group related variables**: Use consistent prefixes like `DB_HOST`, `DB_PORT`, `DB_NAME`.

serverless/development/environment-variables.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Environment variables"
 description: "Configure your Serverless endpoints with environment variables. Review configuration and operations guidance for Runpod Serverless."
 ---
@@ -7,19 +7,19 @@
 
 ## How environment variables work
 
 Environment variables are set in the Runpod console and are available to your handler at runtime through `os.environ`. Your handler can read these variables to configure its behavior.
 
 ## Set environment variables
 
 You can set environment variables in the Runpod console when [creating or editing your endpoint](/serverless/endpoints/overview):
 
 1. Navigate to your endpoint in the [Runpod console](https://console.runpod.io/serverless).
 2. Click on the **Settings** tab.
 3. Scroll to the **Environment Variables** section.
 4. Add your variables as key-value pairs.
 5. Click **Save** to apply the changes.
 
 These environment variables will be available to all workers running on your endpoint.
 
 ### Access environment variables in your handler
 
@@ -48,7 +48,7 @@
 
 ### Build-time variables
 
 Build-time variables are set in your Dockerfile using the `ENV` instruction. These are baked into your Docker image during the build:
 
 ```dockerfile title="Dockerfile"
 FROM runpod/base:0.4.0-cuda11.8.0
@@ -65,14 +65,22 @@
 
 ### Runtime variables
 
 Runtime variables are set in the Runpod console and can be changed without rebuilding your image. These override build-time variables with the same name:
 
 Runtime variables are useful for:
 - API keys and secrets.
 - Environment-specific configuration (dev, staging, prod).
 - Values that change frequently.
 - Sensitive information that shouldn't be in your image.
 
+## Runpod-reserved variables
+
+Runpod reserves some variable names. It reads them to change how it handles your endpoint, in addition to passing them to your workers:
+
+| Variable | Description |
+| --- | --- |
+| `RUNPOD_ALLOW_IP` | Comma-separated list of IP addresses or IP address ranges allowed to send requests to your endpoint, such as `203.0.113.7,198.51.100.0/24`. Requests from other addresses receive a `403` response before API key validation. See [IP allowlist](/serverless/endpoints/endpoint-configurations#ip-allowlist). |
+
 ## Common use cases
 
 ### API keys and secrets
@@ -131,7 +139,7 @@
 ```
 
 Set these variables in the Runpod console:
 - `BUCKET_ENDPOINT_URL`: Your bucket endpoint (e.g., `https://your-bucket.s3.us-west-2.amazonaws.com`)
 - `BUCKET_ACCESS_KEY_ID`: Your access key ID
 - `BUCKET_SECRET_ACCESS_KEY`: Your secret access key
 
@@ -141,7 +149,7 @@
 
 ### Feature flags
 
 Use environment variables to enable or disable features:
 
 ```python title="handler.py"
 import os

serverless/endpoints/endpoint-configurations.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Endpoint settings"
 sidebarTitle: "Endpoint settings"
 description: "Reference guide for all Serverless endpoint settings and parameters. Review configuration and operations guidance for Runpod Serverless."
@@ -17,27 +17,27 @@
 
 | Setting | Default | Description |
 |---------|---------|-------------|
 | **Active workers** | 0 | Always-on workers (eliminates cold starts) |
 | **Max workers** | 3 | Maximum concurrent workers |
 | **GPUs per worker** | 1 | GPU count per worker instance |
 | **Idle timeout** | 5s | Time before idle worker shuts down |
 | **Execution timeout** | 600s (10 min) | Max job duration |
 | **Job TTL** | 24h | Total job lifespan in system |
 | **FlashBoot** | Enabled | Faster cold starts via state retention |
 
 ## General configuration
 
 ### Endpoint name
 
 Display name for identifying your endpoint in the console. Does not affect the endpoint ID used for API requests.
 
 ### Endpoint type
 
 **Queue-based endpoints** use a built-in queueing system with guaranteed execution and automatic retries. Ideal for async tasks, batch processing, and long-running jobs. Implemented using [handler functions](/serverless/workers/handler-functions).
 
 **Load balancing endpoints** route traffic directly to workers, bypassing the queue. Designed for low-latency applications like real-time <InferenceTooltip /> or custom REST APIs. See [Load balancing endpoints](/serverless/load-balancing/overview).
 
 ### GPU configuration
 
 Determines the hardware tier for your workers. Select multiple GPU categories to create a prioritized fallback list. If your first choice is unavailable, Runpod automatically uses the next option. Selecting multiple types improves availability during high demand.
 
@@ -47,7 +47,7 @@
 
 Specify up to three GPU types in priority order when configuring an endpoint. Runpod uses this ranking to distribute workers across available GPUs, improving availability during high demand.
 
 For endpoints with five or more workers, Runpod distributes workers across your selected GPU priorities. Most workers run on your primary GPU type, with fewer assigned to secondary and tertiary selections. This reduces throttling when your primary GPU is constrained.
 
 For endpoints with fewer than five workers, all workers use the highest-priority GPU type available.
 
@@ -61,15 +61,15 @@
 
 Maximum concurrent instances your endpoint can scale to. Acts as a cost safety limit and concurrency cap. Set ~20% higher than expected max concurrency to handle traffic spikes smoothly.
 
 ### GPUs per worker
 
 Number of GPUs assigned to each worker instance. Default is 1. Generally prioritize fewer high-end GPUs over multiple lower-tier GPUs.
 
 ### Auto-scaling type
 
 **Queue delay**: Adds workers when requests wait longer than the threshold (default: 4 seconds). Best when slight delays are acceptable for higher utilization.
 
 **Request count**: More aggressive scaling based on pending + active work. Formula: `Math.ceil((requestsInQueue + requestsInProgress) / scalerValue)`. Use scaler value of 1 for max responsiveness. Recommended for LLM workloads or frequent short requests.
 
 ## Lifecycle and timeouts
 
@@ -80,24 +80,24 @@
 ### Idle endpoint scale-down
 
 Runpod automatically scales down endpoints that go a long time without any requests, so unused endpoints don't keep consuming your account balance. 
 * After 3 days with no requests, the endpoint's max workers is reduced to 2 and Runpod sends you an email notification. 
 * After 7 days with no requests, max workers is set to 0. 
 
 This scale-down is automatic and system-driven, and the timer is based on request activity, so any incoming request resets it.
 
 Once an endpoint has been scaled down this way, it stays at its reduced max workers until you raise the value yourself. To use the endpoint again, increase its max workers in the Runpod console. To prevent an endpoint from scaling down in the first place, make sure it continues to receive requests.
 
 ### Execution timeout
 
 Maximum duration for a single job. When exceeded, the job fails and the worker stops. Keep enabled to prevent runaway jobs. Default: 600s (10 min). Range: 5s to 7 days.
 
 Configure in **Advanced** settings, or override per-request via `executionTimeout` in the [job policy](/serverless/endpoints/send-requests#execution-policies).
 
 ### Job TTL (time-to-live)
 
 Total lifespan of a job in the system. When TTL expires, job data is deleted regardless of state (queued, running, or completed). Default: 24 hours. Range: 10s to 7 days.
 
 The timer starts at submission, not execution. If a job queues for 45 minutes with a 1-hour TTL, only 15 minutes remain for execution.
 
 <Warning>
 TTL is a hard limit. If it expires while a job is running, the job is immediately removed and status checks return 404. Set TTL to cover both expected queue time and execution time.
@@ -110,16 +110,16 @@
 | Request type | Retention | Notes |
 |--------------|-----------|-------|
 | Async (`/run`) | 30 min | Retrieve via `/status/{job_id}` |
 | Sync (`/runsync`) | 1 min | Returned in response; also available via `/status/{job_id}` |
 
 Results are permanently deleted after retention expires.
 
 ## Performance features
 
 ### FlashBoot
 
 Reduces cold starts by retaining worker state after spin-down, allowing faster "revival" than fresh boots. Most effective on endpoints with consistent traffic where workers frequently cycle between active and idle.
 Both new GPU and CPU endpoints will have FlashBoot enabled by default, and you can edit existing endpoints to enable or disable FlashBoot.
 
 ### Model
 
@@ -135,10 +135,22 @@
 
 [Network volumes](/storage/network-volumes) provide persistent storage across worker restarts. Tradeoffs: adds network latency and restricts your endpoint to the volume's data center. Use only when you need shared persistence or datasets exceeding container limits.
 
 ### CUDA version selection
 
 Ensures workers run on <MachinesTooltip /> with compatible drivers. Select your required version plus all newer versions, since CUDA is backward compatible and a wider range increases available hardware.
 
 ### Expose HTTP/TCP ports
 
 Exposes the worker's public IP and port for direct external communication. Required for persistent connections like WebSockets.
+
+### IP allowlist
+
+To restrict which source IP addresses can send requests to your endpoint, add a `RUNPOD_ALLOW_IP` environment variable to your endpoint with a comma-separated list of IP addresses or IP address ranges:
+
+```bash
+RUNPOD_ALLOW_IP=203.0.113.7,198.51.100.0/24
+```
+
+Runpod checks the source IP of every request before validating the API key. Requests from addresses that aren't on the list receive a `403 Forbidden` response with the message `ip address not allowed`. This applies to every endpoint operation, including `/run`, `/runsync`, `/status`, and `/health`, and to both queue-based and load balancing endpoints. Changes take effect within a few seconds and don't restart your workers. If the variable is empty or unset, Runpod allows all IP addresses.
+
+To set the variable, open your endpoint in the [Runpod console](https://console.runpod.io/serverless), go to the **Settings** tab, and add it under **Environment Variables**. See [Environment variables](/serverless/development/environment-variables#runpod-reserved-variables) for details.

serverless/endpoints/send-requests.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Send API requests"
 sidebarTitle: "Send API requests"
 description: "Submit and manage jobs for your queue-based endpoints by sending HTTP requests. Review configuration and operations guidance for Runpod Serverless."
@@ -21,13 +21,13 @@
 
 ## How requests work
 
 A **job** is a unit of work containing the input data from the request, packaged for processing by your [workers](/serverless/workers/overview). If no worker is immediately available, the job is queued. Once a worker is available, the job is processed using your worker's [handler function](/serverless/workers/handler-functions).
 
 ## Sync vs. async
 
 - `/runsync` submits a **synchronous** job.
   - Client waits for the job to complete before returning the result.
   - Results are available for 1 minute (5 minutes max).
   - Ideal for quick responses and interactive applications.
 - `/run` submits an **asynchronous** job.
   - The job processes in the background; retrieve results via `/status`.
@@ -71,7 +71,7 @@
 | `/cancel`         | POST   | Stop a job in progress or waiting in the queue.                            |
 | `/retry`          | POST   | Requeue a failed or timed-out job with the same job ID and input.          |
 | `/purge-queue`    | POST   | Clear all pending jobs from the queue.                                     |
 | `/health`         | GET    | Monitor endpoint status, including worker and job statistics.              |
 
 See the [operation reference](/serverless/endpoints/operation-reference) for detailed examples using cURL and the Runpod SDK.
 
@@ -81,7 +81,7 @@
 
 ## Advanced options
 
 Beyond the required `input` object, you can include optional top-level parameters for additional functionality.
 
 ### Webhook notifications
 
@@ -113,17 +113,17 @@
 
 | Option             | Description                                              | Default              | Constraints             |
 |--------------------|----------------------------------------------------------|----------------------|-------------------------|
 | `executionTimeout` | Maximum time a job can run while being processed         | 600000 (10 minutes)  | Min 5 sec, max 7 days   |
 | `lowPriority`      | When true, job won't trigger worker scaling              | false                | -                       |
 | `ttl`              | Total lifespan of the job before deletion                | 86400000 (24 hours)  | Min 10 sec, max 7 days  |
 
 <Info>
 Setting `executionTimeout` in a request overrides the default endpoint setting for that specific job only.
 </Info>
 
 #### TTL vs. execution timeout
 
 - **`ttl`**: Total lifespan of the job. Timer starts when submitted and covers queue time, execution time, and everything in between. When TTL expires, the job is deleted regardless of state.
 - **`executionTimeout`**: Maximum time the job can actively run once a worker picks it up. Only enforced during execution.
 
 <Warning>
@@ -132,7 +132,7 @@
 
 #### Long-running jobs
 
 For jobs that need to run longer than the default 24-hour TTL:
 
 1. Set `executionTimeout` to your desired maximum runtime.
 2. Set `ttl` to cover **both expected queue time and execution time**.
@@ -147,7 +147,7 @@
 }
 ```
 
 This allows up to 48 hours of active runtime with 72 hours total lifespan (24 hours headroom for queue time).
 
 <Warning>
 Both `ttl` and `executionTimeout` have a maximum of 7 days. A job with 7-day TTL that queues for 2 days only has 5 days remaining for execution.
@@ -155,12 +155,12 @@
 
 #### Result retention
 
 After completion, results are retained for a fixed period separate from TTL:
 
 | Request type       | Retention period |
 |--------------------|------------------|
 | `/run` (async)     | 30 minutes       |
 | `/runsync` (sync)  | 1 minute         |
 
 ### S3-compatible storage
 
@@ -199,7 +199,7 @@
 
 Rate limits scale with your endpoint's worker count. The system uses whichever is higher between:
 
 1. **Base limit**: Fixed rate limit per user per endpoint (shown above)
 2. **Worker-based limit**: `number_of_running_workers × requests_per_worker`
 
 Requests exceeding the effective limit return `429 (Too Many Requests)`. Implement retry logic with exponential backoff to handle rate limiting gracefully.
@@ -212,15 +212,16 @@
 |-------------|-----------------------|---------------------------------------------------|
 | 400         | Bad Request           | Check your request format and parameters          |
 | 401         | Unauthorized          | Verify your API key is correct and has permission |
+| 403         | Forbidden             | Your IP address isn't in the endpoint's [IP allowlist](/serverless/endpoints/endpoint-configurations#ip-allowlist) |
 | 404         | Not Found             | Check your endpoint ID                            |
 | 429         | Too Many Requests     | Implement backoff and retry logic                 |
 | 500         | Internal Server Error | Check endpoint logs; worker may have crashed      |
 
 | Issue              | Possible Causes                          | Solutions                                                           |
 |--------------------|------------------------------------------|---------------------------------------------------------------------|
 | Job stuck in queue | No available workers, max workers reached | Increase max workers, check endpoint health                        |
 | Timeout errors     | Job takes longer than execution timeout  | Increase timeout in job policy, optimize processing                |
 | Failed jobs        | Worker errors, input validation issues   | Check [endpoint logs](/serverless/development/logs), verify input  |
 | Missing results    | Results expired                          | Retrieve within expiration window (30 min async, 1 min sync)       |
 
 See [error handling](/serverless/workers/handler-functions#error-handling) for implementation details.

serverless/load-balancing/overview.mdx

@@ -1,14 +1,14 @@
 ---
 title: "Overview"
 sidebarTitle: "Overview"
 description: "Deploy custom direct-access REST APIs with load balancing Serverless endpoints. Review configuration and operations guidance for Runpod Serverless."
 ---
 
 import { RequestsTooltip, QueueBasedEndpointsTooltip } from "/snippets/tooltips.jsx";
 
 Load balancing endpoints route incoming traffic directly to available workers, bypassing the queueing system. Unlike <QueueBasedEndpointsTooltip /> that process requests sequentially, load balancing distributes requests across your worker pool for lower latency.
 
 You can create custom REST endpoints accessible via a unique URL:
 
 ```
 https://ENDPOINT_ID.api.runpod.ai/YOUR_CUSTOM_PATH
@@ -28,15 +28,15 @@
 
 ### Queue-based endpoints
 
 With queue-based endpoints, <RequestsTooltip /> are placed in a queue and processed in order. They use the standard handler pattern (`def handler(job)`) and are accessed through fixed endpoints like `/run` and `/runsync`.
 
 These endpoints are better for tasks that can be processed asynchronously and guarantee request processing, similar to how TCP guarantees packet delivery in networking.
 
 ### Load balancing endpoints (new)
 
 Load balancing endpoints send requests directly to workers without queuing. You can use any HTTP framework such as FastAPI or Flask, and define custom URL paths and API contracts to suit your specific needs.
 
 These endpoints are ideal for real-time applications and streaming, but provide no queuing mechanism for request backlog, similar to UDP's behavior in networking.
 
 
 ## Endpoint type comparison table
@@ -44,15 +44,15 @@
  Aspect | Load balancing | Queue-based |
 |--------|----------------|-------------|
 | **Request flow** | Direct to worker HTTP server | Through queueing system |
 | **Implementation** | Custom HTTP server (FastAPI, Flask, etc.) | Handler function |
 | **API flexibility** | Custom URL paths, any HTTP capability | Fixed `/run` and `/runsync` endpoints |
 | **Backpressure** | Drops requests when overloaded | Queue buffering |
 | **Latency** | Lower (single-hop) | Higher (queue + worker) |
 | **Error handling** | No built-in retry | Automatic retries |
 
 ## Worker comparison
 
 **Queue-based worker** (traditional):
 
 ```python
 import runpod
@@ -64,7 +64,7 @@
 runpod.serverless.start({"handler": handler})
 ```
 
 **Load balancing worker** (custom HTTP server):
 
 ```python
 from fastapi import FastAPI
@@ -116,19 +116,20 @@
 
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `PORT` | `80` | Main application server port |
 | `PORT_HEALTH` | Same as `PORT` | Health check endpoint port |
 | `HEALTH_CHECK_PATH` | `/ping` | Path the load balancer polls to check worker health |
+| `RUNPOD_ALLOW_IP` | Unset, allows all | Comma-separated IP addresses or IP address ranges allowed to send requests to the endpoint. See [IP allowlist](/serverless/endpoints/endpoint-configurations#ip-allowlist) |
 
 If using a custom port, add it to your endpoint's environment variables and expose it in container configuration (under **Expose HTTP Ports (Max 10)**).
 
 ## Timeouts and limits
 
 | Limit | Value |
 |-------|-------|
 | **Request timeout** | 2 min (no worker available) |
 | **Processing timeout** | 5.5 min (per request) |
 | **Payload limit** | 30 MB (request and response) |
 
 For payloads larger than 30 MB, use [network volumes](/storage/network-volumes) or implement chunking.
 
@@ -172,6 +173,6 @@
 Use load balancing endpoints when you need:
 
 - Direct access to your model's HTTP server.
 - Internal batching systems (like vLLM).
 - Non-JSON payloads.
 - Multiple endpoints within a single worker.