Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Managed Compute: region limits and idle worker billing with minScale 0

Open
  • Is something wrong?
#5,837 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
rust
Domain
backend-api-design, cloud, infrastructure

Research direction

Start with the runner-config upsert implementation at engine/packages/pegboard/src/ops/runner_config/upsert.rs and compare its omitted-value default with the workers and pool configuration documentation. Then trace the managed-pool API behavior for region placement, worker limits, idle retention, resource validation, and runner-config access. Done means the supported controls and defaults are established and the report's separate questions have clear answers or scoped follow-up work.

Written by the indexing model from the issue text.

Description

We are testing agentOS with RivetKit 2.3.17 on managed Rivet Compute with minScale: 0,
maxScale: 1, 1 vCPU and 2 GiB. Actor idle timeout is ten seconds. There are
no customer workloads in these experiments.

Two deployments started the application in Europe, US East, US West and
Singapore. Our actor inventory had instances only in Europe and US East.
Project compute telemetry reached about 240 active instance-seconds per minute
at a weighted 1 vCPU / 2 GiB, consistent with four allocated workers.

After a controlled two-turn test, all actors were sleeping. The final receipt
read completed and the guest disposal hook reported zero active turns and
processes. Compute telemetry continued reporting allocation for approximately
fifteen minutes before explicit zero. Shortening the actor's shutdown grace
from fifteen minutes to thirty seconds did not shorten that allocation tail.
We are not attributing the host retention to the separate native VM teardown
warning: synchronized causality has not been established.

The managed-pool API exposes resources and runner draining, but we could not
find supported region or worker idle-retention settings. The dashboard hides
the lower-level provider editor for managed pools. We have not changed the
generated runner datacenter map.

A separate resource-update/rollback observation on October 5, 2026 used a fixed
window starting at 10:45 UTC. At 11:27 UTC, the latest available telemetry ended
at 11:15 UTC and showed explicit zero allocation from 11:10:57 onward. The
window's reported allocation cost was approximately $0.137, calculated from
the published CPU/memory rates. This includes the failed resource update and
rollback, without inference. It is consistent with four retained workers for
about fifteen minutes, but is not an exact attribution of all monthly spend.
Telemetry was delayed; we do not present the last sample as current live state.

The workers documentation describes a
10-second default serverless drain grace, while the
pool configuration reference
lists 1,800 seconds. The public runner-config upsert implementation also
mentions an omitted-value default of 1,800 seconds. Our managed pool returns
runnerConfig: null, so we cannot establish its effective drain value from
that response. Attempts to read /runner-configs with existing connection
credentials returned HTTP 403. We have not bypassed managed configuration.

Questions:

  1. Is four-region startup on each managed deployment expected, and is there a
    supported way to deploy only to the regions containing our actors?
  2. Is maxScale per region? How can a small staging project enforce an overall
    worker cap without stranding actors already placed in two regions?
  3. What controls the roughly fifteen-minute allocation after actors sleep,
    and can that retention be shortened safely for agentOS?
  4. Can the managed API validate CPU/memory combinations before accepting an
    update? A 0.5 CPU / 2 GiB update was accepted then failed during deployment
    because that CPU permits at most 1 GiB. We restored the 1 CPU / 2 GiB baseline.
  5. Which documented drain default applies to managed Compute, and what is the
    supported API and permission scope for reading its effective runner config?
    Is runner draining related to worker idle retention, or are these separate
    controls?

At the published rates, four workers retained for fifteen minutes cost about
$0.14 per rollout. We want to keep hosted Rivet and durable actors while making
short staging sessions economical. We can provide bounded, redacted telemetry
for these experiments. This report intentionally omits tokens, actor keys,
user identities, transcripts, project files and service URLs.

Other references:

Dominant language
Rust
Stars
6.3k
Forks
279
Avg merge
1d 12h
Merged PRs (30d)
50

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rivet-dev/rivet

All issues in rivet-dev/rivet

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.