requirements attribute and fal handles CUDA setup and environment isolation, so you do not need to write or maintain a Dockerfile. If you need system-level packages (like ffmpeg), a specific CUDA version, a non-Python runtime, or you are migrating an existing Docker-based server, the custom container path gives you full control over the build. Both approaches produce the same kind of runner and support all the same scaling, observability, and deployment features.
fal Runtime
For apps that only need pip packages, the managed runtime is the simplest setup. You define your pip dependencies in therequirements attribute of your app class and fal builds the container for you. This approach handles CUDA and PyTorch setup automatically based on your chosen machine type, so you do not need to manage base images or CUDA library versions.
app_files, local_python_modules, and git clone patterns.
See fal Runtime for the full guide including CUDA handling, extra index URLs, and best practices.
Custom Container
When you need full control over the environment, use a Dockerfile. This is the right choice when your app requires system packages, a specific base image, non-Python dependencies, or you are bringing an existing Docker image from another platform.Which Should I Use?
| Situation | Recommended |
|---|---|
| New Python model with pip packages | fal Runtime |
| Need system packages (ffmpeg, imagemagick) | Custom Container |
| Specific CUDA or PyTorch version | Custom Container |
| Migrating an existing Docker server | Custom Container + exposed_port |
| Non-Python runtime (Node.js, Go, etc.) | Custom Container |
| Local modules or git repositories | fal Runtime + Import Code |