Summary
When --min-disk is passed to brev create together with --type, the disk-size minimum is silently ignored — the instance type's default disk size wins. There is no flag combination that lets a caller specify both which instance type to use AND what root-disk size to provision; you can express one or the other.
Reproducer
brev create gh-runner-test --type n2d-standard-8 --min-disk 589 --detached
brev refresh
ssh gh-runner-test 'df -h / && lsblk'
Observed:
Filesystem Size Used Avail Use% Mounted on
/dev/root 125G 6.6G 119G 6% /
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 129G 0 disk
├─sda1 8:1 0 128.9G 0 part /
Disk is 129 GB; the requested 589 GB minimum was ignored. No warning or error was emitted.
Expected
One of:
- The instance is provisioned with at least 589 GB of root disk (preferred — the user asked for a minimum, the CLI delivers).
- The command rejects with an error like
--min-disk 589 cannot be satisfied with --type n2d-standard-8 (default disk: 129 GB), so the caller can either drop --type and let brev search pick a type that satisfies the minimum, or pick a different type explicitly.
Either is fine; silently dropping the flag is what hurts.
Why it matters
Callers that need a specific instance type and a specific disk size — e.g., long-lived self-hosted CI runners where the type is dictated by cost/throughput tradeoffs and the disk is dictated by build artifact volume — have no way to express that intent through the CLI today. The only available workaround is to drop --type and let brev search --min-disk N pick a type whose default disk happens to be ≥ N, which doesn't work when the user has a specific type in mind.
n2d-standard-8 exposes disk_min_gb=10, disk_max_gb=16384 in brev search cpu --json, so 589 GB is well within the supported range for this instance type — this is a CLI/server gap, not a hardware constraint.
Notes
target_disk_gb reported by brev search cpu --json for n2d-standard-8 is 10, but the actual provisioned root disk on --type n2d-standard-8 was 129 GB. The catalog metadata also looks worth a sanity check, but the primary bug is --min-disk being a no-op.brev version: v0.6.323.
Summary
When
--min-diskis passed tobrev createtogether with--type, the disk-size minimum is silently ignored — the instance type's default disk size wins. There is no flag combination that lets a caller specify both which instance type to use AND what root-disk size to provision; you can express one or the other.Reproducer
brev create gh-runner-test --type n2d-standard-8 --min-disk 589 --detached brev refresh ssh gh-runner-test 'df -h / && lsblk'Observed:
Disk is 129 GB; the requested 589 GB minimum was ignored. No warning or error was emitted.
Expected
One of:
--min-disk 589 cannot be satisfied with --type n2d-standard-8 (default disk: 129 GB), so the caller can either drop--typeand letbrev searchpick a type that satisfies the minimum, or pick a different type explicitly.Either is fine; silently dropping the flag is what hurts.
Why it matters
Callers that need a specific instance type and a specific disk size — e.g., long-lived self-hosted CI runners where the type is dictated by cost/throughput tradeoffs and the disk is dictated by build artifact volume — have no way to express that intent through the CLI today. The only available workaround is to drop
--typeand letbrev search --min-disk Npick a type whose default disk happens to be ≥ N, which doesn't work when the user has a specific type in mind.n2d-standard-8exposesdisk_min_gb=10,disk_max_gb=16384inbrev search cpu --json, so 589 GB is well within the supported range for this instance type — this is a CLI/server gap, not a hardware constraint.Notes
target_disk_gbreported bybrev search cpu --jsonforn2d-standard-8is10, but the actual provisioned root disk on--type n2d-standard-8was 129 GB. The catalog metadata also looks worth a sanity check, but the primary bug is--min-diskbeing a no-op.brevversion: v0.6.323.