Billing & limits

How a run is billed

A Nextflow run bills to your account like any other Carolina Cloud compute:

• The head is a small container, billed for as long as it’s running (it’s tiny — it only runs the driver). Delete it when you’re done with a project.
• Pool workers are billed per worker, only while they’re doing work. Each worker is charged at a flat Nextflow rate — per vCPU-hour, per GiB of RAM, per GiB of disk — for its current size, so a task costs the same wherever the scheduler places it. Every resize is metered exactly, a worker shrinks to a small idle floor between tasks, and it’s reclaimed when the pipeline goes idle. You pay for the compute your tasks actually use — no fixed cluster, no instance-type guesswork.

Because billing is per-worker and per-run, you can see the exact cost of a pipeline run — something managed batch services can’t report inline.

Note

Object storage (your workDir bucket) is billed by your storage provider, separately from Carolina Cloud compute.

Where errors show up

When a task fails, the executor surfaces it the way Nextflow normally does:

• The failing task’s error block prints in the terminal, pointing you at its work directory and the relevant log files.
• .command.err / .command.out in the task’s work dir hold your tool’s own stderr/stdout.
• .exec.err — a Carolina Cloud–specific file in the same work dir — captures the worker’s staging and setup output: pulling inputs from your bucket, credential/bucket errors, a missing S3 tool, and so on. This is where a failure that happens before your command runs shows up (bad credentials, NoSuchBucket, an image missing a required tool) — cases where the normal .command.err would be empty. Nextflow’s terminal error also points you to it.
• The task’s real exit code comes from its .exitcode file, so you can tell “my tool exited non-zero” (look in .command.err) from “it never got to run” (look in .exec.err).
• A task you cancel reports exit code 137.

Resume

nextflow run … -resume works — completed tasks are skipped and the run picks up where it left off, using durable state on the platform (worker inventory, in-flight tasks, billing).

One caveat

The locality cache is not restored on resume — the executor rebuilds its view of the pool but re-stages task inputs from S3 rather than from workers’ local caches. Resumed runs are correct; they just don’t get the zero-download locality speedup that a fresh run does.

Not supported yet

The executor is early and focused. Not yet available:

	Notes
GPU tasks	The accelerator directive isn’t honored yet — GPU pool workers are on the roadmap.
DSL1 pipelines	Nextflow DSL2 only.
gs:// / az:// work dirs	S3-compatible storage only — see Storage & buckets.
Private / non-AWS-S3 third-party buckets	Only your own storage and public-AWS references — see Storage & buckets.
Cross-provider publishing	workDir and --outdir must share an endpoint.

Good to know

• First use of a new container image pays a one-time docker pull on the host (seconds to a few minutes for large bioinformatics images). Subsequent tasks on that image are fast.
• A very wide fan-out across different container images stages through S3 between stages (workers of one image can’t run another image’s tasks). Same-image chains get the fast local-scratch path.
• Results are only durable once written to your workDir/--outdir in S3; the local scratch on workers is transient and cleared as the pool is reclaimed.

Have a pipeline that needs something here? Let us know — it helps us prioritize.