Starship Resource Management: Configuring CPU and Memory for Blockchain Nodes

Starship supports CPU and memory resource management through Helm chart values that define defaults in values.yaml and allow per-node overrides in chain configurations using standard Kubernetes resource notation.

Starship by hyperweb-io/starship orchestrates blockchain infrastructure as Kubernetes StatefulSets, requiring precise resource allocation to ensure nodes perform reliably under load. The Helm chart provides comprehensive resource management capabilities that let you define compute limits globally for all nodes or customize them per-chain using Kubernetes-native syntax.

Default Resource Limits in values.yaml

Starship defines baseline CPU and memory allocations in starship/charts/devnet/values.yaml. These defaults ensure nodes can run on low-resource clusters while maintaining stability.

The global defaults are:

• Node (validators, full-nodes, relayers): 0.5 CPU, 500M memory
• Wait init-container (used by devnet.init.wait helper): 0.1 CPU, 100M memory
• Exposer (API gateway): 0.2 CPU, 200M memory

These values are defined at lines 17-23 (node), 24-25 (wait), and 31-33 (exposer) of the values file. When you deploy without custom configuration, every blockchain pod receives the node defaults of 0.5 CPU cores and 500 MiB RAM.

Resource Injection via Helm Helpers

The chart dynamically injects resource blocks using the devnet.node.resources helper defined in starship/charts/devnet/templates/_helpers.tpl (lines 52-58). This template implements a fallback mechanism:

{{- define "devnet.node.resources" }}
{{- if hasKey .node "resources" }}
{{- include "getResourceObject" .node.resources }}
{{- else }}
{{- include "getResourceObject" .context.Values.resources.node }}
{{- end }}
{{- end }}

The logic checks if a specific chain definition contains a resources key. If present, it uses those values; otherwise, it falls back to the global defaults from values.yaml. This helper is invoked throughout the chart templates, such as in starship/charts/devnet/templates/chains/cosmos/validator.yaml at line 70, where it populates the container spec:

resources: {{- include "devnet.node.resources" ( dict "node" $chain "context" $ ) | trim | nindent 12 }}

Per-Chain Resource Overrides

You can override global defaults for specific chains by adding a resources block to your chain configuration. This supports standard Kubernetes resource notation including millicores (2000m) and binary/MiB suffixes (2048Mi).

For example, the Solana test configuration in starship/tests/e2e/configs/solana.yaml (lines 13-16) allocates 2 CPUs and 2 GiB RAM:

chains:
- id: solana
  name: solana
  numValidators: 2
  resources:
    cpu: 2000m          # 2 CPUs

    memory: 2048Mi      # 2 GiB RAM

Additional examples from the test suite demonstrate flexibility:

• cpu: "0.5" in starship/tests/e2e/configs/one-chain.yaml (lines 15-17)
• cpu: "0.2" in starship/tests/e2e/configs/simapp.yaml (lines 19-21)

Practical Configuration Examples

Overriding Resources in Custom Values

Create a custom values file to allocate 1 full CPU core and 1 GiB RAM to Cosmos Hub validators:

# custom-values.yaml

chains:
  - id: cosmoshub
    name: cosmoshub
    numValidators: 3
    resources:
      cpu: "1"          # 1 full CPU core

      memory: "1Gi"     # 1 GiB RAM

Deploy with:

helm install starship ./starship/charts/devnet -f custom-values.yaml

Querying Effective Resources

Verify the applied resource limits after deployment:

kubectl get statefulset cosmoshub-validator -o yaml \
  | yq '.spec.template.spec.containers[].resources'

The output displays either your custom overrides or the chart defaults, confirming the scheduler will enforce the specified limits.

Summary

• Default allocation: Nodes receive 0.5 CPU and 500M memory unless overridden.
• Global configuration: Modify starship/charts/devnet/values.yaml to change baseline resources for all nodes.
• Per-chain precision: Add resources blocks to individual chain definitions for workload-specific allocation.
• Kubernetes native: Supports standard notation including millicores (2000m) and memory suffixes (1Gi, 2048Mi).
• Template injection: The devnet.node.resources helper automatically applies the correct resource block to StatefulSet specs.

Frequently Asked Questions

What are the default CPU and memory limits for Starship nodes?

By default, Starship allocates 0.5 CPU cores and 500 MiB of memory to each blockchain node (validators, full-nodes, and relayers). The wait init-container receives 0.1 CPU and 100M memory, while the exposer service gets 0.2 CPU and 200M memory. These defaults are defined in starship/charts/devnet/values.yaml to ensure compatibility with low-resource development clusters.

How do I increase resources for a specific blockchain node?

Add a resources block to your chain definition in the values file. Specify cpu and memory using Kubernetes resource notation. For example, setting cpu: "2000m" and memory: "2048Mi" allocates 2 CPU cores and 2 GiB RAM to that specific chain's nodes, overriding the global defaults defined in the Helm chart.

Can I use fractional CPU values like 0.5 or 500m?

Yes. Starship supports standard Kubernetes CPU notation. You can use fractional values like "0.5" (half a core) or millicore notation like "500m" (equivalent to 0.5). Both formats are valid in the resources.cpu field and are passed directly to the Kubernetes scheduler through the Helm templates.

Where does Starship inject resource limits in the Kubernetes manifests?

Resource limits are injected into the container specs of StatefulSets through the devnet.node.resources Helm helper. This helper is referenced in node templates such as starship/charts/devnet/templates/chains/cosmos/validator.yaml at line 70, where it renders the resources field in the pod specification based on either per-chain overrides or global defaults.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}