Skip to main content
This page provides ready-to-use Dockerfile templates for common deployment patterns and covers best practices for building efficient container images on fal. If you are new to custom containers on fal, start with Use a Custom Container Image for the core setup. For optimizing container images specifically for cold start performance (layer ordering, image size reduction, FlashPack), see Optimize Container Images.

Templates

Base Python

For applications that only need pip packages and basic system tools.

PyTorch and HuggingFace

For deep learning applications using PyTorch and the HuggingFace ecosystem.

Custom CUDA Version

When you need a specific CUDA runtime that differs from the fal base image.

Best Practices

Use the fal base image

falai/base:3.11-12.1.0 comes with the correct Python version, CUDA libraries, and a small image size that reduces container pull times during cold starts.

Pin all package versions

Unpinned versions can break your app when a new release introduces incompatibilities. Pin everything for reproducible builds.

Clean up package caches

Removing caches reduces image size, which speeds up container pulls during cold starts.

Use multi-stage builds for smaller images

Separate your build dependencies from your runtime to reduce the final image size.

Store model weights on /data, not in the image

Download model weights to persistent storage (/data) in your setup() method rather than baking them into the Docker image. This keeps your image small, speeds up container pulls, and allows weights to be cached across runner restarts.

Common Issues

Python binary not found

Problem: python: command not found when using a custom base image. Solution: Create symlinks so fal can find the Python binary:

CUDA not available

Problem: RuntimeError: No CUDA GPUs are available Solution: Ensure CUDA environment variables are set in your Dockerfile:

Dependency version conflicts

Problem: ImportError or version conflicts with pydantic, protobuf, or boto3. Solution: Install the fal package (or these three packages) as the last RUN pip install step in your Dockerfile so they override any conflicting versions installed by earlier layers.