Orgs, usage and billing
Your org owns your sandboxes, templates, keys and vault; see its quotas, current use, usage and estimated cost.
Everything in pols belongs to an org: sandboxes, templates, API keys, SSH keys and the vault. An API key acts on its own org only, and names of sandboxes and templates are unique within an org.
Accounts and orgs
You sign up at https://my.pols.so/signup with your email address; there is no password. Each address can have one account, and every new account gets an org of its own with the default quotas.
New accounts are approved by hand. Until yours is approved you can log in, but not create API keys; you get an email once it is approved.
Your account page shows your org’s API keys, its vault, its webhooks, its sandboxes with their current CPU, memory and disk use, and its usage against its quotas.
Members and roles
Sandboxes, templates and the vault belong to the org, not to the person who created them. Each member of an org has one of three roles:
| Role | May |
|---|---|
owner |
everything, including making and removing owners |
admin |
manage the members other than owners, every API key of the org, the vault, webhooks and billing |
member |
use sandboxes, templates and SSH keys, make and revoke their own API keys, and see the vault’s names |
An API key acts with the current role of the user who made it: changing someone’s role changes what their keys may do, and removing someone from the org revokes their keys. GET /v1/org says the role of the calling key.
Invites
Owners and admins invite people by email on the members page. The link in the invite works once, within 7 days, and joins that address to the org. An address belongs to one org, so an address that already has a pols.so account cannot be invited. New accounts are approved before they can create API keys.
Current use
The account page and pols stats show each running sandbox’s CPU, memory and disk use (disk is the root disk). The control plane samples it about every 30 seconds while a sandbox runs and keeps the last hour; see Watching resource use. On a server that does not sample resource use, the table shows –.
Your org from the CLI
pols org # the org, its quotas and what it uses right now
pols usage # usage and estimated cost, this calendar month
pols usage --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z
pols stats # CPU, memory and disk use of the running sandboxes
The same data is in the API: GET /v1/org, GET /v1/usage and GET /v1/org/stats.
Usage and billing
List prices exclude VAT; VAT is added at checkout, when you top up credit or pay for the subscription. An EU business outside Luxembourg whose VAT ID VIES confirms (the reverse charge), or a business outside the EU with a tax ID, pays no VAT. Everyone else pays Luxembourg VAT (17 percent): every customer in Luxembourg, businesses included, and any other EU consumer or business without a VAT ID VIES confirms. The pricing page has the current list prices; at the time of writing they are:
| Charge | Price | What counts |
|---|---|---|
| CPU | EUR 0.035 per busy vCPU-hour | the busy vCPU time the host measures |
| RAM | EUR 0.018 per GiB-hour | the full RAM of the sandbox’s size, while it runs or is in standby on the standard engine; nothing while it is stopped |
| Disk | EUR 0.18 per GiB-month above 10 GiB free | used disk of every sandbox and template, in any state, until it is deleted |
- Stopping a sandbox ends its CPU and RAM charges, not its disk charges.
- Standby is billed per engine. On the standard engine a sandbox in standby keeps its memory on the host and pays its size’s full RAM. On the new engine (Cloud Hypervisor, which an operator switches on per org), standby writes the sandbox’s memory to disk, which is billed as disk instead of RAM.
pols usageshows the usage as priced lines; the account page shows one row per charge, with the lines per sandbox under Per sandbox. Usage defaults to the current calendar month in UTC;--fromand--totake RFC 3339 times.
Credit
While billing is not switched on for an org, its usage is metered and shown but not charged, and the monthly sandbox-hours quota caps it instead. New orgs have billing on from the start of their trial; you are told by email 30 days before billing is switched on for an existing org.
Once billing is on, each hour’s usage is taken from the org’s credit once the hour is over, from the credit that expires first, prepaid credit last. pols balance shows what is left.
Owners and admins buy credit with pols topup (EUR 5 to 1000 of credit, which never expires) or the monthly pols subscription (EUR 20 a month with EUR 25 of usage included). These amounts exclude VAT, which is added at checkout: with Luxembourg VAT, EUR 5 of credit costs EUR 5.85 and a subscription month EUR 23.40; under the reverse charge or outside the EU you pay the amount itself. Each payment’s net_eur, vat_eur and charged_eur show the split, and every paid top-up and subscription month gets an invoice (pols invoices). At zero, running and standby sandboxes are stopped and none can start or wake (402 insufficient_credit) until there is credit again. Their disks are kept, and disk above the free allowance keeps costing: what the credit cannot pay becomes debt, taken first from the next credit.
Trial credit
A new org gets trial credit of EUR 10 that lasts 30 days. The trial starts when billing is switched on for the account; nothing is taken from the trial credit, and it does not expire, until then. While an org is on its trial, it has the trial limits.
Notices
While billing is off, at 80 percent of the monthly sandbox-hours, the org’s users get an email. At 100 percent, the org’s running and standby sandboxes are stopped until the next month or until the quota is raised; see Limits and quotas.