Neuwerk

Cloud Rollout Integration

Understand how Neuwerk integrates with AWS ASGs, Azure VMSS, and GCP MIG-style replacements, including drain, readiness, and upgrade behavior.

Cloud rollout integration lets Neuwerk participate in cloud-managed replacement behavior while still enforcing traffic locally on each node.

It is designed for environments where node lifecycle is controlled by a managed group rather than manual VM replacement.

What The Integration Does

At a high level, integration mode coordinates with provider lifecycle behavior so rollout automation and Neuwerk health signals can align:

  • readiness is visible through Neuwerk health endpoints
  • replacement can honor drain windows
  • node-local enforcement stays explicit even while instances are replaced by the platform

Neuwerk remains a per-node dataplane and control-plane process. Integration mode does not create shared dataplane state.

Standalone VM Versus Managed Group

Standalone VM operation:

  • you replace, restart, and validate nodes directly
  • rollout sequencing is handled by your runbook
  • no managed group reconciliation loop is expected

Managed group operation:

  • the provider group decides when to create/replace instances
  • Neuwerk integration settings map node behavior to that lifecycle
  • readiness and drain behavior become rollout-critical signals

If you do not use an auto-replacing group, leave integration mode unset and operate as standalone VMs.

Provider Mapping

Use integration.mode in /etc/neuwerk/config.yaml to select provider semantics:

  • aws-asg
  • azure-vmss
  • gcp-mig

Pair that mode with provider-specific YAML fields in the matching integration.<provider> block.

Provider requirements for managed-group modes:

  • aws-asg: integration.aws.region, integration.aws.vpc_id, integration.aws.asg_name
  • azure-vmss: integration.azure.subscription_id, integration.azure.resource_group, integration.azure.vmss_name
  • gcp-mig: integration.gcp.project, integration.gcp.region, integration.gcp.ig_name

Configuration Model

Neuwerk now uses one primary runtime document:

  • /etc/neuwerk/config.yaml

Representative split:

  • bootstrap topology: bootstrap.management_interface, bootstrap.data_interface, bootstrap.cloud_provider
  • integration lifecycle: integration.mode, integration.aws.*, integration.azure.*, integration.gcp.*
  • dataplane/runtime tuning: dataplane.*, dpdk.*, tls_intercept.*

Prefer writing these values through cloud-init or startup metadata into /etc/neuwerk/config.yaml so first boot stays declarative and reproducible.

For the full YAML path reference and default values, read Runtime Configuration Reference.

For first-boot customization patterns that add config, files, certificates, helper scripts, or extra packages around that model, see Customize The Appliance Image At First Boot.

For production rollouts, use an image-first replacement pattern:

  1. publish and verify a new Neuwerk image release
  2. import or register that image in your cloud
  3. update the template/image reference used by ASG, VMSS, or MIG
  4. roll replacements gradually
  5. watch GET /ready, service logs, and drain behavior before increasing rollout speed

This keeps binary/runtime coupling aligned and avoids hand-mutating long-lived instances.

What Not To Do

Avoid these patterns:

  • do not treat managed-group replacement as a substitute for readiness checks
  • do not push fully expanded one-off Neuwerk command lines via metadata when a stable config.yaml is sufficient
  • do not roll the whole group at once without observing drain and readiness signals
  • do not mix unmanaged manual node edits with automated group replacement and expect deterministic outcomes

For hands-on bootstrapping flow, see Launch Neuwerk From The Released Cloud Image. For cluster-safe sequencing, see Upgrade A Cluster.