How do I limit the vCPU and vMemory consumption of sandboxes?

ryanhaticus

PROOP

a month ago

Today, I can't set the vCPU/vMemory limits of a sandbox like I can a regular service. Billing in this way is a bit ambiguous and I have little control over sandbox cost ops. Is there something I'm missing?

Solved$20 Bounty

Pinned Solution

ryanhaticus

PROOP

a month ago

cgroupv2 is available in Railway sandboxes and can be used to limit system resources without killing processes (e.g. with memory.high).

https://docs.kernel.org/admin-guide/cgroup-v2.html

This is sufficient and achieves what was originally intended.

2 Replies

Railway

BOT

a month ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 1 month ago

coxdoj

HOBBY

a month ago

You’re not missing a setting. Railway currently does not expose per-sandbox vCPU or memory limits like the Replica Limits available for regular services.

The documented sandbox creation options cover idle timeout, templates/checkpoints, networking, variables, region, and authentication—but not CPU or memory caps. The CLI’s sandbox create options likewise have no resource-limit flags.

For cost control today:

Set a short sandbox idle timeout with idleTimeoutMinutes in the SDK or --idle-timeout-minutes in the CLI.
Explicitly call sandbox.destroy() or railway sandbox destroy as soon as the task finishes.
Use the Workspace Usage page—or railway usage—to monitor CPU and memory costs.
Configure workspace-level compute alerts and a hard usage limit if you need an absolute billing ceiling. Be aware that reaching the hard limit takes all workloads in the workspace offline.

Sandboxes are billed for actual CPU, memory, and network usage while running, and an idle sandbox still consumes billable resources until it is destroyed or reaches its idle timeout.

References:

ryanhaticus

PROOP

a month ago

cgroupv2 is available in Railway sandboxes and can be used to limit system resources without killing processes (e.g. with memory.high).

https://docs.kernel.org/admin-guide/cgroup-v2.html

This is sufficient and achieves what was originally intended.

Status changed to Solved brody • about 1 month ago

Welcome!