Pricing by Service

This page gives the exact points formula for every marketplace service, the factors you choose when you create or resize a resource, and one worked example each. It builds on Points & Plans — read that first for how points behave: creating a resource reserves its cost against your plan budget, deleting refunds it, and resizing reserves or refunds only the difference.

Apps

An app’s cost is its compute tier multiplied by how many replicas it runs:

cost = app tier points × replicas   (replicas ≥ 1)

Factors you choose

• Compute tier — a small-to-large ladder (a, b, c, d) of reserved CPU and memory. A larger tier costs more points.
• Replicas — how many identical copies run behind the app. Each replica holds its own CPU and memory, so replicas multiply the cost. At least one replica is required: you can’t create or resize an app below a single replica.

Your plan also sets a maximum app tier. Tiers above it are unavailable regardless of how many points you have left — that guardrail protects the platform and is separate from your budget.

What’s included in each tier (not priced separately)

• A maximum image size — the size of your built container image.
• An ephemeral-disk allowance — scratch working space that resets when the pod restarts. Exceed it and the pod is evicted. It is working space, never durable storage.

Apps have no persistent disk — ever. Anything that must survive a restart or redeploy — uploads, generated files, caches you can’t lose — belongs in object storage, not on the app. That is also why an oversized image is rejected at deploy time: if your built image is larger than your tier’s maximum image size, the deploy fails with an error explaining that large or persistent files should go to object storage rather than being baked into the image. To fix it, move that data to object storage or pick a tier with a larger image allowance.

Example. The smallest app tier, a (500m CPU / 512 MiB), reserves 3 points at one replica. Run it at 3 replicas and it reserves 9 points (3 × 3); scale it back to one replica and 6 of those points return to your budget.

Databases

A managed database prices its compute, its disk, and its backup schedule as three independent terms:

cost = compute tier points                                   (compute)
     + ceil(disk GB ÷ disk block GB) × disk block points     (disk)
     + backup add-on                                          (see Backups below)

Factors you choose

• Engine — PostgreSQL, MongoDB or Valkey. The engine does not change the price: the same tier, disk, and backup schedule cost the same whichever you pick. MongoDB needs tier m or above; Valkey runs on every tier, xs included.
• Compute tier — a ladder (xs, s, m, l, xl) of reserved CPU and memory. As with apps, your plan sets a maximum database tier.
• Disk GB — bought in fixed-size blocks (see below).
• Backup schedule — see Backups.

Pure separation: the tier buys compute only. A database’s compute tier reserves CPU and memory and zero disk. Even the first gigabyte is bought as disk blocks, kept as a separate term so compute and storage price independently. The dashboard pre-selects a sensible default disk size so you’re not starting from nothing.

Disk is sold per block, and the price rounds up: a partial block costs a whole block. Database disk is fast, backed-up local storage, so its per-GB rate is higher than object storage — reach for object storage when you just need cheap capacity.

Backups

Every database includes weekly backups (keep 4) at no points cost — that is baked into the database price. More frequent schedules cost extra, and because snapshots are real stored bytes, the add-on scales with the database’s disk size:

weekly, keep 4       = included free
daily, keep 7        = 1 × ceil(disk GB ÷ backup block GB)
every 6 h, keep 28   = 3 × ceil(disk GB ÷ backup block GB)

If the disk is smaller than one backup block, the add-on is just the multiplier (1 for daily, 3 for every-6-hours).

Example. Create an xs PostgreSQL with 12 GB of disk and daily backups (keep 7), with the 10 GB backup block:

Total: 2 + 12 + 2 = 16 points. The disk block is a separate knob from the backup block (disk is 1 point per GB), so don’t reuse the backup block’s size when you work out the disk term.

A Valkey on xs with the same disk and backups costs the same 16 points. MongoDB is not offered on xs: it starts at tier m, where it costs exactly what a PostgreSQL on m does. Switching the backup schedule to every 6 hours (keep 28) would make the backup term 3 × ceil(12 ÷ 10) = 6 points instead.

Object storage

Each bucket carries its own quota, but object-storage points are charged on the block-rounded project total — the sum of every bucket’s quota, bought in blocks:

cost = ceil( (sum of every bucket's quota GB) ÷ block GB ) × block points

Factors you choose

• Per-bucket quota GB — you size each bucket’s quota with ghayma storage create --quota-gb <gb>; there is no single project-wide quota input. Points are charged on the block-rounded project total, though — the sum of every bucket’s quota, rounded up to a whole block. Buckets therefore share one pooled cost basis: two half-block buckets round up together on the sum, not each on its own. As with database disk, a partial block rounds up to a whole block.

Object storage is the cheapest per-GB capacity in the marketplace — it’s where your bulky and persistent files belong, including everything your apps can’t keep on disk. Egress (data your users download) is not points: it counts against your plan’s separate bandwidth allowance and is metered there.

Bandwidth — and the compute usage a pay-as-you-go project is billed on — is counted per project: every site in the project, the main site and any additional sites, is summed into the project’s usage.

Example. With the 10 GB block = 1 point, two buckets sized 15 GB and 10 GB sum to a 25 GB project total, which rounds up to ceil(25 ÷ 10) = 3 blocks = 3 points. The sum is rounded once, not each bucket on its own. Downloads from those buckets don’t touch your points — they draw down your plan’s bandwidth cap instead.

Auth

An auth service prices a user-capacity bracket, plus an optional 2FA add-on:

cost = bracket points
     + (2FA on ? flat 2FA points : 0)

Factors you choose

• Capacity bracket — the maximum number of registered users the service can hold (1k / 10k / 100k / 1M, at 1 / 3 / 6 / 12 points). When you reach the cap, new signups pause: registering the next user is rejected until you move to a larger bracket. Everyone already registered is unaffected — existing users always log in.
• 2FA (authenticator-app codes) — a flat add-on. It costs the same small amount no matter how many users enable it, because verifying codes is pure compute.

Example. A 1k-user auth service with 2FA on:

So the total is 1 + 1 = 2 points, no matter how many of those users actually enrol in 2FA.