Scale every project surface intentionally.
Project scaling is not a sidecar connector. It is canonical Runtime Fabric intent: manual desired count, autoscale rules, load-balanced ingress, named scale groups, per-surface topology, vertical CPU and memory policy, storage, bandwidth, accelerators, and edge budgets. Vadyl matches that intent against RuntimeSubstrate capabilities and fails closed when a substrate cannot realize it.
One project. Many independently scaled surfaces.
API ingress, core handlers, event consumers, scheduled jobs, webhook handlers, realtime gateways, edge handlers, and management handlers can share a pool, split per surface, or join named scale groups. The product topology declares the intent; the substrate connector realizes the native shape.
Manual horizontal scaling
Operators set desired instances inside canonical min / max bounds. The mutation is audited, idempotent, grant-checked, and exposed through dashboard, CLI, SDK, and API.
Autoscaling
Target tracking, step rules, scheduled windows, predictive strategies, queue-driven rules, cooldowns, hysteresis, and rollout/drain suspension all live in RuntimeScalingPolicy.
Load-balanced services
Managed public, managed private, and mesh-only load balancing express intent. Target groups, listeners, and provider handles stay connector-private.
Per-surface partitioning
Scale API ingress separately from event consumers. Keep scheduled jobs at one instance. Let realtime gateways follow connection pressure. Named groups let surfaces scale together when that is the correct topology.
Vertical resource policy
Declare CPU millicores, memory MiB, ephemeral or persistent storage, IOPS, network bandwidth, resource class, accelerator class, and edge-isolate budgets without leaking ECS, Kubernetes, or Cloud Run syntax.
Capability-aware matching
A substrate must explicitly advertise manual scale, autoscale strategy, metric support, partition modes, load balancing, resource classes, and accelerator classes before a project can bind to it.
Measures come from the Plane Capability Graph.
Runtime Fabric contributes workload resources, scale actions, autoscale triggers, and per-target measures to PCG. Built-in substrate metrics and custom project measures share the same semantic unit and freshness checks before they can drive scale.
Built-in metrics
CPU, memory, request rate, in-flight requests, latency p95 / p99, error rate, queue depth, consumer lag, saturation, and accelerator utilization are all capability-gated.
Custom PCG measures
Business measures can drive autoscale only when PCG proves semantic compatibility and a live production sample source exists for that target.
Native or runtime-enforced
ECS, Kubernetes, Cloud Run, and serverless substrates can use native autoscalers. Simpler substrates can opt into Vadyl-managed enforcement through the same SetDesiredCount contract.
Explainable decisions
Every scale-out, scale-in, skipped decision, cooldown, stale metric, governance denial, or capability mismatch carries a typed reason trace.
Governed budgets
Ancestor projects cap max instances, CPU, memory, storage, accelerators, autoscale strategies, public ingress, sticky sessions, protocols, and cumulative resource envelopes.
Vendor-neutral realization
ECS task definitions, Kubernetes requests, Cloud Run instance shape, Nomad resources, Fly machines, and edge isolates are translations of the same project policy.
Ingress, handlers, consumers, jobs, realtime
Substrate-native or runtime-enforced
CPU, memory, storage, GPU, edge budgets
No silent weaker realization
Declare scale as product intent.
Set the workload shape once. Runtime Fabric resolves the substrate, PCG explains the decision, governance caps the budget, and the dashboard, CLI, SDK, API, and automation plane all read the same scaling contract.