You're right that Envoy's config feels programmatic, and that's precisely why it's a liability for static mTLS. That snippet's `common_tls_context` will force you to embed your entire CA certificate as a YAML multiline string. It's not just heavy, it creates an artifact that's difficult to verify for integrity because the meaningful bytes are buried in YAML escaping.

If runtime integrity is a concern for your agents, consider this: you could cryptographically sign your NGINX config file and have the proxy itself validate that signature before applying it. It's a few lines of Lua to check an Ed25519 signature. With Envoy's YAML, the operational overhead to achieve the same sealed-configuration guarantee is significantly higher. The "programmatic" nature works against attestation.

You're zeroing in on the right pain point with the snippet cutting off at `common_tls_context`, but the risk isn't just the YAML bloat. It's that this programmatic structure subtly pulls you toward treating the config as an API, not a policy artifact. For a static allow list, you're now debugging protobuf schema compatibility instead of a straightforward `ssl_verify_client on`.

If you're truly small-scale, why inherit Envoy's control-plane assumptions? The "granular security controls" you mention often just mean more knobs to misconfigure. A hardened NGINX config with a simple `map $ssl_client_s_dn $allowed` block for SNI matching gives you the same explicit allow list, and you can log the entire handshake failure in one line.

That said, if your Flask agents ever need to do protocol-aware routing - like sniffing for a specific HTTP/2 header - Envoy's filters might justify the complexity. But for mTLS egress? You're paying for a Ferrari to drive 25 mph.

You cut the snippet at the worst possible line. That `common_tls_context` is where you'll be embedding your entire CA cert as a YAML multi-line literal block, and it's a nightmare to manage.

You said your setup is small-scale and complexity is a concern. That's your answer right there. Envoy's granular controls are useless overhead if you just need static mTLS with an allow list. The "programmatic" feel is a trap. You'll spend more time debugging YAML indentation and proto schema versions than you will securing traffic.

Go with NGINX. Use `ssl_verify_client on;` and a `map` for SNI allow-listing. You'll have a single, auditable config file. If you ever actually need dynamic CA rotation, you can revisit it, but you're avoiding an entire control plane's worth of moving parts for a problem that fits in ten lines of config.

You cut the snippet at the worst possible line. That `common_tls_context` is where you'll be embedding your entire CA cert as a YAML multi-line literal block, and it's a nightmare to manage.

You said your setup is small-scale and complexity is a concern. That's your answer right there. Envoy's granular controls are useless overhead if you just need static mTLS with an allow list. The "programmatic" feel is a trap. You'll spend more time debugging YAML indentation and proto schema versions than you will securing traffic.

Go with NGINX. Use `ssl_verify_client on;` and a `map` for SNI allow-listing. You'll have a single, auditable config file. If you ever actually need dynamic CA rotation, you can revisit it, but you're avoiding an entire control plane's worth of moving parts for a problem solved by a daemon from the early 2000s.