Costs and idle observation

Chalupa provides cost context to help prevent forgotten compute. It is not a billing system and does not attempt to reproduce credits, taxes, or every provider adjustment.

Commands on this page assume:

export DEMO_CONFIG="/path/to/project/chalupa.yml"

The three clocks

chalupa preview separates three clocks for inference configs, offline and without changing the config:

• Managed hours — hours the control plane observed signed activity; Chalupa's plan clock, never GPU hours or droplet hours. Preview reads only the local hosted-account cache and labels usage fresh or stale.
• Session — when Chalupa will try to stop compute: session.expiresAfterMinutes after up, plus idleShutdownMinutes when present. The local scheduler needs an awake, unlocked machine for expiry; with cloud.url, the configured console reaper handles expiry and idle for reported deployments, subject to the organization coverage described below.
• Provider estimate — estimated hourly rate × full session length, plus estimated retained storage per month: inference.cache.sizeGb and persist.sizeGb at an estimated $0.10/GiB-month. Unknown rates stay unknown; the provider invoice wins. Retained storage keeps billing after compute stops.

Cost surfaces

The Chalupa console estimates only the DigitalOcean resources it observes. A complete operating budget has additional provider-owned surfaces:

These services have separate invoices, retention policies, and scale-to-zero behavior. Do not infer total platform spend from the compute and storage cards alone.

What Chalupa estimates

The view separates:

1. Ephemeral compute: the approximate price of the size while the droplet exists.
2. Persistent storage: volume capacity, including while compute is sunk.
3. Month to date: observed cycles that intersect the current UTC month, using the observed rate for each deployment or size.
4. Monthly projection: an extrapolation that changes when you sink a resource.

Every monetary figure is labeled estimated.

The default volume rate is 0.10 USD/GiB/month, matching DigitalOcean's published Volume pricing when this guide was reviewed. Override DO_VOLUME_USD_PER_GIB_MONTH if the provider changes that rate.

Synthetic example

A demo environment can show:

Estimated compute        $0.0417/h
Estimated storage        $1.00/month
Estimated month to date  $0.62

These numbers are illustrative, not a quote. Check current provider pricing before creating a droplet or volume.

Money formatting is adaptive, not fixed at two decimals: a whole-cent amount like the storage or month-to-date figures above renders normally, but a sub-cent rate — most hourly compute prices, like $0.0417 above — widens until three significant digits are visible, down to a micro-dollar floor. A nonzero estimate never silently rounds to $0.00.

Sunk environment

When a deployment ends:

• its estimated hourly compute cost becomes zero;
• its historical month-to-date estimate remains;
• persistent storage can continue to incur estimated cost;
• the total must not automatically be described as zero.

This distinction prevents the false impression that chalupa down deletes the data volume.

How estimates are updated

A scheduled poll queries Chalupa-tagged resources with a read-only credential. It associates the observed size, volume, and deployment without using the token that can create or delete resources.

Updates are not instantaneous. The capture timestamp shows how fresh an estimate is. A short-lived deployment that starts and ends between two inventory polls might never provide a rate and can be absent from the month-to-date estimate. The provider invoice remains authoritative.

Control-plane database wake-ups

An autosuspending Postgres endpoint becomes inexpensive only when requests and open connections leave an idle interval longer than its suspension timeout. An active Chalupa environment sends heartbeats by design, so the control-plane database can remain active while billable compute is running. Signed ingest, authenticated reads, readiness probes, and scheduled maintenance can also wake it.

Use a pooled runtime connection and keep the direct migration connection release-only. Do not add database-backed warmers or short-interval polling to keep the console “ready.” Schedule reconciliation and retention at the lowest cadence that still meets their recovery guarantees, and treat every scheduled invocation as part of the database compute budget.

After changing a schedule, retention window, or query pattern, compare at least one representative operating period before and after the change. Record compute time, storage growth, request failures, and recovery delay; a lower compute ceiling alone does not fix a workload that continually wakes the database.

Configure idle observation

idleShutdownMinutes: 45

This value makes the agent report an idle window. It never gives the droplet a deletion credential. When the external control-plane reaper and its dedicated write credential are configured, it also supplies the persisted deadline for automatic compute shutdown.

Omitting the value disables idle observation. The schema accepts values from 5 to 10,080 minutes.

How the countdown is derived

The agent reports:

• idleChecks;
• checkIntervalSeconds;
• limitMinutes;
• the latest activity time, when available.

The console calculates remaining minutes from these fields. The value is approximate because heartbeats, checks, and UI rendering do not occur at the same instant.

What counts as activity

The v1 implementation observes established SSH sessions. An active tunnel resets the counter; closing it begins consecutive idle checks.

This does not measure business activity inside each service. Remote work that does not use SSH may require a different policy or a larger window.

What is destroyed by idle observation

With no external reaper configured, the console only shows a warning and the operator decides when to run:

chalupa down --config "$DEMO_CONFIG"

For reported deployments (those with cloud.url and an ingest key), the configured console reaper destroys compute at session expiry as well as at the idle deadline. Customer organizations opt in with their own DigitalOcean token; without one, they still rely on the local scheduler. Session expiry wins over fresh heartbeats, an open SSH tunnel, and a live CI suite. Live CI still defers idle shutdown.

The worker uses a dedicated write credential, refuses compute without a Chalupa tag, and never targets the protected data stack. A failed provider call leaves the deployment active so the next scheduled tick can retry.

This is not a hard spend cap. Cron delays, missing reports, and provider or control-plane failures can extend billable runtime beyond the deadline. Persistent storage continues billing after compute is destroyed.

For separately configured demo or test sessions, an explicit, operator-local expiry runner can call the same task down path after rechecking a registered config digest and provider ID. It is independent from the idle countdown, has no Vercel or droplet credentials, and cannot target the data stack.

Arm the console reaper

chalupa setup --inference asks whether to arm the console reaper. Supply a DigitalOcean custom token with only droplet:read and droplet:delete scopes. The token can read and delete droplets throughout that account. Chalupa restricts its use to destroying Chalupa-tagged droplets registered to your organization after session expiry or an idle deadline. It does not delete persistent volumes.

Chalupa stores the token encrypted at rest with AES-256-GCM under CHALUPA_INGEST_MASTER_KEY and never shows it again. The environment's idle window card shows Console reaper: armed or not armed. Opt-in works while your laptop sleeps, provided the deployment reports to the console.

Revoke with DELETE /api/account/provider-token?provider=digitalocean using an account session bearer, or delete the token in DigitalOcean to revoke it instantly. Console revocation stops future sweeps; an already-started provider request may finish. A DigitalOcean 401/403 marks the credential invalid and records a provider warning. Replace it to arm the reaper again; Chalupa never falls back to another organization's credential.

The sweep selects at most five customer organizations per tick, with the order shuffled each minute, and stops provider work after 22 seconds. Large fleets may need multiple ticks. This remains a best-effort shutdown, not a billing cap.

Recommended practice

Use the signal as operational discipline:

1. configure a reasonable window;
2. keep the informational warning visible;
3. run chalupa down when your work ends;
4. verify that the environment appears sunk;
5. review retained storage separately;
6. review Postgres, hosted runtime, and artifact-storage usage in their own provider consoles.