fal Release Notes

App-Level Retry Configuration

Apps can now register a default per-condition retry budget at deploy time with the new retry_config deployment option, using the same format as the X-Fal-Retry-Config request header.

Set it as a class attribute on fal.App or under the app’s table in pyproject.toml.

Applies to all queue-based requests to the app; the app owner can still override it per-request with the X-Fal-Retry-Config header.

Each condition (server_error, timeout, connection_error) keeps an independent budget, bounded by the platform ceiling of 10 total attempts.

See Retries and Error Handling for details.

New Serverless Usage Page

The new Serverless Usage page (Serverless → Usage) provides attributable, dimensioned reporting of serverless compute spend in the dashboard.

Compute reported in machine-seconds , broken down per app, environment, and machine type.

Spend is split by price category: Reserve, Burst, On-Demand, and List. This distinguishes consumption covered by committed reserved capacity from burst overage and undiscounted list-rate usage, supporting reservation sizing and workload placement decisions.

Group by app or by machine type , including a dedicated Usage by machine type view, to identify the deployments and hardware classes driving cost.

Billing-cycle and custom time-range presets are supported. On-demand quotes are reported as a distinct price category, and organization-level reporting now spans both serverless and compute.

This is the same dataset returned by the GET /v1/serverless/usage API, surfaced in the dashboard.

Deploy Existing Docker Servers Without Code Changes

Existing Docker-based servers (ComfyUI, custom APIs) can now be deployed without rewriting them as a fal.App, reducing migration effort from self-hosted infrastructure, Kubernetes, or RunPod.

• Direct Server Mode: set exposed_port in pyproject.toml and fal routes traffic directly to the container port. Existing routes, middleware, and response formats are preserved.
• Prebuilt image references (no Dockerfile required): reference an image already pushed to a registry (image = "my-org/my-server:latest") and override entrypoint / cmd under [tool.fal.apps..image].
• Private registry support: pull from Docker Hub, Google Artifact Registry, or Amazon ECR by supplying registry credentials in the image configuration.

Migration guides are available for external Docker servers and RunPod, along with the pyproject.toml reference and Private Docker Registries.

Serverless Usage API

New GET /v1/serverless/usage endpoint reports your own serverless compute usage — the machine-seconds each of your deployed apps consumed, priced with your machine rates and net of discounts

Break usage down per app, environment, and machine type, with time_series and summary views over any date range and timeframe

Filter by app name with app (exact, one or more) or search (case-insensitive substring) — match a deployed app by name without needing its exact version suffix

Ideal for per-app cost reporting and exporting to your own billing/observability tools

Complements the per-request billable_units on GET /v1/serverless/requests/by-endpoint with an aggregated, time-bucketed view

New Capacity Page

The new Capacity page (Serverless → Capacity) reports GPU consumption against your account limit, providing visibility into available headroom before requests begin queuing.

• Account-wide GPU usage over time, plotted against your limit , with baseline and burst reference lines indicating utilization relative to reserved capacity.
• Per-GPU-type breakdown of capacity consumption by hardware class.
• Approaching-limit and at-limit indicators on runner and app views, with GPU counts shown on runners.
• Request more capacity action for requesting a higher limit.

Per-Condition Retry Configuration

The new X-Fal-Retry-Config request header replaces all-or-nothing retry behavior with a separate retry budget per failure condition, allowing retry policy to be tuned independently for each failure mode.

• Map each retry condition (server_error, timeout, connection_error) to its own retries count (for example, retry transient server errors while disabling retries on timeouts).
• Each condition maintains an independent budget, bounded by the platform ceiling of 10 total attempts.
• Applies to apps you own and takes precedence over status-code defaults. x-fal-no-retry takes precedence when both are set.
• Complements app-level skip_retry_conditions and the per-response X-Fal-Needs-Retry and x-fal-stop-runner controls.

See Retries and Error Handling for the full reference.

Filter and Sort Apps

Managing a large number of serverless apps is now easier with new filtering and sorting controls directly on the apps page.

