> ## Documentation Index > Fetch the complete documentation index at: https://fal.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Deployment Overview > Ship your fal applications to production, manage revisions and environments, configure scaling, and choose the right machine type. Deployment is where your [fal App](/documentation/development/app-lifecycle) goes from local development to a production API that serves real traffic. When you run `fal deploy`, fal builds your code into a container image, pushes it to a registry, and makes it available at a permanent endpoint ID. From that point, [runners](/documentation/deployment/runners) spin up on demand to handle requests, scale automatically based on traffic, and shut down when idle. You can roll back to any previous version instantly, deploy to separate [environments](/documentation/deployment/manage-environments) for staging and production, and tune [scaling parameters](/documentation/deployment/scale-your-application) without redeploying. Before diving into this section, make sure you have [installed the CLI](/documentation/development/getting-started/installation) and built your app following the [Development](/documentation/serverless/index) guides. The pages here cover everything after your code is written: understanding what runners are, deploying to production, managing versions and environments, choosing hardware, and configuring scaling. If you are migrating from another platform, the [migration guides](/documentation/development/migrate-external-docker-server) can help you get started faster. ## Quick Start The simplest deployment is a single command: ```bash theme={null} fal deploy path/to/myapp.py::MyApp ``` This builds your app remotely, creates a persistent deployment, and gives you an endpoint ID like `your-username/my-model` that callers use with the [fal client SDKs](/documentation/model-apis/inference). ## Runners and Requests Before deploying, it helps to understand the execution model. When a caller submits a request, it enters a persistent queue and is dispatched to a runner. Runners are compute instances that pull your container image, run `setup()`, and serve requests until they scale down. Understanding how requests flow through the queue and how runners start, process, and shut down is essential for debugging latency, configuring scaling, and managing costs. Request lifecycle, retry interaction, and platform architecture diagram Runner lifecycle states, startup, shutdown, and scaling behavior How Docker layers, model weights, and compiled artifacts are cached across runners ## Deploying and Managing Deployment creates a versioned revision of your app. Each deploy creates a new revision, so you can roll back to any previous version instantly if something goes wrong. You choose a rollout strategy (recreate for speed, rolling for zero downtime), configure authentication (private, public, or shared billing), and optionally deploy to separate environments for staging and production. Build, configure, and ship your app with rollout strategies and auth modes List, update, and delete deployed apps Switch between revisions or restart runners with rollouts Isolate staging and production with separate secrets and config ## Scaling and Hardware Once deployed, you control how your app scales. Scaling parameters determine how many runners stay warm, how quickly new ones spin up, and how many requests each runner handles concurrently. Machine types determine the hardware backing each runner, from lightweight CPU instances to H200 and B200 GPUs. Configure concurrency, keep-alive, multiplexing, and scaling delays Set parameters via code, CLI, or dashboard, and understand --reset-scale Choose from CPU and GPU hardware based on memory, compute, and VRAM needs