Dev Infrastructure Roundup: Native Frontend Tooling, EC2 Nested Virtualization, Tailscale Peer Relays GA, Let's Encrypt DNS-Persist-01

Four noteworthy updates in the dev infrastructure space came out around the same time. Frontend tooling overhaul, EC2 virtualization expansion, VPN relay improvements, and TLS certificate operational improvements. The layers are all different, but they share a common thread: making developers’ daily work a little easier.

Migrating to Native Frontend Tools Also Improves AI Code Generation Quality

Christoph Nakazawa (cpojer), formerly of Meta, published an article on the benefits of replacing frontend development tooling with native language tools. The three recommended tools are:

tsgo

A Go port of the TypeScript compiler being developed by Microsoft (codename: Project Corsa). Announced by TypeScript creator Anders Hejlsberg in February 2025.

It achieves roughly 10x speedup compared to the traditional JavaScript implementation. Specifically, compiling the VS Code codebase (1.5 million lines) went from 89 seconds to 8.74 seconds. cpojer says he’s validated it over 6 months across 20+ projects ranging from 1,000 to 1 million lines, and it even found type errors that the JavaScript implementation missed.

It’s positioned as a type-checking-only replacement for tsc, leaving compilation to Vite or tsdown. In VS Code, it can be enabled with "typescript.experimental.useTsgo": true.

Oxfmt

A Rust-based formatter from the OXC project. It’s designed to match Prettier’s output, and any differences are treated as bugs (it passes about 95% of Prettier’s test suite).

It’s roughly 30x faster than Prettier and 2x faster than Biome, with import sorting and Tailwind CSS class sorting built in by default. Features that required separate plugin installation with Prettier work out of the box. It supports a wide range of languages: JavaScript/TypeScript, CSS, HTML, Vue, JSON, YAML, Markdown, GraphQL, and more.

Oxlint

Also from the OXC project, a Rust-based linter. It has 675+ built-in rules covering ESLint core, TypeScript, React, Jest, Unicorn, and jsx-a11y plugins.

Performance is 50-100x faster than ESLint for regular rules, and 8-12x faster even for type-aware rules (enabled via the oxlint-tsgolint package). Real-world benchmarks: vuejs/core at 2.5s vs 20.8s (8.2x), outline/outline at 4.4s vs 55.1s (12.4x).

cpojer’s @nkzw/oxlint-config follows an “Error, Never Warn” philosophy — warnings are treated as noise and everything is an error. Subjective style rules are excluded, focusing on preventing problematic patterns like banning instanceof, blocking console.log and test.only.

Connection to AI Code Generation

The interesting claim is that “fast tooling also has a positive impact on AI code generation quality.” When running the same code transformation on GPT-5.2 Codex with an empty Git repository versus a template with strict guardrails, the latter produced significantly better code with fewer bugs.

cpojer’s conclusion: “Both humans and LLMs do far better work in codebases with fast feedback loops, strict guardrails, and strong local inference.” In environments where linters and formatters are slow and often skipped, AI also tends to generate lower-quality code. The perspective that tooling speed directly impacts not just developer experience but also collaboration quality with AI is a novel one.

Amazon EC2 Now Supports Nested Virtualization

AWS has enabled Nested Virtualization on non-bare-metal Amazon EC2 instances. This was announced in stages from February 12 to 16.

Supported Scope

Only 8th-generation Intel instances from the C8i, M8i, and R8i families (including flex variants) are supported. Since microarchitecture features like VMCS shadowing are required, 7th-generation and earlier, AMD, and Graviton (ARM) instances are excluded. Instance sizes exceeding 192 vCPUs (m8i.96xl, etc.) are also unsupported.

Supported hypervisors are KVM and Hyper-V. VMware ESXi is not supported, likely due to licensing structure issues after the Broadcom acquisition.

Architecture

It operates in a 3-layer structure. L0 is the physical AWS infrastructure + Nitro hypervisor, L1 is the user’s EC2 instance (running KVM or Hyper-V), and L2 is the virtual machine created on L1. This is achieved by the Nitro system passing through Intel VT-x (including EPT) to the instance.

Enabling is possible via CLI:

aws ec2 run-instances \
    --instance-type r8i.4xlarge \
    --cpu-options "NestedVirtualization=enabled" \
    --placement "Tenancy=host"

Applying to existing instances requires stopping the instance. There’s no additional charge. Available in all commercial regions.

Comparison with Other Clouds

Item	Azure	GCP	AWS
Start date	2017	2017	2026
Hypervisor	Hyper-V	KVM only	KVM + Hyper-V
Supported generations	Wide range from v3+	Wide range from Haswell+	8th-gen Intel only

AWS enters about 9 years late. It surpasses GCP by supporting both KVM and Hyper-V, but has the narrowest range of supported instances.

Performance and Limitations

CPU-bound workloads can expect 5-15% degradation, with even greater degradation for I/O-bound workloads. Heavy processing like kernel builds has seen up to 50% degradation reported. Bare metal remains recommended for latency-critical use cases.

