Billing Model¶

This page explains how Servala prices a managed service instance: the billing components, how they combine into a monthly total, and the mechanics behind sizing, discounts, and service levels.

It describes the structure of the model, not the actual prices. The live prices and the interactive price calculator are on servala.com. For the technical implementation (catalog sync, Odoo products, Kubernetes billing annotations) see Billing & Pricing.

The idea in one line¶

Servala decomposes every service instance into independent billable components. Each component is priced and scaled on its own, and the sum is the monthly total. This keeps invoices transparent and lets the infrastructure layer (compute, storage) evolve independently from the service-operation layer (managed service, service levels).

flowchart LR
    subgraph infra["Infrastructure layer (per cloud provider)"]
        direction TB
        comp["Compute"]
        stor["Storage, incl. backups"]
        csp["Additional CSP resources"]
    end
    subgraph ops["Service operation layer (per service)"]
        direction TB
        ms["Managed Service (flat)"]
        mss["Managed Service Sizing (per unit)"]
    end
    lic["License (optional)"]
    infra --> total(["Monthly total"])
    ops --> total
    lic --> total

Billing components¶

A service instance is billed through the following components:

The monthly total is the sum of these components:

Total = Compute            (per component × replicas)
      + Storage            (per component × replicas)
      + Additional CSP resources (where applicable)
      + Managed Service    (flat; includes service level surcharge if selected)
      + Managed Service Sizing   (per unit × main component replicas)
      + License            (where applicable)

Each component is described below.

Compute¶

A compute plan is a predefined bundle of CPU and RAM. Plan names are provider-independent (the same name means the same resources everywhere), while the plan price is derived from each cloud provider's infrastructure cost and therefore varies by provider. See Compute Plans & SLAs for the customer-facing view.

A service can consist of more than one component. For example, a Nextcloud instance runs alongside a PostgreSQL database. Each component has its own compute plan and its own replica count, and each appears as a separate compute line on the invoice. Components can be sized independently: the main service might run on a larger plan with two replicas while its database runs on a smaller plan with three replicas for higher availability.

Storage¶

Storage is billed per GiB and added on top of compute. The per-GiB rate already includes the cost of backups, so customers see a single storage rate without a separate backup line.

A provider can offer several storage classes (for example SSD or NVMe), each with its own per-GiB rate. Each persistent volume of a service is reported as its own storage line, so a service with supporting components shows multiple storage lines, each labelled by the component it belongs to. Storage scales with the replica count of the component it belongs to.

Additional CSP resources¶

Some service and provider combinations need infrastructure beyond compute and storage, such as load balancers, public or floating IP addresses, DNS records, or network traffic. Where they apply, these are passed through at the provider's rate and shown as separate line items. They are flat per instance and do not scale with replicas or storage size. The same service on a different provider may need none of these.

Managed Service¶

A flat fee per service instance, independent of instance size. It covers the minimum cost of operating a managed service: monitoring, maintenance, updates, and incident response. The fee depends on the service and on the selected service level. When a service level is selected, the flat fee increases to include the service level surcharge.

Managed Service Sizing¶

A per-unit fee that accounts for the growing complexity of operating larger instances: larger backups, longer recovery times, more involved tuning. Today all services use "per GiB RAM" as the unit, derived from the main component's compute plan (for example a plan with 8 GiB RAM counts as 8 units). Future services may use other units such as "per user".

The sizing fee uses a progressive discount model and is based on the main component only. Supporting components do not carry their own managed service or sizing fee: they are covered by the main service. Like the Managed Service flat fee, the per-unit rate increases to include the service level surcharge when a service level is selected.

License¶

When a managed service requires a commercial license or subscription from the software vendor, Servala resells it and the license appears as a separate line item. The billing shape follows the vendor's terms (per user, per instance, flat, or usage-based). Services built on open source software without a commercial vendor have no license component.

Composite services¶

A service can be composed of a main component and one or more supporting components (for example Nextcloud with a PostgreSQL database). Each component has its own compute and storage, with its own plan and replica count, and each appears on the invoice. The Managed Service and Managed Service Sizing fees are charged once for the whole instance, based on the main component. Supporting components do not carry their own managed service fee.

flowchart TB
    subgraph si["Service instance"]
        direction TB
        subgraph main["Main component (e.g. Nextcloud)"]
            mcs["Compute + Storage<br/>own plan and replicas"]
        end
        subgraph sup["Supporting component (e.g. PostgreSQL)"]
            scs["Compute + Storage<br/>own plan and replicas"]
        end
        mgmt["Managed Service + Sizing<br/>charged once, based on the main component"]
    end

Service levels (SLA)¶

Service levels are optional add-ons that provide an uptime guarantee. A service without a service level operates on a reasonable-effort basis with no uptime commitment, and any service level can be applied to any service. For the available levels and what they cover, see Service Levels.

From a billing perspective, when a service level is selected its surcharge is folded into both the Managed Service flat fee and the per-unit sizing rate, rather than appearing as a separate line. The surcharge is defined per service per service level, because guaranteeing uptime takes different effort for different services. This keeps the invoice structure identical whether or not a service level is chosen.

Some service levels require high availability. In that case a minimum number of replicas is enforced by the portal, and the customer cannot configure fewer. From a billing perspective such an instance is simply billed for the replicas it runs.

Progressive discount model¶

The per-unit sizing fee uses a progressive model that works like income tax brackets: the units of an instance are split into successive ranges, and each range gets its own per-unit rate. Higher ranges receive a larger discount, so the per-unit cost falls as an instance grows. The discount applies to the sizing fee only. Compute and storage are not affected.

Each range becomes its own invoice line, and the result is multiplied by the main component's replica count. When a service level is selected, its per-unit surcharge is added to the base rate before the discount is applied, so the surcharge is discounted at the same rate.

flowchart LR
    u["Instance units<br/>(e.g. GiB RAM)"] --> r1["Lowest range<br/>no discount"]
    u --> r2["Middle ranges<br/>growing discount"]
    u --> r3["Highest range<br/>largest discount"]
    r1 --> fee(["Sizing fee:<br/>sum of ranges × main replicas"])
    r2 --> fee
    r3 --> fee

Scaling behavior¶

When an instance scales, the components behave as follows:

The discount bracket is determined by the plan size, not by the total across replicas. The bracket split is calculated once from the plan and then multiplied by the replica count.