Data and seeding

An ephemeral droplet is useful only if destroying it does not force you to rebuild expensive data every time. Chalupa solves this problem with an independent block storage stack.

The following commands assume:

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

Declare persistence

persist:
  sizeGb: 20

After validating Compose:

chalupa data-up --config "$DEMO_CONFIG"

The volume is created in the demo-harbor-data stack. The 20 GiB value is a synthetic example; choose capacity based on your dataset, operating margin, and current price.

How volumes are mounted

Block storage is mounted at /mnt/chalupa. Each named Compose volume gets its own subdirectory under /mnt/chalupa/volumes, named after the Compose volume itself:

/mnt/chalupa/volumes/
  postgres-data/
  redis-data/

Bind mounts are generated from the volumes actually used by the selected services. Chalupa does not add a volume that belongs only to a pruned service.

Restore a seed

Declare a local command:

seed: bun run seed:demo

Keep the tunnel open in one terminal:

chalupa tunnel --config "$DEMO_CONFIG"

Then run this command in another:

chalupa seed --config "$DEMO_CONFIG"

The command runs in your project, not inside the droplet. Your tools reach the remote databases through SSH at localhost.

Keep literal credentials and secret-store references out of the seed string: the command is stored as a local Pulumi output. Let the project-owned script inject any required credential at runtime and keep shell tracing disabled.

Design a repeatable seed

A production seed should:

1. fail with a nonzero exit code;
2. support resuming or explain how to clean up a partial attempt;
3. validate that the tunnel and the correct service are available;
4. avoid printing credentials;
5. produce a clear completion signal.

For large datasets, prefer verifiable files and bounded retries for each restore unit. Avoid one fragile stream when the source tool supports partitioning.

What happens when you sink compute

chalupa down --config "$DEMO_CONFIG"

This destroys the droplet. It does not destructively unmount or delete the demo-harbor-data stack. On the next chalupa up, the new compute mounts the volume again.

In the Chalupa console, a sunk environment can show:

• estimated compute cost of zero;
• estimated storage cost greater than zero;
• the latest observed capacity and usage;
• a seed-restored event, if one was reported.

Do not interpret “sunk” as “no remaining cost.”

Delete data

task data-nuke \
  CONFIG="$DEMO_CONFIG" \
  CONFIRM_DATA_NUKE=demo-harbor

This destroys the persistent volume. It is irreversible and not part of the normal lifecycle. Before you run it:

• confirm the exact stack;
• verify that no unique seed exists without a backup;
• retain any required artifacts or dumps;
• communicate the expected data loss.

The confirmation value must exactly match name in chalupa.yml. A missing or different value fails before Chalupa unprotects the data stack. Never turn this confirmation into a reusable shell default.

chalupa status --config "$DEMO_CONFIG" can distinguish a configured data stack that is absent, present, or unknown without selecting it or contacting the provider. Its expected size comes from chalupa.yml; it is not a live provider-capacity reading. See Local CLI and operator UI.

Artifacts are not volumes

Videos, reports, and screenshots from a suite must not accidentally live inside the database volume. Chalupa suite runs store ArtifactRefV1 metadata for a local stash, a stable external link, or a committed private hosted file.cheap artifact. Transport locators cannot contain embedded credentials, but metadata is not DLP-scanned and must remain non-sensitive. file.cheap can emit either local fcheap-local references or private hosted fcheap-cloud references. Chalupa stores the reference envelope only: it never stores artifact bytes or tries to resolve a local fcheap:// URI. See Suites and artifacts.