> ## Documentation Index > Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt > Use this file to discover all available pages before exploring further. # Billing > Understand what you are charged for, and what happens when the balance hits zero. slipway bills in plain dollars. There is no abstract unit to convert: your balance is a dollar figure, compute is metered by the second, and running workloads draw from the balance while they run. ## Billing email Invoices, receipts and payment failures go to the workspace's billing email, set under **Settings → Billing**. Changing it requires the admin or owner role. It starts as the address of whoever created the workspace, and stays there. Transferring ownership does not move it, so handing a workspace to a colleague does not redirect its invoices, and someone leaving does not take the billing mail with them. Point it at your finance inbox if that is not the same person. ## Where your balance comes from | Source | Behaviour | | - | - | | Monthly allowance | Paid plans include a set dollar amount of usage per period for the whole workspace. It resets each period and does not roll over. | | Top-ups | Add any amount from \$10 at any time. A top-up is a single payment, not a subscription, and topped-up balance never expires. | | Signup grant | A new organization gets a one-time \$5 grant, with no card. This is the trial: there is no clock, only balance to spend. | | Promo credit | Usually lands in the balance that never expires, so it survives the monthly reset. A code can instead grant credit with a lifetime, and you are told which before you redeem it. | When you spend, the monthly allowance goes first. Topped-up balance is only touched once the allowance is gone, so an unused allowance never causes money you paid for to expire alongside it. ### Promo codes Enter a code on the plan picker if your workspace lands there, or under **Settings → Billing** once it is on a plan. What a code is worth depends on the plan, and the picker shows the amount on each plan's card before you commit. Some codes do not apply to every plan, and the card says so rather than ignoring the code. A code can be used once per account and once per workspace. Codes are entered in slipway, never in Stripe's checkout. If you enter one before paying, it is applied as soon as your subscription lands. Every code has a shareable claim page at `console.slipway.sh/claim/CODE` — it shows what the code grants and signs new users up with the code applied. Already have a workspace? Codes can also be redeemed under Settings → Billing (owners only). Some codes include a plan. Redeeming one puts the workspace on that plan directly — no card, no subscription — and adds the code's credit to your balance. To keep the plan permanently, subscribe to it from Settings → Billing → Change plan. A workspace that already pays keeps its subscription and gets the code's credit only. Other codes start a **free trial** of a plan instead. The claim page and the plan picker say so, and the difference is the card: a trial code asks for one up front, starts a real subscription, and charges nothing until the trial ends. On that date the plan simply starts billing, with no further step. Cancel from Settings → Billing before then and the card is never charged. The code's credit lands in your balance the moment the trial starts. A workspace that already pays cannot start a trial; it gets the code's credit only. #### When an included plan, trial or credit runs out An included plan lasts either for as long as your balance does, or for a set number of days. Settings → Billing says which, and shows the date when there is one. A week before that date we email you and put a notice in your inbox. On the day, the workspace moves to the free plan. Nothing is deleted and no project is torn down: the free plan's limits apply from each project's next deployment. Subscribing before the date keeps everything as it is. A trial ends differently: nothing moves and nothing is lost, the card on file is charged for the plan from that date on. We email you three days beforehand. Credit with a lifetime works the same way. It is spent before anything you have paid for, so everything you run until the date comes out of it first, and only the unused remainder is returned. You get the same week's warning before that happens. Where there is no plan deadline, access lasts as long as the balance does: at zero your projects pause (nothing is deleted), and topping up or subscribing brings everything back. ## What costs money | What | Rate | | - | - | | CPU | \$8.76 per vCPU per month | | Memory | \$4.38 per GiB per month | | Disk | \$0.25 per GiB per month | | Volume backups | \$0.05 per GiB per month | | Object storage | \$0.05 per GiB per month | | Egress beyond the plan allowance | \$0.01 per GB | Compute is metered by the second against the allocation a service is configured with, so a service that sleeps costs nothing while it is asleep. Disk, backups and object storage are metered on what is provisioned or held, whether or not the service is running. **Metered** | Item | Basis | | - | - | | Web, worker and database services | The configured CPU and memory, per second, per replica, while running | | Builds | The build machine's CPU and memory, per second, for the length of the build. Static site builds are free | | Cron services | The CPU and memory of each run, per second, for the length of the run | | Disks | Provisioned GiB, per hour, whether or not the service is running | | Volume backups | Stored GiB, per hour | | Object storage | Stored GiB, per hour | | Egress | Per GB beyond the plan allowance, on every byte served through the edge, WebSockets included | **Not metered** * Static sites, including their builds. They are served from the CDN edge with no container behind them, so there is no compute allocation to charge for. You are metered on egress only. * A sleeping service. Sleep scales it to zero replicas, and a service with no replicas accrues no compute. * A paused service, for the same reason. * Inbound traffic. * Deployment history, logs and metrics, within your plan's retention window. * Secrets, variables, projects, previews and org members in themselves. A preview costs what its services cost while they run. Compute prices are quoted per month for an always-on service and metered to the second. The per-minute rate is the monthly figure divided by 43,800, the minutes in an average month. A 1 vCPU and 1 GiB service is \$13.14 a month always-on, and a pod that ran for two minutes costs two minutes. There is no minimum increment, so a job that ran for four seconds is charged four seconds. Every kind of service pays the same rates: web, internal, workers, cron and databases alike. See [CPU and memory](/services/compute). ### Reserved, not measured Compute is billed on the allocation you **configured**, for as long as the pod is scheduled, rather than on measured utilisation. That is what the cluster genuinely holds for you, and it means the estimate you see before deploying is the figure you are charged. Storage follows the same principle: a disk is billed on its **provisioned** size, so a 20 GiB disk bills for 20 GiB whether it holds 3 GiB or 19 GiB. The figure only moves when you create, resize or delete a disk. Each disk's actual usage is on the service's Metrics tab. Backups and object storage are the exception and bill on real bytes, because a backup is a deduplicated incremental with no provisioned size and a bucket holds exactly what you upload. ### Monthly minimums The platform may set a minimum monthly charge per service type. Where one applies, a service that ran at all during a month is charged at least that minimum, topped up at the end of the period. It applies per service, per project, so a service that changed allocation mid-month owes one floor rather than one per shape. The default is no minimum. The usage page shows it as **Monthly minimums**, with what you would owe if the period ended today, folded into the projection. That number only shrinks, because floors are flat rather than prorated. ### Egress Every plan includes an allowance, and most projects never reach it. Past the allowance, outbound traffic is \$0.01 per GB at the same rate on every plan. Egress is everything served through the edge: ordinary HTTP responses and WebSocket or other streaming connections alike. Two kinds of traffic never count against the allowance or the overage: traffic between siblings inside a project, which never leaves the cluster, and anything served from the CDN cache, which never reaches your service. ## Watching your balance **Settings → Usage** shows your credits, meaning the monthly allowance and any topped-up balance as one figure, alongside the current burn rate, storage, egress, seats, and the **runway**: roughly how long the credits last at the rate you are spending them. Runway is the number worth watching, because a balance on its own does not say whether you have two days or two months. **Charges this period** breaks the spend down by project. Expand one to see every service it ran, the allocation it ran at, how long it was scheduled, and what that came to. A disk is listed under the service that mounts it, since that is what it belongs to. A disk shared by more than one service, or mounted by none, has no single owner to sit under and is listed against the project instead. A service resized mid-period appears once per shape, so you can see what each cost rather than having the old allocation's hours relabelled. A project or service deleted mid-period is tagged **deleted**, since its charges are real and stay listed. Cron services are marked **per run**. You are emailed once when the balance runs low, and not again until it recovers past the figure that triggered the warning. On plans with a monthly allowance, "low" means 20% of that allowance; on plans without one — the free tier, or a workspace running on topped-up balance — it means an absolute floor of $5 (halved to $2.50 on the free tier, so a fresh signup isn't warned about the grant it just received). You can set your own threshold, or turn the email off, under **Settings → Spend limits**. The sidebar shows credits and runway on every page. ## Running out At zero: * Running projects are scaled to zero. * Every project and service reads **Paused** in the console, including services that were asleep. A sleeping service will not wake on a request while the balance is empty. * New deploys and builds are refused. * Billing stops immediately. Nothing accrues while paused. Nothing is deleted. Disks, configuration, secrets, URLs and deployment history are all intact, and topping up brings every project back exactly as it was with no redeploy. > [!NOTE] > > Being paused at zero balance is not the same as being suspended. Paused is self-serve: top up > and you are running again in moments. Suspension follows a failed payment or an operator > hold, and the billing page says which applies. Billing stops in both states: nothing accrues > while your services are scaled to zero. ## Plans | | Free | Hobby | Pro | Enterprise | | - | - | - | - | - | | Price | \$0 | \$5 / month | \$20 / seat / month | Negotiated | | Included usage | \$5 one time | \$10 / month | \$20 / month, per workspace | Negotiated | | Seats | 1 | 1 | Unlimited | Unlimited | | CPU per service | 1 vCPU | 8 vCPU | 32 vCPU | Unlimited | | Memory per service | 1 GiB | 8 GiB | 32 GiB | Unlimited | | Build machine | 4 vCPU / 8 GiB | 8 vCPU / 16 GiB | 16 vCPU / 32 GiB | Unlimited | | Pods per project | 6 | 12 | 24 | Unlimited | | Running pods per org | 12 | 40 | 120 | Unlimited | | Disk size per volume | 10 GB | 50 GB | 200 GB | 500 GB | | Included egress | 100 GB | 500 GB | 2 TB | 10 TB | | Logs and metrics history | 3 days | 7 days | 30 days | 30 days | | Backup retention | Not available | 7 days | 14 days | Unlimited | | Requests per second per IP | 25 | 100 | 250 | Unlimited | | Capability | Free | Hobby | Pro | Enterprise | | - | - | - | - | - | | PR previews | Yes | Yes | Yes | Yes | | Always-on services | No | Yes | Yes | Yes | | Shell access | No | Yes | Yes | Yes | | Manual scaling and autoscaling | No | Yes | Yes | Yes | | Persistent disks | No | Yes | Yes | Yes | | Object storage | No | Yes | Yes | Yes | | Scheduled backups | No | Yes | Yes | Yes | | Access controls | No | No | Yes | Yes | | Bring your own cluster | No | No | Yes | Yes | | Forced sleep after 5 idle minutes | Yes | No | No | No | The subscription is the minimum rather than a fee on top. Hobby's $5 comes back as $10 of usage credit — double the price — so the default always-on service, and a small disk beside it, cost exactly the subscription. A new organization is assigned the Free plan automatically at signup. See [Plans](/plans). ## Seats On Pro, seats are billed per member per month. Adding a teammate charges the prorated remainder of the period, and removing one credits the unused portion back. Free and Hobby are single-seat. Seats do not change your usage allowance, which is a flat monthly figure for the workspace. Team size and what your services consume are unrelated. ## Bring your own cluster Workloads on your own cluster are still metered, at a reduced rate. You supply the hardware; slipway supplies the control plane, the build pipeline, log and metric ingest, and support. The rate is set per cluster and shown on the cluster's page. See [Bring your own cluster](/clusters/byok). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.