CerebriumAI · mintlify · Jun 30, 2026 · Jul 15, 2026 · Jul 15, 2026
@@ -5,7 +5,7 @@ description: "Run ASGI/WSGI Python apps on Cerebrium"
 
 Cerebrium's default runtime covers most app needs. For more control, use ASGI or WSGI servers through the custom runtime feature - enabling custom authentication, dynamic batching, frontend dashboards, public endpoints, and WebSocket connections.
 
-## Setting Up Custom Servers
+## Setting up custom servers
 
 A basic FastAPI server running as a custom server on Cerebrium:
 
@@ -58,6 +58,6 @@ The configuration requires three key parameters:
 
 The [FastAPI Server Example](https://github.com/CerebriumAI/examples) provides a complete implementation.
 
-## Request Headers
+## Request headers
 
 Custom web servers receive the Cerebrium run ID in the `X-Request-Id` header on every request. This corresponds to the internal `run_id` and is useful for tracking and debugging.
@@ -12,7 +12,7 @@ Unlike traditional Docker or Kubernetes setups with multiple configuration files
 
 Python decorators scatter infrastructure settings throughout code files, making changes risky and reviews difficult. TOML centralizes configuration in one place, making it easier to track changes and maintain consistency. Its hierarchical structure maps naturally to app requirements without the accidental complexity of code-based configuration.
 
-### Getting Started
+### Getting started
 
 Run `cerebrium init` to create a `cerebrium.toml` file in the project root. Edit it to match the app's requirements.
 
@@ -24,7 +24,7 @@ Run `cerebrium init` to create a `cerebrium.toml` file in the project root. Edit
   section of your `cerebrium.toml` file.
 </Info>
 
-## Hardware Configuration
+## Hardware configuration
 
 Configure GPU type and memory allocations in the hardware section:
 
@@ -40,7 +40,7 @@ For detailed hardware specifications see the [toml reference](/toml-reference/to
 
 ## Dependency management
 
-### Selecting a Python Version
+### Selecting a Python version
 
 The Python runtime version forms the foundation of every Cerebrium app. Supported versions: 3.10 to 3.13. Specify the version in the deployment section:
 
@@ -58,7 +58,7 @@ To use a later Python version, please use a [Dockerfile](http://localhost:3000/c
   the base environment and all Python package installations.
 </Warning>
 
-### Adding Python Packages
+### Adding Python packages
 
 Manage Python dependencies directly in TOML or through requirement files:
 
@@ -83,7 +83,7 @@ pip = "requirements.txt"
 
 Cerebrium caches pip packages at the node level - including wheel files and compiled binaries - so subsequent builds only install new or updated packages. This significantly reduces build times.
 
-### Adding APT Packages
+### Adding APT packages
 
 System-level packages (image-processing libraries, audio codecs, etc.) are declared under `[cerebrium.dependencies.apt]`:
 
@@ -103,7 +103,7 @@ apt = "deps_folder/pkglist.txt"
 
 Changes to APT packages trigger a full rebuild of the container image, so builds take longer than when modifying Python packages alone.
 
-### Conda Packages
+### Conda packages
 
 Conda excels at managing complex system-level Python dependencies, particularly for GPU support and scientific computing:
 
@@ -123,11 +123,11 @@ conda = "conda_pkglist.txt"
 
 Like APT packages, Conda packages modify system-level components. Changes trigger a full rebuild. Batch Conda dependency updates together to minimize rebuild time.
 
-## Build Commands
+## Build commands
 
 The build process includes two command types that execute at different stages during container image creation.
 
-### Pre-build Commands
+### Pre-build commands
 
 Pre-build commands execute at the start of the build process, before dependency installation. Use them to set up the build environment:
 
@@ -143,7 +143,7 @@ pre_build_commands = [
 
 Common uses: installing build tools, configuring system settings, or preparing the environment for subsequent build steps.
 
-### Shell Commands
+### Shell commands
 
 Shell commands execute after all dependencies install and the application code copies into the container. This later timing ensures access to the complete environment:
 
@@ -159,11 +159,11 @@ shell_commands = [
 
 Use shell commands for tasks that require the fully configured environment — such as compiling code that depends on installed libraries or downloading resources.
 
-## Custom Docker Base Images
+## Custom Docker base images
 
 The base image determines the OS foundation for the container. The default Debian slim image works for most Python apps; other validated base images support specific requirements.
 
-### Supported Base Images
+### Supported base images
 
 Supported base image categories include NVIDIA, Ubuntu, and Python images.
 
@@ -182,7 +182,7 @@ docker_base_image_url = "debian:bookworm-slim" # Default minimal image
   add only essential components as needed.
 </Tip>
 
-#### Public Docker Hub Images with Namespaces
+#### Public Docker Hub images with namespaces
 
 Public Docker Hub images with a namespace (e.g., `bob/infinity`, `huggingface/transformers`) require a local Docker Hub login, even though the image is public. Cerebrium reads `~/.docker/config.json` to authenticate image pulls.
 
@@ -211,7 +211,7 @@ docker_base_image_url = "bob/infinity:latest"
   with our build system.
 </Warning>
 
-#### Public AWS ECR Images
+#### Public AWS ECR images
 
 Public ECR images from the `public.ecr.aws` registry work without authentication:
 
@@ -222,11 +222,11 @@ docker_base_image_url = "public.ecr.aws/lambda/python:3.11"
 
 However, **private ECR images** require authentication. See [Using Private Docker Registries](/container-images/private-docker-registry) for setup instructions.
 
-## Custom Runtimes
+## Custom runtimes
 
 Cerebrium's default runtime covers most apps. Custom runtimes provide more control, enabling features like custom authentication, dynamic batching, public endpoints, or WebSocket connections.
 
-### Basic Configuration
+### Basic configuration
 
 Define a custom runtime by adding the `cerebrium.runtime.custom` section to the configuration:
 
@@ -252,7 +252,7 @@ Key parameters:
   for a detailed implementation of a FastAPI server that uses a custom runtime.
 </Info>
 
-### Self-Contained Servers
+### Self-contained servers
 
 Custom runtimes also support apps with built-in servers. For example, deploying a VLLM server requires no Python code:
 
@@ -268,7 +268,7 @@ torch = "latest"
 vllm = "latest"
 ```
 
-### Important Notes
+### Important notes
 
 - Code is mounted in `/cortex` - adjust paths accordingly.
 - The port in your entrypoint must match the `port` parameter.
@@ -283,11 +283,11 @@ Deploy with `cerebrium deploy -y` - the system automatically detects custom runt
 
 The build process follows a sequence that transforms source code into a production-ready container image:
 
-### Stage 1: App Upload
+### Stage 1: App upload
 
 Code is uploaded to Cerebrium, including all source files, configuration, and additional assets needed for the app.
 
-### Stage 2: Image Creation
+### Stage 2: Image creation
 
 The system creates a container image through the following sequential steps:
 
@@ -298,6 +298,6 @@ The system creates a container image through the following sequential steps:
 5. **Python Code Copy**: The app's source code copies into the container, placing it in the correct directory structure.
 6. **Shell Commands Execute**: Finally, any build-time shell commands run to complete the image setup.
 
-### Stage 3: Production Image
+### Stage 3: Production image
 
 The result is a production-ready container image that contains everything needed to run the app. This image serves as a blueprint for creating individual containers when the app receives requests.
@@ -12,13 +12,13 @@ Deploy apps globally across multiple continents to reduce latency through co-loc
   about features/functionality you would like to see
 </Warning>
 
-## Why Use Multi-Region Deployment
+## Why use multi-region deployment
 
 - **Reduced Latency**: Deploy closer to users for faster response times and better experience with real-time applications like voice agents and LLMs
 - **Data Residency**: Meet data protection requirements by keeping sensitive data within specific geographic regions to comply with regulations like GDPR and CCPA
 - **High Availability**: Ensure fault tolerance and continuous service through geographic redundancy, disaster recovery, and load balancing across multiple regions
 
-## Available Regions
+## Available regions
 
 Cerebrium supports deployment across three major continents with the following regions:
 
@@ -42,7 +42,7 @@ Cerebrium supports deployment across three major continents with the following r
   region not currently listed.
 </Info>
 
-## CLI Configuration
+## CLI configuration
 
 Configure the CLI to work with different regions in two ways:
 
@@ -68,7 +68,7 @@ cerebrium download results.json -r eu-north-1
   `cerebrium region set` is not modified.
 </Info>
 
-## App Deployment
+## App deployment
 
 Set the deployment region using the `region` parameter in the `[cerebrium.hardware]` section of `cerebrium.toml`:
 
@@ -85,7 +85,7 @@ memory = 8.0
 
 Pricing varies by region based on local infrastructure costs and availability:
 
-## GPU Availability by Region
+## GPU availability by region
 
 GPU availability and pricing vary across regions due to infrastructure constraints and local demand:
 

@@ -14,7 +14,7 @@ curl -X POST https://api.cerebrium.ai/v4/p-xxxxxxxx/<YOUR-APP>/run?webhookEndpoi
 
 The proxy forwards the response body as a POST request to the specified webhook — no code changes required. Ensure the webhook endpoint accepts POST requests. Webhook forwarding works with both Cortex and Custom runtimes, but only for HTTP requests (not WebSockets).
 
-## Retry Behavior
+## Retry behavior
 
 Webhook requests are sent asynchronously and do not block the function's response. Failed deliveries are retried automatically:
 
@@ -51,7 +51,7 @@ curl -X POST https://webhook.site/'\
        --data '{"smile": "wave"}'
 ```
 
-## Webhook Signature Verification
+## Webhook signature verification
 
 Verify that webhooks originate from Cerebrium using signature verification:
 

@@ -37,7 +37,7 @@ Test the WebSocket endpoint using websocat, a command-line WebSocket client:
 websocat wss://api.cerebrium.ai/v4/p-xxxxxxxx/<your-app-name>/<your-websocket-function-name>
 ```
 
-## Implementing the WebSocket Endpoint
+## Implementing the WebSocket endpoint
 
 Example WebSocket endpoint using FastAPI:
 
@@ -54,7 +54,7 @@ async def websocket_endpoint(websocket: WebSocket):
     await websocket.close()
 ```
 
-## Additional Info
+## Additional info
 
 Client-side Implementation: Handle the WebSocket connection properly on the client, including error handling and reconnection logic.
 

@@ -9,7 +9,7 @@ Mystic AI is sunsetting their services. They were an early pioneer that pushed t
 
 It covers converting existing Mystic code (using a stable diffusion example) and configuration to the Cerebrium platform, including deployment optimization for performance and cost efficiency.
 
-## Key Differences
+## Key differences
 
 Cerebrium helps teams deploy and run models efficiently. The infrastructure is designed for reliable performance:
 
@@ -19,9 +19,9 @@ Cerebrium helps teams deploy and run models efficiently. The infrastructure is d
 
 Cerebrium provides precise control over computing resources. Instead of managing entire instances, select the exact CPU, memory, and GPU power needed. Billing is per-second for actual resource usage. Use the [pricing calculator](https://cerebrium.ai/pricing) for cost estimates.
 
-## Migration Process
+## Migration process
 
-### 1. Project Setup and Configuration
+### 1. Project setup and configuration
 
 Install Cerebrium's command-line tool and create the project:
 
@@ -92,7 +92,7 @@ xformers = "latest"
 
 ```
 
-### 2. Code Migration
+### 2. Code migration
 
 Convert the model implementation. A typical Mystic pipeline:
 
@@ -283,7 +283,7 @@ curl --location 'https://api.cerebrium.ai/v4/p-xxxxxxxx/stable-diffusion/predict
 
 The Cerebrium platform provides the tools and support needed for a smooth transition.
 
-## Join the Community
+## Join the community
 
 Connect with other developers and the Cerebrium team for faster response and issue resolution:
 

@@ -11,7 +11,7 @@ This is useful for both CPU-only and GPU workloads. For CPU applications, checkp
 
 For example, ML and LLM frameworks often load large model weights and compile CUDA kernels at container start time, which can take many seconds or minutes. Loading from a checkpoint that already contains this initialized state can skip most of that delay.
 
-Since this feature is still in beta, please report all issues to the team via our [Discord Community](https://discord.gg/ATj6USmeE2) or via [Email](mailto:support@cerebrium.ai).
+Since this feature is still in beta, please report all issues to the team via our [Discord community](https://discord.gg/ATj6USmeE2) or via [email](mailto:support@cerebrium.ai).
 
 ## How to use
 
@@ -66,7 +66,7 @@ If checkpoint creation succeeds, subsequent containers restore from that snapsho
 
 A checkpoint is tightly coupled to a single deployment. To stop restoring from checkpoints, remove the POST request and redeploy the application.
 
-You can find several implementations in our [Examples repository on Github](https://github.com/CerebriumAI/examples).
+You can find several implementations in our [examples repository on GitHub](https://github.com/CerebriumAI/examples).
 
 ### vLLM example
 
@@ -111,12 +111,12 @@ engine.wake_up()
 
 **Ephemeral filesystem:** Any files written to disk before the checkpoint are not copied to the restored container. Only memory is checkpointed.
 
-**Provider Availability:** Checkpointing is only available on the <b>AWS provider</b>. More coming soon.
+**Provider availability:** Checkpointing is only available on the **AWS provider**. More coming soon.
 
 ## Platform-specific recommendations
 
 ### vLLM
 
 vLLM checkpointing support is not complete but is still possible. See [vllm-project/vllm#34303](https://github.com/vllm-project/vllm/issues/34303) and related issues.
 
-The larger the size of the memory checkpoint the slower the restore is. Reduce the size of the snapshot substantially and improve startup times by dropping the KV Cache before checkpoint and recreating it after restore. vLLM has functionality that does this built in as part of [vLLM Sleep Mode](https://docs.vllm.ai/en/latest/features/sleep_mode/).
+The larger the memory checkpoint, the slower the restore. To reduce snapshot size and improve startup times, drop the KV cache before checkpointing and recreate it after restore. vLLM has built-in functionality for this as part of [vLLM Sleep Mode](https://docs.vllm.ai/en/latest/features/sleep_mode/).
@@ -28,7 +28,7 @@ See the [Partner Services page](/partner-services/deepgram) to deploy a Deepgram
   you must use their API endpoint below.
 </Note>
 
-### LLM Deployment
+### LLM deployment
 
 The LLM is an OpenAI-compatible Llama-3 endpoint using the vLLM framework. For low TTFT, a quantized version is used (RedHatAI/Meta-Llama-3.1-8B-Instruct-quantized.w8a8).
 
@@ -413,7 +413,7 @@ def start_bot(room_url: str, token: str = None):
 
 The result is a fully functioning AI bot that interacts with users through speech in ~500ms. The next section creates a user interface.
 
-## Creating Meeting Room
+## Creating a meeting room
 
 Cerebrium runs any Python code, not just AI workloads. The following two functions use the Daily REST API to create a room and temporary token, both valid for 5 minutes.
 

@@ -12,11 +12,11 @@ ComfyUI is a popular no-code interface for building complex stable diffusion wor
 
 Production-scale deployment guidance for ComfyUI is limited. This tutorial covers deploying ComfyUI pipelines on Cerebrium as autoscaling API endpoints with pay-as-you-go compute. Find the full example code [here](https://github.com/CerebriumAI/examples/tree/master/7-image-and-video/1-comfyui).
 
-### Creating your Comfy UI workflow locally
+### Creating your ComfyUI workflow locally
 
 Create the workflow locally or using a rented GPU from [Lambda Labs](https://lambdalabs.com/). Ensure [ComfyUI is installed](https://github.com/comfyanonymous/ComfyUI#installing) in the local environment.
 
-This tutorial uses Stable Diffusion XL and ControlNet to create custom QR codes. Skip to "Export ComfyUI Workflow" if a workflow already exists.
+This tutorial uses Stable Diffusion XL and ControlNet to create custom QR codes. Skip to "Export the ComfyUI workflow" if a workflow already exists.
 
 1. Create the Cerebrium project: `cerebrium init 1-comfyui`
 2. Clone the ComfyUI GitHub project inside the project directory: `git clone https://github.com/comfyanonymous/ComfyUI`
@@ -29,7 +29,7 @@ This tutorial uses Stable Diffusion XL and ControlNet to create custom QR codes.
 
 The default ComfyUI workflow interface appears in this view. Use this locally running instance to build the image generation pipeline.
 
-### Export ComfyUI Workflow
+### Export the ComfyUI workflow
 
 The example GitHub repository contains a workflow.json file. Click the “Load” button on the right to load the workflow. It should appear populated
 
@@ -43,7 +43,7 @@ To export the workflow in API format, click the gear icon (settings) in the top-
 
 A button appears in the right hover panel labeled “Save (API format)”. Use it to save the workflow as “workflow_api.json”
 
-### ComfyUI Application
+### ComfyUI application
 
 The main code in `main.py` uses the exported ComfyUI API workflow to create an endpoint. The code:
 
@@ -256,7 +256,7 @@ def shutdown_event():
     terminate_process()
 ```
 
-### Deploy ComfyUI Application
+### Deploy the ComfyUI application
 
 Before deploying, define the deployment configuration in `cerebrium.toml`. This specifies dependencies, hardware, scaling, and any pre-run scripts: