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

Compute is part of the plan: each plan runs your apps on its own instance size, and the plan’s monthly fee covers it. A new app starts on its plan’s default instance, and upgrading moves your apps up automatically — there is nothing to resize by hand. Your app’s page in the dashboard shows the CPU and memory it has right now.

The figures are the most your app can use: CPU above it is throttled, and memory above it restarts the app with an out-of-memory error. On Pro, the larger sizes are set up on request — contact us with the app you want to move.

Request rate limit

Each instance also sets how many requests one visitor — one IP address — can make to your app, measured per minute with room for bursts:

The limit is per visitor, not per app: a popular app with many visitors is never throttled as a whole, and a page that loads dozens of images and scripts fits comfortably in the burst. What it stops is a single source flooding your app — most often a page that reloads itself in a loop, or a script calling an endpoint as fast as it can.

Requests over the limit are answered at the edge with 429 Too Many Requests. They never reach your app: they do not use its CPU, do not wake it if it is asleep and do not keep it awake. Everyone else keeps being served normally.

If your app is being rate limited, we tell you. When an app answers a few hundred 429s within an hour, the members of its project get an email — at most once a day per app — with the address involved (partly masked) and the paths it was requesting, which is usually enough to find the loop.

To limit one path or one client more tightly — a login form, a search endpoint, a crawler — add a limit rule to the firewall. Its 429s are yours, so they do not trigger this email.

[!TIP] Running a load test? A test from one machine is one visitor, so it will see 429s once it passes the limit — that is the limit working, not your app failing. Spread the test over several machines, or contact us before a large one.

If you put your own CDN or proxy in front of your app, the limit applies to each of its addresses. CDNs spread traffic over many addresses, so this rarely matters; tell us if it does.

Deployments per day (Free plan)

On the Free plan each project can promote up to 50 successful deployments per calendar day (UTC). Once the quota is spent, nothing is dropped: your latest push is queued and rolls out automatically at 00:00 UTC when the counter resets, or immediately if you upgrade. Hobby and Pro have no deployment limits.

Rapid pushes (Free plan)

On the Free plan, pushes to your deploy branch build at most once every 5 minutes per app. The first push deploys right away. Any pushes that arrive in the next 5 minutes are grouped: when the window closes, Faable builds only the latest commit, so nothing is lost and you don’t wait for builds of commits that are already outdated. On GitHub, the grouped commits show a grey neutral check that says they are batched. This is built for coding agents and scripts that push every few seconds. Hobby and Pro deploy every push immediately.

[!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:

On Hobby and Pro 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.

To keep an app running with no traffic, turn on Always on, or run a process with no web server as a background worker. Both are Hobby and Pro, from the Runs as row of the app page, and use the project’s compute hours: 365 GiB-hours a month on Hobby, 1,460 on Pro (memory × hours running; apps that sleep don’t count). To run a command on a timer instead, use scheduled tasks: 500 task minutes a month on Hobby, 2,000 on Pro.

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 per project 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.

Egress warnings on Free

On the Free plan, every project member gets an email when the project reaches 80 % and 90 % of its daily (1 GB) or monthly (10 GB) egress, and again at 100 %. The dashboard shows the same warning on your apps and on the Usage page. Days and months are counted in UTC.

Nothing is paused automatically. A Free project that keeps its traffic above the allowance may be paused; moving to Hobby brings it back.

Compute on Free

On Free you are expected to stay under 60 GiB-hours of compute a month, added up across the Free projects you belong to, so splitting apps into several projects does not change the total. A GiB-hour is one GiB of memory running for one hour. Every app counts while it is awake and nothing counts while it sleeps, so a single app on 128 MB that runs for 480 hours uses all 60. See it under Deploy → Usage in your project, by project and by app, along with egress.

We email whoever pays for the project when the total reaches 80 % and 100 %, once each per calendar month (UTC). Nothing stops at either one, and you are never charged. Usage at this level is beyond what Free covers, so apps of accounts that stay above it may sleep sooner or be paused. The count starts again on the first of each month.

If your app has to stay awake, that is what Always on on Hobby and Pro is for.

Related

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

Last updated on November 13, 2026