Skip to content

Cost estimate ​

Every app's Resources tab shows an estimated monthly cost under a few illustrative reference pricing profiles, alongside the resource limits editor. The CLI exposes the same number with levelrail-cli apps cost <name>, and the API with GET /api/v1/apps/{name}/cost-estimate.

This is an estimate, not a real bill. It never calls a live pricing API and never reflects what your own hardware actually costs you. The point is comparative: showing roughly what the same CPU/memory envelope would cost under typical metered cloud pricing, so self-hosting's real advantage shows up as a number instead of an assertion.

What it's based on ​

The estimate needs a CPU and a memory size for the app. It resolves each dimension independently:

  1. Declared, when the app's resources: block in app.yaml (or an equivalent API/CLI call) sets a memory or CPU limit. This is the preferred basis: it's what you actually told Levelrail to reserve.
  2. Observed, when no limit is declared but at least a few hours of usage telemetry exist. The estimate falls back to the 95th percentile (p95) of actual CPU and memory usage over the last 7 days, the same lookback window the resource recommendation feature uses.
  3. Unavailable, when neither a declared limit nor enough usage history exists yet (a brand-new app with no resources: block and telemetry disabled or not yet collecting). The estimate still returns a response, using the provider's minimum monthly charge, so the UI has something to show rather than an error, but the size and basis fields make it clear there's nothing real behind the number yet.

The formula ​

For each reference provider:

cpu_cost    = vcpu_cores  * provider.cpu_per_core_usd
memory_cost = memory_gib  * provider.memory_per_gib_usd
total       = max(cpu_cost + memory_cost, provider.minimum_usd)

That's it. No tiered discounts, no sustained-use pricing, no egress or storage costs (Levelrail doesn't yet have a per-app storage usage metric to estimate that dimension honestly, so it's left out rather than guessed).

Reference providers ​

Three illustrative profiles ship by default, in internal/costestimate/costestimate.go. None of them is any single real provider's actual rate card; they're round numbers meant to be directionally honest for 2026-era budget cloud pricing, not a quote.

ProviderWhat it represents$/vCPU-core/mo$/GiB/moMinimum/mo
Generic cloud VMA bare unmanaged VM/IaaS instance$4$4$4
Generic managed VMA managed VM with backups/support bundled in$8$6$10
Generic metered container PaaSHeroku/Render/Railway-shaped metered pricing, which bundles a real margin over raw compute$25$10$7

The gap between the first and third rows is the point: metered container platforms charge several times raw compute cost for the convenience of not managing a server, which is exactly the cost Levelrail's self-hosted model avoids.

Correcting the rates for your own region ​

Hardcoded defaults are never going to match your actual provider or region, so every rate is overridable with an env var on the control plane process:

APP_COST_ESTIMATE_VM_CPU_USD=3.5
APP_COST_ESTIMATE_VM_MEMORY_USD=3.0
APP_COST_ESTIMATE_VM_MINIMUM_USD=5

APP_COST_ESTIMATE_MANAGED_VM_CPU_USD=7
APP_COST_ESTIMATE_MANAGED_VM_MEMORY_USD=5
APP_COST_ESTIMATE_MANAGED_VM_MINIMUM_USD=12

APP_COST_ESTIMATE_PAAS_CPU_USD=20
APP_COST_ESTIMATE_PAAS_MEMORY_USD=8
APP_COST_ESTIMATE_PAAS_MINIMUM_USD=7

A malformed or negative value is ignored and the built-in default is kept; there's no way to misconfigure this into a crash. Restart the control plane after changing any of these for the new rate to take effect.

Released under the Apache 2.0 License.