Note that enabling nested virtualization on Windows instances automatically disables Virtual Secure Mode (VSM), making security features like Credential Guard unavailable.

Use cases include virtualization testing in CI/CD pipelines, running WSL2 on EC2, Firecracker microVMs (cost reduction without bare metal), Android Studio emulators, and security research sandboxes.

Tailscale Peer Relays Reaches General Availability

Tailscale has launched general availability (GA) for Peer Relays. Peer Relays are customer-owned relay nodes that operate within a tailnet. When direct P2P connections between devices aren’t possible due to firewall or NAT constraints, they relay encrypted traffic.

Difference from DERP

Traditional DERP (Designated Encrypted Relay for Packets) is shared infrastructure managed by Tailscale, functioning as a last resort when NAT traversal is impossible. Peer Relays use customer-controlled nodes as high-throughput relay points and are positioned as complementary to DERP, not a replacement.

Connection priority order: Direct P2P > Peer Relay > DERP.

Performance

The real-world measurements between India and Minnesota published on the official blog are illustrative.

Connection Method	Throughput	Latency
Via DERP	2.2 Mbps	452ms
Via Peer Relay	27.5 Mbps	298ms
Direct Internet	31.1 Mbps	-

Roughly 12.5x throughput improvement and ~1/3 latency reduction compared to DERP. Performance nearly matches a direct internet connection.

The GA release adds lock contention improvements and traffic distribution across multiple UDP sockets via SO_REUSEPORT, improving performance in high-load scenarios on multi-core systems.

Setup

It’s built into the Tailscale client, so no separate process or Docker is needed. Setup is just opening one UDP port and running one command.

tailscale set --relay-server-port=40000

When running behind an AWS NLB or similar, specify a fixed IP:port with --relay-server-static-endpoints. Add a grant policy to ACL and you’re done. Requires Tailscale 1.86+. iOS/Apple TV/Android are not supported (due to NetworkExtension size limitations).

Security

Traffic is forwarded while remaining encrypted with WireGuard — relay nodes do not decrypt packets. Only devices within the same tailnet can use the relay, limited to devices with the tailscale.com/cap/relay capability granted via ACL.

Monitoring and Pricing

Prometheus metrics tailscaled_peer_relay_forwarded_packets_total and tailscaled_peer_relay_forwarded_bytes_total are exposed. tailscale ping can also test relay health and latency.

Available on all plans including the free plan, though the free plan is limited to 2 per tailnet. I’ve also written a previous article on exposing a local LLM as an external API via VPN as a Tailscale use case.

Let’s Encrypt Announces DNS-Persist-01

Let’s Encrypt has announced a new ACME challenge type called “DNS-PERSIST-01.” It was approved unanimously by 26 CAs as SC-088v3 at the CA/Browser Forum in October 2025 and formally adopted by the IETF ACME Working Group.

The Problem with DNS-01

The traditional DNS-01 challenge required publishing a temporary TXT record to _acme-challenge.<domain> for every certificate issuance and renewal. DNS API credentials were needed for each renewal, spreading those credentials across the entire issuance pipeline. This was a significant operational burden for IoT devices, multi-tenant platforms, and security-conscious Kubernetes environments.

How DNS-PERSIST-01 Works

Set a TXT record at _validation-persist.<domain> just once. The record contains the CA identifier and ACME account URI.

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"
  " policy=wildcard;"
  " persistUntil=1767225600"
)

Once set, no DNS changes are needed for subsequent certificate issuance and renewal. The security focus shifts from protecting DNS write access to protecting the ACME account key.

policy=wildcard extends the authorization scope to the domain itself, wildcards, and matching subdomains. The persistUntil timestamp (UNIX epoch seconds) sets an expiration, defaulting to indefinite if omitted. Multiple CAs can be authorized simultaneously by placing multiple TXT records at the same label.

SC-088v3 sets the validation reuse period to a fixed 10 days. This was complicated with DNS-01 due to record TTL considerations, but has been simplified to apply uniformly regardless of TTL.

Security Tradeoffs

With DNS-01, DNS credential theft was the attack vector. With DNS-Persist-01, ACME account key compromise becomes the primary risk. If the key is compromised, unauthorized issuance is possible until the persistUntil deadline (indefinitely if not set). On the other hand, the attack surface for credential management is reduced since DNS write permissions no longer need to be distributed across the entire issuance flow. Combined use with DNSSEC validation is recommended.

Timeline and Client Support

October 2025: SC-088v3 approved, IETF adoption
Current: Test environment Pebble already supports it
Late Q1 2026: Staging environment
Q2 2026: Production environment

Among ACME clients, the Go-based lego is leading implementation efforts. cert-manager is also tracking via a GitHub Issue. certbot and acme.sh are expected to follow after production launch.

Environments with high DNS update costs benefit the most: infrastructure managed with Terraform or Pulumi, IoT device certificate management, and large-scale domain operations on multi-tenant platforms.