Configuration reference¶

Every CASHPILOT_* setting, what reads it, and, where a file can also supply the value, which one wins.

That last column is the reason this page exists. Two settings look identical from the outside (a secret, supplied by an environment variable or by a file under /data) and resolve in opposite directions. Each behaviour is defensible on its own; together they are impossible to guess.

UI¶

Worker¶

GPU passthrough¶

CashPilot reports a worker's GPU as one of three answers, yes, no or unknown, and inside a container the honest answer is almost always unknown: the absence of a GPU there says nothing about the host.

That matters because four services only earn with a real GPU (Salad, Nosana, io.net, Vast.ai), and a GPU service deployed without the device starts, reports healthy, and earns nothing. It is the same shape as the Mysterium /dev/net/tun failure.

To let the worker see an Intel or AMD GPU, uncomment the block in the compose file:

devices:
  - /dev/dri:/dev/dri

NVIDIA is a different mechanism¶

/dev/dri does nothing for an NVIDIA card, and installing the NVIDIA Container Toolkit is only the prerequisite. The toolkit on its own does not hand the GPU to a Compose service. You have to ask for it as well, with either of these:

gpus: all

deploy:
  resources:
    reservations:
      devices:
        - driver: nvidia
          count: all
          capabilities: [gpu]

Both are Compose-spec attributes and both were validated against Compose v2.40.3. Pick one; do not set both. Use the explicit reservation when you need to pin particular cards, which it can do via device_ids and capabilities.

Once the GPU is actually allocated, the worker finds nvidia-smi and reports the real model name rather than just a device count.

Passing a device into the worker only lets the worker see it. A deployed GPU service needs the device too. Declare it in that service's catalog entry.

Compose-level¶

These are read by the compose files, not by CashPilot itself.

The UI's web port inside the container is fixed at 8080 (set via the container's CMD). CASHPILOT_UI_PORT and CASHPILOT_BIND_ADDR choose only the host side: which port and which interface it is published on.

Put these in a .env file next to the compose file, not on the command line. The Update button in Settings reads .env but never sees your shell. If the published ports came from the command line, it refuses to update rather than move the dashboard back to 127.0.0.1:8080.

Memory¶

The shipped compose files set no memory limit, deliberately. If you set one, size it from the numbers below rather than from what the container looks like when idle, because those two figures are very far apart.

Measured, not estimated¶

Read from the kernel's own high-water mark (memory.peak) on a live install after 8 hours of normal operation, which covers roughly 8 hourly collection cycles:

Provenance: drumsergio/cashpilot:1.14.1, 15 managed containers, 54.7 MB SQLite database, collectors running hourly in-process under APScheduler. Figures are memory.peak and docker stats from the container's own cgroup.

Why the peak is what matters¶

The UI idles around 72 MiB and peaks near 207 MiB, close to three times its resting size. Collection runs every service's collector in-process, and the transient cost of that dwarfs the steady state.

So a limit chosen by looking at a running container is almost certainly too low. 128 MiB looks generous against 72 MiB and will be exceeded on the first collection cycle.

If you do set one¶

Leave real headroom above the measured peak. 256 MiB leaves only 49 MiB above the 207 MiB observed here, on one install with one database size. A larger database, more services, or a slower provider that holds connections longer will all push it up.

services:
  cashpilot-ui:
    mem_limit: 384m     # 177 MiB above the measured peak
  cashpilot-worker:
    mem_limit: 256m     # 126 MiB above the measured peak

Re-measure on your own install rather than trusting these:

docker exec cashpilot-ui cat /sys/fs/cgroup/memory.peak

Running a service more than once on one worker¶

Open the service and set Instances next to a node. Each extra copy is its own container (cashpilot-<service>-2, -3, ...) and registers with the provider as its own device: every device name the catalog derives from the host name gets -2, -3 added.

• Providers count devices per public IP, and copies on one machine share its connection. Extra copies add devices, not bandwidth, so they only help where the provider pays per device and allows several per IP (Traffmonetizer and Mysterium document that). Where a provider allows one device per IP, the box is locked at 1; add workers on other connections instead.
• A service that keeps data in a host directory or publishes a host port runs once per worker, because its copies would share the directory and fight over the port.
• The count is saved per worker and kept by every redeploy. Lowering it removes the highest copies first; removing the service from a worker removes all of them.
• Each copy has its own Restart, Stop and Logs under Deployed on in the service's details and on the dashboard.
• A worker runs more than one copy only once it is on a release that supports it; older workers keep the box locked until they are updated.

A service's image¶

Each service runs from the image its catalog entry names. To run it from another one, open the service, expand Advanced and type the image in the Image box: a pinned tag of an image the catalog leaves floating (honeygain/honeygain:0.8.1), a registry mirror, or a community build for an architecture the provider does not publish.

• Blank means the catalog image. Clearing the box and deploying goes back to it.
• The choice is saved per worker with the rest of the deployment, and every redeploy keeps it until you clear the box. Redeploy running instances with this image applies it to the workers that already run the service, keeping their credentials.
• Only the image changes. Capabilities, devices, ports, the entrypoint and the stop timeout still come from the worker's catalog entry, so a custom image gets nothing the service does not already have. It does receive the service's credentials, so use an image you trust.
• An image that boots systemd (its main process is /sbin/init, and its own docs ask for --privileged) is refused at deploy time with that reason: it needs the host's cgroup tree, which CashPilot never grants, so it would exit 255 and restart forever with empty logs. Pick the image's non-systemd tag instead, usually lite (venatum/earnapp:lite, never venatum/earnapp).
• The dashboard marks such an instance custom image and judges "update available" against the image you chose, not the catalog's.

To run an image the catalog does not list at all, add it as a custom service instead.

Update check¶

CashPilot asks GitHub once a day whether a newer release exists, and shows a dismissible banner if there is one. A fleet running 33 releases behind with no indication anywhere is the problem this solves.

Three things it deliberately does not do:

• It never updates anything. It tells you; you decide. This application deploys containers and holds credentials, and nothing about that should happen because a version number changed.
• It never says "up to date". Offline, firewalled, disabled, or simply not run yet all produce unknown, and unknown renders nothing at all: no error, no spinner, and no reassurance it has not earned.
• It sends nothing about you. One unauthenticated GET to the public releases endpoint. No request body, no identifier, and your version is not reported upstream. GitHub learns that an IP asked what the latest release is.

Turn it off entirely and no connection is made:

environment:
  - CASHPILOT_UPDATE_CHECK=off

The banner is dismissible per version. Dismiss v1.20.1 and it stays gone until there is a v1.20.2, so it cannot become wallpaper.

Themes¶

Every signed-in user picks a theme in the avatar menu (top right). It applies straight away and is saved to that account, so it follows you to any browser. A user who never picked one gets Classic night.

Status colours (green up, amber warning, red down) mean the same thing in every theme, and every text and control meets WCAG AA contrast.

To add a theme, add one entry to app/themes.json and one block plus one swatch rule in app/static/css/style.css. The server, the settings check, the menu and the CI checks all read that list.