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"

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.04/h
Estimated storage        $0.03/month
Estimated month to date  $0.62

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

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 task 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.

Configure idle observation

idleShutdownMinutes: 45

This value makes the agent report an idle window. It does not give the droplet a deletion credential or enable automatic deletion.

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 today

Nothing is destroyed when the countdown expires. The console shows a warning, and the operator decides when to run:

task down CONFIG="$DEMO_CONFIG"

A future P1 worker may enforce an automatic sinking policy outside the droplet with narrowly scoped authority. Even then, it must not delete the data stack.

Recommended practice

Use the signal as operational discipline:

1. configure a reasonable window;
2. keep the informational warning visible;
3. run task down when your work ends;
4. verify that the environment appears sunk;
5. review retained storage separately.