Ray is being built as a lean inference runtime for cheap VPS hardware. Contributions should preserve that constraint instead of treating it as branding.
- Smaller-model hosting and routing primitives
- Configuration, scheduling, caching, and observability that help a single node perform well
- Deployment ergonomics for self-hosted builders
- Adapter work that keeps the runtime backend-agnostic without bloating the core
- Kubernetes-first control planes
- Cluster complexity before single-node reliability is solid
- Heavy optional dependencies pulled into the hot path
- Product surface that duplicates broader sovereignty concerns already better owned by
iso
- Install Node 20+ and Bun 1.3+.
- Run
bun install --frozen-lockfile. - Start the default sub-1B
llama.cpppath withbun run dev, or usebun run dev:tinyif you do not have a local model backend running yet. - Build with
bun run build. - Run tests with
bun run test. - Run
bun run release:gatebefore opening a PR — same command CI runs (Quality checks →qualityjob: lint, format check, tests).
- Keep the runtime dependency graph small.
- Prefer stable primitives over feature sprawl.
- Explain why added memory or operational cost is worth it.
- Favor explicit configuration over framework magic.
- Make local development and single-VPS production behave the same way whenever possible.
- Keep changes scoped.
- Include doc updates when architecture or operator-facing behavior changes.
- Add or extend tests when changing scheduler, cache, config, or transport behavior.
- For user-visible or API changes in
@razroo/ray-coreor@razroo/ray-sdk, add a Changeset (bun run changeset). For repo-only or private-package work, add an empty changeset ifbun run changeset:statusrequires it:bunx changeset add --empty. - Call out memory, cold-start, or deployment tradeoffs in the PR description.