Deploy pricing

Faable Deploy is part of the unified Faable subscription. The platform fee and billing model are documented on the Pricing page — this page focuses on what each tier includes for Deploy specifically, plus the compute catalog and bandwidth allowances.

What each plan includes for Deploy

Docker and bring-your-own-image

Docker and Dockerfile builds — and deploying a prebuilt image — require a paid plan (Hobby or Pro).

On the Free plan, apps build with the three managed buildpacks:

A free-plan deploy that resolves to the Docker buildpack stops with Docker and Dockerfile builds — and deploying a prebuilt image — require a paid plan (Hobby or Pro). Nothing is wrong with your repository and there is no build log to read: the platform declines the build rather than running it.

Two ways forward:

• Deploy with a managed buildpack. Most projects that carry a Dockerfile also carry a package.json, a requirements.txt or a composer.json — and when both exist at the repository root, detection prefers the managed buildpack anyway, so those repos deploy on Free with no changes at all. A repository holding only a Dockerfile needs the matching manifest added. PHP is the exception: plain .php files are a fallback signal that a Dockerfile outranks, so a PHP repo shipping one must add a composer.json or remove the Dockerfile.
• Upgrade to Hobby or Pro. Your Dockerfile is then built verbatim with BuildKit, exactly as described in Dockerfile Projects.

[!NOTE] This is a plan entitlement, not a size or rate limit — the daily deployment quota is untouched by it, and a build declined this way never counts against it.

Compute catalog

Each deployed app is billed per month based on the instance size it requests. The bi.xs row is free on the Free plan (1 per project); all other sizes require Hobby or Pro.

Instances are billed per month.

Deployments per day (Free plan)

On the Free plan each project can promote up to 10 successful deployments per calendar day (UTC). Once the quota is spent, nothing is dropped: the build still runs to completion and the deployment waits, ready to roll out. It goes live automatically at 00:00 UTC when the counter resets, or immediately if you upgrade. Hobby and Pro have no deployment limits.

[!TIP] Only successful deployments count. A build that fails never touches the quota, so iterating on a broken build can’t lock you out for the rest of the day.

Sleep and always-on

An idle app scales to zero and starts again on the next real request — a cold start of a few seconds. Nothing is lost while it sleeps: the release, its environment and any attached volume stay exactly as they were.

How long an app has to be idle before that happens depends on the plan:

Hobby and Pro are always-on: an app that is being used never sleeps. There is no forced downtime and no daily rest window — as long as traffic keeps arriving, your app keeps running, around the clock. The two-hour window only ever applies to an app nobody is using, and the first request after it wakes it again.

Free is shorter by design: a free instance holds its CPU and memory reservation whether or not anyone is using it, so it is released sooner.

[!NOTE] Coming to the Free plan: a daily rest window. Free apps will be required to sleep for 4 hours out of every 24, including under traffic. This is not in effect yet — today a Free app sleeps only when it has been idle for 30 minutes — and we will announce the date before it applies. If your app has to answer around the clock, that is what Hobby is for.

External uptime monitors do not keep a Free app awake. A ping from a monitoring service (Uptime Kuma, UptimeRobot, Pingdom, StatusCake, Better Stack, Site24x7 and similar) is answered by the platform on the app’s behalf, so it never starts the instance:

• 200 while your latest release is healthy — the app is asleep and will start on real traffic.
• 503 when the platform knows the app is broken: the promoted deployment failed, or the app has no release yet.

Responses carry an X-Faable-Probe header (sleeping or unhealthy) so you can tell them apart from your app’s own answers. Your monitor therefore keeps catching the failures that matter on a Free app — a broken release, an app that never deployed — but it does not see errors your code returns while asleep. If you need a monitor to reach the app itself on every check, upgrade to Hobby or Pro: a monitored app is an app under traffic, and on those plans it stays up.

Build artifact size

When Faable builds your app it produces a build artifact — a compressed archive holding your application plus its installed dependencies — and your instances boot from it. The size of that archive is capped per plan:

If a build produces something larger, the deploy stops with an artifact_too_large error naming the size it reached and the limit it passed. The build itself is not charged against your daily deployment quota.

Most apps are far below these numbers — a typical Node or Python service lands in the tens of megabytes. Artifacts get large when something ships inside the repository that does not need to: bundled media and datasets, checked-in build caches, or development dependencies installed in the production image. Trimming those is usually enough to get back under the limit; if your app genuinely needs more, upgrade the plan.

[!NOTE] 2 GB is also the platform maximum, so it is the ceiling on every plan. Builds above it are not supported on the artifact runtime.

Bandwidth

Egress is included per plan, counted monthly across all of your instances.

Ingress is unlimited and free on every plan.

[!NOTE] Only Pro bills for traffic. Free and Hobby are flat: their allowance is what the tier includes, and there is no per-GB line that can grow on an invoice you did not agree to. If a project consistently serves more than its allowance, that is the signal to move up a tier — Pro is the plan built to meter and bill traffic.

The Bandwidth column in the instance catalog above describes the network capacity of each instance size. It is not a separate billing allowance: what you are billed against is your plan’s monthly figure in the table here.

Related

• Platform pricing — tiers, platform fee, billing model.
• Auth pricing — MAU allowances and identity-feature gating.

Last updated on September 15, 2026