Native bootstrap

The bootstrap: key of the configuration file accepts the same resources as envoy_bootstrap:, but in Arion's own serialization — the shape of its internal configuration model, without the Envoy field names and conversions.

envoy_bootstrap is the canonical dialect used throughout this documentation; this page is the only one that documents the native form. A file may set one of the two keys, never both. Everything Envoy-shaped that Arion accepts is listed in the supported-configuration matrix; the native form can express exactly the same set, no more.

Top-level keys

Field	Type	Required	Default	Description
`static_resources`	object	no	empty	`listeners`, `clusters` and `secrets`, in native shapes.
`dynamic_resources`	object	no	unset	`grpc_cluster_specifiers`: a list of cluster names to reach the xDS control plane, replacing Envoy's `ads_config.grpc_services`.
`node`	object	no	unset	xDS node identity: `id` and `cluster_id` (Envoy's `node.cluster`).
`admin`	object	no	unset	Admin interface; `address` is the listening socket.
`stats_flush_interval`	object	no	unset	Flush interval for stats sinks, as `secs` and `nanos` fields (not a duration string).
`stats_sinks`	list	no	`[]`	Stats sinks; the OpenTelemetry sink with `grpc_service` and `prefix`.

Example

bootstrap:
  node:
    id: arion-1
    cluster_id: edge
  dynamic_resources:
    grpc_cluster_specifiers: [xds]
  static_resources:
    clusters:
      - name: xds
        static:
          cluster_name: xds
          endpoints:
            - Socket:
                - 127.0.0.1
                - 50051
        connect_timeout: 250ms

How the native form differs

Field names follow the internal model. For example node.cluster_id instead of node.cluster, dynamic_resources.grpc_cluster_specifiers instead of the nested ads_config.grpc_services block, and a cluster's discovery type appears as a key (static:, strict_dns:, EDS:, ORIGINAL_DST:) holding its settings instead of type: plus load_assignment:.
Enums are single-key maps inside static_resources (as in the Socket: address above) and YAML tags elsewhere.
Endpoint lists are simplified: a single priority-0 group of healthy, weight-1 endpoints is written as a plain list of addresses; the full priority / lb_endpoints form is also accepted.
Parsing is plain serde, not the strict protobuf mapping used inside envoy_bootstrap, so only the exact native field names are accepted — there are no camelCase aliases.

The authoritative rendering of any configuration in the native form is the admin interface: GET /config_dump returns the running configuration in exactly this serialization, as JSON. Load a config via envoy_bootstrap and read /config_dump to see its native equivalent — see the admin API.

Prefer envoy_bootstrap unless you have a tool that produces the native form. The Envoy dialect is what the examples, guides and reference pages on this site use, and it round-trips through the same internal model.

Top-level keys

Example

How the native form differs

Reference and guides