While Cerebrium’s default runtime works well for most app needs, teams sometimes need more control over their web server implementation. Using ASGI or WSGI servers through Cerebrium’s custom runtime feature enables capabilities like custom authentication, dynamic batching, frontend dashboards, public endpoints, and WebSocket connections.Documentation Index
Fetch the complete documentation index at: https://cerebrium-assembly-ai.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Setting Up Custom Servers
Here’s a simple FastAPI server implementation that shows how custom servers work in Cerebrium:cerebrium.toml by adding a custom runtime section:
entrypoint: The command that starts your serverport: The port your server listens onhealthcheck_endpoint: The endpoint used to confirm instance health. If unspecified, defaults to a TCP ping on the configured port. If the health check registers a non-200 response, it will be considered unhealthy, and be restarted should it not recover timely.readycheck_endpoint: The endpoint used to confirm if the instance is ready to receive. If unspecified, defaults to a TCP ping on the configured port. If the ready check registers a non-200 response, it will not be a viable target for request routing.
For ASGI applications like FastAPI, include the appropriate server package
(like
uvicorn) in your dependencies. After deployment, your endpoints become
available at
https://api.aws.us-east-1.cerebrium.ai/v4/[project-id]/[app-name]/your/endpoint.Request Headers
When using custom web servers, you can access the Cerebrium run ID through theX-Request-Id header, which is included in all requests to your endpoints. This header is particularly useful for tracking and debugging requests in your custom runtime implementation, as it corresponds to the run_id that Cerebrium uses internally.