Dora NodaOn August 31, 2026, Appwrite merged a billing fix with an embarrassing confession inside it. After moving function and site builds onto a new jobs-service backend, the average billed duration of a failed build had climbed from 111 seconds in June to 491 seconds in August — while successful builds held steady at about 52 seconds. Failed builds, most of which never ran a single line, had grown to 57% of all billed build compute across the entire Appwrite Cloud fleet.
One production project told the story in miniature: 2,286 of its 2,311 failed August builds had no start timestamp, empty logs, and an exit code of -1. Each was billed roughly a full GB-hour for queue wait. That project paid for 1,878 GB-hours of build compute in August, and 1,869 of them were builds that never ran.
Read that again, because it reframes everything below: Appwrite bills builds as metered compute, failed builds bill exactly like successful ones, and for most of a quarter the meter was quietly charging teams for builds stuck in a queue. The fix capped billed duration at the build timeout. The follow-up — billing zero for builds that never started — was still pending.
That is meter number one. Meter number two is quieter and harder to dodge: every deployment you keep counts against your plan's storage allowance. In May 2026, Appwrite announced deployment retention for Functions and Sites, and the rationale was stated plainly: "Deployment artifacts count toward your project's overall storage allowance on Appwrite Cloud. Retention reclaims that space automatically, so unused builds stop pushing you toward additional storage overage." Every retained build is a recurring storage charge. Ship often, keep history, and your build artifacts compete for gigabytes with your users' files.
The topline, before the workings: a typical three-person team deploying about 10 times a day burns roughly a dozen GB-hours of build compute a month and — on a 90-day retention window — carries around 70 GB of retained build artifacts, nearly half of a Pro plan's 150 GB storage allowance, before storing a single user file. The same history on a self-hosted box costs effectively nothing beyond the VM already running the project: builds consume your own CPU time, artifacts sit on disk you already rent.
The full math, with sensitivity from 2 to 30 deploys a day, is three sections down. The rest of this post is how the two meters work, who they punish most, and what to set before your deploy cadence becomes a budget line.
Meter one: every build is GB-hours, pass or fail
Appwrite's usage pipeline records each build's compute as memory × duration × CPUs, billed in GB-hours on sized runners (the August incident report names the s-2vcpu-2gb class explicitly). Three properties of this meter matter more than the unit:
- Failed builds bill the same as successful ones. The merge message for the August 31 fix states it outright: billed duration "is billed for 'failed' exactly as for 'ready'." A red build costs the same as a green one of equal length.
- Queue wait used to bill as build time. The old executor measured wall-clock around the build's own execution, so queue wait was structurally unbillable. The jobs-service backend stamped the start time on the first log line — and a build that never streamed a line fell back to the deployment's creation time, billing its entire queue wait. That is how 904 seconds of waiting became 904 seconds of "build."
- The ceiling is the timeout, which is generous. The fix clamps billed duration at the build timeout — but Appwrite raised that timeout from 15 to 45 minutes for Pro plans in April 2026. A starved build still bills the full timeout, and the fix's own message admits as much.
None of this is malice; it is the ordinary shape of usage-based build billing. But notice the direction of every error term: failures bill, waiting billed, the cap is 45 minutes. Every imprecision in the pipeline points the customer's way.
Meter two: every deployment you keep rents storage by the month
Builds are the flow; retained deployments are the stock. Each Function or Site deployment leaves behind artifacts — the built bundle, the image layers, the metadata — and Appwrite counts all of it toward the project's storage allowance: 2 GB on Free, 150 GB on Pro (per Appwrite's Pro announcement), 500 GB on Scale. Past the allowance, it is overage.
The May retention announcement is unusually candid about who this bites. "For teams using Git-based deploys, preview deployments, frequent rebuilds, or short-lived feature branches, that footprint adds up quickly and can push you into additional storage charges for builds you would never roll back to." Preview-per-PR workflows are the worst case on purpose: each pull request mints a deployment with real artifact weight and near-zero rollback value, and without a retention window every one of them rents space indefinitely.
The controls are straightforward. In the Console, each Function or Site has Settings → Deployment retention, with presets of 1 week, 1 month, 6 months, or 1 year; the API and Server SDKs expose the same knob as deploymentRetention, any value from 1 to 36500 days, or 0 to keep non-active deployments forever. The active deployment is always protected. What Appwrite does not do is pick a default for you — retention is a setting you must go set, per function, per site, while the meter runs.
You can watch both meters in the usage API and Console. Four metric families cover the build footprint:
| Metric | What it counts | Why it matters |
|---|---|---|
builds | Build count per period | Volume knob: deploys × previews × retries |
buildsTime | Total billed build duration | The GB-hour meter's time factor |
buildsStorage | Build working/storage footprint | Scratch space per build |
deploymentsStorage | Retained deployment artifacts | The stock that rents allowance monthly |
The worked example: what 10 deploys a day actually costs
Assumptions, stated so you can substitute your own: a three-person team, 10 deployments a day across Functions and Sites (production plus previews), 30 days a month, 85% of builds succeeding at the fleet mean of ~52 seconds and 15% failing at an assumed ~3 minutes, on a 2 GB runner class. Average retained artifact weight 80 MB per deployment (a blend of small function bundles and heavier site builds), held on a 90-day retention window.
Build compute. Monthly builds: 300. Successful: 255 × 52s ≈ 3.7 hours. Failed: 45 × 180s ≈ 2.25 hours. Total ≈ 5.9 runner-hours × 2 GB ≈ 12 GB-hours a month, before any CPU multiplier in Appwrite's formula. Push the failure rate to 30% during a rough migration month and the same deploy count costs ~15 GB-hours — the red builds charge rent too.
Retained storage. Each month mints 300 deployments × 80 MB ≈ 24 GB. A 90-day window holds three months of history: ≈ 72 GB standing, or nearly half the Pro plan's 150 GB allowance — consumed by builds the team will almost certainly never roll back to, before a single row, document, or user upload is counted. Shorten retention to 30 days and the standing footprint drops to ~24 GB; keep-everything-forever (retention 0) grows it without bound.
Now the sensitivity table — same team, same assumptions, varying only cadence and workflow shape. Cloud columns are metered units consumed; the self-hosted column is the marginal cost of the identical history on the project's existing box:
| Deploys/day | Cloud build compute | Cloud retained artifacts (90-day) | Self-hosted marginal | Delta |
|---|---|---|---|---|
| 2 (side project) | ~2.4 GB-hours/mo | ~14 GB standing | ~€0 (own CPU + disk) | Small in units, but 14 GB is 7× the entire Free allowance — a hobby project on Free is in overage-or-prune territory from builds alone |
| 10 (typical team) | ~12 GB-hours/mo | ~72 GB standing | ~€0 (own CPU + disk) | ~Half the Pro storage allowance spent on history; every deploy adds metered units on Cloud, ~zero marginal cost self-hosted |
| 30 (preview-heavy monorepo) | ~36 GB-hours/mo | ~216 GB standing | ~€0 (own CPU + disk) | Retained artifacts alone exceed the whole Pro allowance — overage, aggressive retention, or a bigger plan, chosen under billing pressure |
| 10, production-only (no previews) | ~7 GB-hours/mo | ~40 GB standing | ~€0 (own CPU + disk) | Previews roughly double both meters for near-zero rollback value — the most expensive builds are the ones nobody would ever restore |
Two notes on fairness. First, self-hosted disk is not infinite either — 216 GB of history fills a small VM disk just as surely as an allowance. The difference is the mechanism: on your own box you buy cheap disk once and prune on your schedule, with no per-GB meter running and no feature (uploads, functions) at risk when a threshold trips. Second, Appwrite has shipped mitigations on the compute side, including cache-key support for builds to cut rebuild time. Use them. They shrink the flow; they do not change the fact that the stock is metered.
Why this taxes exactly the teams with the healthiest habits
Step back and look at the incentive gradient. Everything the industry spent a decade teaching teams — deploy small, deploy often, preview every pull request, keep history for debugging and rollback — increases both meters. The team deploying twice a month from a laptop pays nearly nothing for builds. The team with CI on every PR, preview environments per branch, and a 90-day rollback window pays the most. Build-artifact metering is a tax whose rate rises with deploy hygiene.
And it arrives as part of a pattern, not an accident. In April 2026, Appwrite began enforcing Realtime usage limits and billing — monthly message caps, concurrent-connection caps, message-size caps, with overage pricing attached (website PR #2825). Each previously-unmetered dimension becomes a line item in turn: first bandwidth, executions, and storage; then realtime messages; now build compute and retained artifacts with retention tooling to manage them. This is the standard hosted-platform lifecycle — generous flat beginnings, metered maturity — and no individual step is unreasonable. The cumulative effect is a bill that grows line by line while the self-hosted alternative stays flat.
The teams hurt most are easy to name: preview-per-PR Git workflows where each branch mints artifact weight with no rollback value; agencies and freelancers running many small projects whose build histories add up across projects; and anyone mid-migration, when failure rates spike and every red build bills like a green one. If that is you, the next section is the actionable part.
What to do before your deploy cadence becomes a budget line
1. Set retention windows now, per resource. Open every Function and Site, go to Settings → Deployment retention, and pick a window that matches the resource's rollback reality — 30 days for preview-heavy sites, 90 for production functions, forever (0) only where compliance demands it. The same setting is available as deploymentRetention in the create/update endpoints, so encode it in your IaC or provisioning scripts rather than clicking through the Console every time a service is born. This is the single highest-leverage change: it converts unbounded stock growth into a bounded one.
2. Watch the four build metrics, not just the invoice. Console → Usage exposes builds, build time, and deployment storage trending over time. A sudden climb in deploymentsStorage after enabling Git previews, or a buildsTime spike during a flaky-dependency week, is visible weeks before it becomes overage. Set budget alerts if your plan supports them; the meter that surprises you is the one you never graphed.
3. Price the self-hosted alternative honestly. Appwrite is open source and, per its own docs, designed for self-hosting with the same features as Cloud — installable anywhere Docker runs, which in practice means a single small VM. On that box, the entire worked example above — 300 builds, 72 GB of history — costs whatever the VM already costs (a small cloud instance runs single-digit euros a month with tens of GB of NVMe) plus effectively zero marginal: builds burn your own CPU time instead of GB-hours, artifacts occupy your own disk instead of allowance.
The honest costs of self-hosting are operational, not per-unit: you own updates, backups, and scaling. For a team whose Cloud bill is dominated by build meters that scale with how often they ship, that trade increasingly favors the box — because the box never learns to charge you for deploying.
The broader lesson generalizes past Appwrite. Every hosted platform eventually meters its build path — minutes, concurrency, cache, artifacts — because builds are compute and storage the vendor pays for. The question is never whether the meter arrives; it is whether your deploy cadence is an asset or a liability when it does. Own the machine, and shipping ten times a day is pure upside. Rent the meter, and every green build carries a small invoice with it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