• Filter by machine type to instantly isolate apps running on specific hardware (e.g., H100, A100, L40) and monitor targeted resource allocation.
• Sort by active runners, GPUs, or queue size to instantly surface the apps consuming the most capacity or backing up with queued requests.

Works in both card view and list view, and stacks with environment and tag filtering so you can find what needs your attention faster.

The runner termination grace period is now configurable, allowing long-running requests to drain and teardown() to complete before SIGKILL, which reduces the risk of dropped work or inconsistent state during scale-down.

The grace period is a shared budget for completing in-flight requests and running teardown(). Use handle_exit() to signal long requests to stop early so cleanup is not skipped.

• termination_grace_period_seconds is configurable up to 1 hour (previously capped at 30 seconds, default 5 seconds).
• The grace period is a shared budget for completing in-flight requests and running teardown(). Use handle_exit() to signal long requests to stop early so cleanup is not skipped.
• keep_alive now applies to both idle-after-request and never-served runners.

See Scale Your Application for details.

The Serverless apps page now opens with an aggregate analytics dashboard that summarizes capacity, traffic, and per-app activity across every app you own in one place.

• GPU and CPU distribution charts visualize how your active runners are split across machine types (H100, A100, L40, B200, CPU types, etc.)
• Live capacity tiles show total Active Runners, Queued Requests, GPUs, and CPUs, each annotated with how many apps contribute to the number
• Status code, request traffic, and concurrent request charts plot aggregate request health over your selected window
• Top Apps lists your highest-volume apps over the window for quick drill-in
• Requests by app is a new stacked chart that breaks aggregate traffic down per app, with a searchable legend you can click to isolate a single app or flip to an Errors view

We introduced new aggregate analytics components on serverless app surfaces to keep health signals consistent between the app listing and each app header.

• Shared metrics components now power Runners, Reqs/min, Latency, and Errors in both app cards and app detail headers
• Reqs/min, latency, and error trends are shown with directional indicators using recent activity windows, so regressions stand out at a glance
• App headers now pair those analytics signals with a queue metric, giving a compact operational snapshot before drilling into detailed analytics tabs

Legacy CDN Cleanup — June 1st, 2026

On June 1st, 2026, any legacy CDN object not accessed in the past 6 months will be deleted.

How to identify legacy objects

Legacy URLs look like /files/[animal]/[filename] (e.g. /files/otter/AFsfdoliuhhvf.mp4). Anything served from /files/b/... is on our current CDN and is unaffected.

If you’ve accessed it recently, it’s already safe: Any legacy object accessed in the last 6 months has already been automatically migrated to our current CDN — no action needed on your end. The URL is unchanged and the object will be preserved.

To keep a legacy object you haven’t touched in a while: Access it once before June 1st, 2026. That single access triggers the automatic migration and preserves the object. The URL stays the same.

What stays the same

• Legacy URLs continue to work — no code changes needed
• Anything new you create already uses the modern CDN (/files/b/...)

Run ComfyUI workflows on fal serverless GPUs without writing a single line of code. Two pre-built zip packages, one double-click 12 your team is generating on H100s in minutes.

• User package 12 a tiny launcher UI on localhost:9998. Paste your fal API key and the endpoint slug your team lead gave you, click Start, and the full ComfyUI canvas opens on localhost:8188 running against the cloud GPU.
• Admin package 12 a complete management UI on localhost:9999. Add models, custom nodes, and Python deps from a table, set HuggingFace / Civitai tokens for gated weights (auto-pushed to fal secrets at deploy), and ship with one click. Live runner observability, an outputs gallery, and an undeploy switch are built in.

The launcher auto-installs uv and Python 3.11 on first run 12 no Python knowledge required from end users. Works on macOS and Windows.

Diagnose why a runner was terminated directly from the dashboard. The reason now appears across every runner surface.

• Runner detail page termination reason is shown inline next to the state.
• Runner list surfaces the same reason via a tooltip on the state badge, so you can scan failures without opening each runner
• Runner events timeline event rows display the termination reason as a highlighted badge alongside the status text

Please note that in some cases the termination reason may be unknown. When that happens, no reason badge or tooltip is shown.