chore(deps): consolidate remaining major dependency updates

[dylanratcliffe]

Summary

Consolidates all 8 remaining open Renovate PRs into a single update, with the necessary migration fixes to make everything build cleanly.

Dependency updates:

• react, react-dom: ^18 → ^19
• react-router-dom: ^6 → ^7
• date-fns: ^3 → ^4
• typescript: ^5 → ^6
• vite: ^7 → ^8, @vitejs/plugin-react-swc: ^3 → ^4
• eslint: ^9 → ^10, @eslint/js: ^9 → ^10
• eslint-plugin-react-hooks: ^5 → ^7

Migration fixes required for compatibility:

• Switched PostCSS plugin from tailwindcss to @tailwindcss/postcss (required by Vite 8)
• Updated CSS to use @import "tailwindcss" syntax (Tailwind v4)
• Inlined card-elevated styles into card-interactive (@apply can't reference custom component classes in Tailwind v4)
• Replaced removed Github icon with GitBranch (lucide-react v1 dropped brand icons)
• Converted require("tailwindcss-animate") to ESM import in tailwind config

Supersedes: #479, #480, #483, #487, #490, #495, #499, #506

Test plan

• vite build passes
• Verify app renders correctly in browser
• Smoke test routing (react-router-dom v7)
• Verify date formatting still works (date-fns v4)

Made with Cursor

[github-actions]

Open in Overmind ↗

---

model|risks_v6
✨Encryption Key State Risk ✨KMS Key Creation

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple compute resources showing unusual weekly changes at 1 event/week for the last 2-3 months, which is infrequent compared to typical patterns.

View signals ↗

---

🔥 Risks

Updating the sole ALB backend EC2 instance will drop the load balancer to zero healthy targets ‼️High Open Risk ↗
This change updates two production EC2 instances whose public endpoints are auto-assigned rather than backed by stable Elastic IPs. One of them, i-09d6479fb9b97d123, is the only currently registered healthy target in ALB target group api-207c90ee-tg. If the update path requires a stop/start or otherwise interrupts the instance, AWS can reassign its public IPv4 and the ALB will temporarily have zero healthy backends while the instance restarts and re-registers.

That will take the api-207c90ee-alb service offline and fire the unhealthy-target alarm. The second changed instance, i-0464c4413cb0c54aa, is directly exposed on its own public IP and EC2 hostname with no load balancer abstraction, so any consumer or operational tooling pinned to 18.175.147.19 or its ec2-*.compute.amazonaws.com name will break when the auto-assigned address changes. The Route53 health checks mentioned in the hypothesis are already failing against different hard-coded IPs, so they do not change the mechanism, but they do show this public-endpoint design is already fragile.

EC2 stop/start will rotate public endpoints and break consumers pinned to the current instance IPs ❗Medium Open Risk ↗
The two EC2 instances being updated, 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa, show no planned changes to AMI, instance type, IAM profile, subnet, security groups, or EBS attachments. However, both diffs do show public_ip and public_dns becoming (known after apply), which is consistent with an EC2 stop/start path rather than an in-place no-op.

If apply stops and starts these instances, AWS will assign new public IPv4 addresses and public DNS names while keeping the existing ENIs, private IPs, and root volumes. Anything still using the current public endpoints such as 35.179.137.86 / ec2-35-179-137-86.eu-west-2.compute.amazonaws.com or 18.175.147.19 / ec2-18-175-147-19.eu-west-2.compute.amazonaws.com will lose connectivity immediately after the restart. Internal traffic through the ALB to i-09d6479fb9b97d123 should continue, but any direct public access paths, scripts, or monitors pinned to the old instance addresses will fail.

---

🧠 Reasoning · ✔ 2 · ✖ 1

Opaque EC2 instance updates risking hidden compute/IAM/network config changes

Observations 4

Hypothesis

EC2 instance updates with empty Terraform or API diffs can still change core compute configuration, including AMI, instance type, IAM instance profile, and network/security attachments. For instances such as i-09d6479fb9b97d123 and i-0464c4413cb0c54aa, an update that involves stop/start or replacement can:

• Switch to an AMI with different patch level or architecture, violating hardening and performance best practices (e.g., aws-compute-configuration, SEC6, PERF02).
• Remove or replace the IAM instance profile (e.g., api-207c90ee-api-role), causing loss of AWS API access, S3/Secrets Manager/CloudWatch permissions, and SSM/CloudWatch Agent functionality.
• Alter security group and network interface attachments, impacting allowed ingress/egress paths.
  Because the diff is empty, these changes may not be visible in IaC, so the change plan must explicitly confirm preservation of AMI baseline, instance type, IAM role/profile, security groups, subnet, and attached volumes for all updated instances.

Investigation

Evidence Gathered

I first checked the relevant organizational knowledge for compute, IAM, network, availability, infrastructure notes, and security/compliance. The most relevant guidance was that EC2 instances without stable private-only networking and direct public IP exposure are already non-ideal, but more importantly for this change, stop/start of EC2 instances can change public addressing while preserving ENIs, private IPs, EBS volumes, and IAM instance profiles unless those are explicitly changed.

I then queried the full planned diffs for both updated instances. For both 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa, the only planned diff is public_dns and public_ip moving from concrete values to (known after apply). There are no planned diffs for AMI, instance type, subnet, security groups, ENIs, root volume, or IAM profile attachment.

Blast-radius inspection confirms the current state of i-09d6479fb9b97d123: AMI ami-076e6b911c0417157, instance type c5.large, private IP 10.0.101.11, subnet subnet-07b5b1fb2ba02f964, security group sg-0b35287bf0a8a338c, root EBS volume vol-090e750179b5fa681, and IAM instance profile api-207c90ee-api-profile via association iip-assoc-0f7f3d615aaa03f46. The target is currently healthy in ALB target group api-207c90ee-tg on port 80. For i-0464c4413cb0c54aa, blast radius shows AMI ami-076e6b911c0417157, instance type t3.nano, private IP 10.0.101.133, subnet subnet-07b5b1fb2ba02f964, root volume vol-0a61278f4602fc12b, and notably no IAM instance profile at all.

I also checked AWS documentation. AWS documents that rebooting an EC2 instance preserves public IP and DNS, but stopping and starting an instance typically migrates it to a new host and assigns a new public IPv4 address and public DNS name, while attached EBS volumes, ENIs, private IPs, and associated IAM instance profile attachments persist. AWS further documents that when an instance is started again, the associated network interfaces are reattached and the private IPv4 address persists. That means the hypothesis' broad concern about hidden AMI, instance type, IAM, SG, subnet, and volume mutation is not supported by the actual change or by EC2 stop/start behavior; however, public IP/DNS churn from stop/start is a real closely related mechanism visible in this plan.

Impact Assessment

There are 2 directly affected EC2 instances in this change: i-09d6479fb9b97d123 and i-0464c4413cb0c54aa. The confirmed downstream dependency in blast radius is the ALB target registration for i-09d6479fb9b97d123 in target group api-207c90ee-tg; that dependency uses the instance ID and private networking path on port 80, so ALB-to-instance traffic should continue after stop/start. The root EBS volumes and primary ENIs also remain attached, so storage and private addressing should not break.

The operational impact comes from the two instances' ephemeral public endpoints. Both instances currently have AWS-assigned public IPs and public DNS names, and the plan shows those values becoming unknown until apply. AWS documentation makes this significant: if the apply path stops and starts either instance, each affected instance will receive a new public IPv4 address and public DNS name. That will invalidate any consumer, script, monitoring target, manual access path, or external integration that still points at 35.179.137.86 / ec2-35-179-137-86.eu-west-2.compute.amazonaws.com for i-09d6479fb9b97d123, or 18.175.147.19 / ec2-18-175-147-19.eu-west-2.compute.amazonaws.com for i-0464c4413cb0c54aa. The scope is limited to dependencies using those public endpoints; internal connectivity via private IPs and ALB health checks should remain intact.

Conclusion

Risk is real. The specific hypothesis about hidden AMI, IAM profile, security group, subnet, or volume changes is not supported, but the same concern area of EC2 update side effects does reveal a real and narrower risk: this change can rotate the instances' public IP and DNS during stop/start, breaking anything that depends on those ephemeral public endpoints.

✔ Hypothesis proven

---

ALB, Route53, and direct public endpoint connectivity/reliability risk from EC2 and IP updates

Observations 15

Hypothesis

Updating or replacing EC2 instances that are directly exposed or registered behind an ALB can disrupt service connectivity and reduce reliability while also widening network exposure. For instance i-09d6479fb9b97d123 in internet-facing ALB target group api-207c90ee-tg, an update may:

• Change instance ID or IP so targets are deregistered or fail health checks, reducing healthy target count and impacting availability via the ALB.
• Alter security group and ENI attachments (e.g., involving sg-0ac525af0d472d9bf and ENIs eni-0042..., eni-0e15...), leading to ALB backend connectivity loss or unintended ingress/egress paths.
• Break or change security group relationships between frontend and database tiers (e.g., between sg-0b35287bf0a8a338c and sg-0fe38b77fda090133), while the DB SG also has broad 0.0.0.0/0 egress, compounding network-security risk (SEC05-BP02).
  Route53 health checks (e.g., b3fb0a5c-a7bb-49fb-8382-914c06cd730a probing HTTPS /health on IPs such as 44.207.52.17 and 13.134.236.98) and CloudWatch alarms tied to those checks depend on instance reachability and stable addressing; instance updates can cause health-check failures, DNS failover, and paging if public IPs or service availability change.
  Separately, simultaneous public IP/hostname churn on two public-facing EC2 endpoints (e.g., 35.179.137.86 and 18.175.147.19 and their ec2-*.compute.amazonaws.com names) increases blast radius: there is no ALB/WAF/DNS abstraction in front, so any hardening mistake or propagation issue affects all externally reachable endpoints at once. External consumers, monitoring, and operational tooling that pin to current public addresses can silently break, and workflows relying on one instance as fallback for the other lose redundancy.
  The change plan should stage endpoint changes, confirm ALB target re-registration and health, validate security group and DB paths, review broad SG egress, and inventory any non-Terraform consumers (partner allowlists, probes, runbooks, alerts) that depend on current public IPs/hostnames or Route53 health checks. Consider placing these services behind managed edge protections (ALB + WAF, Route53-based DNS) instead of direct standalone EC2 endpoints. (REL02-BP01, REL02-BP03, SEC05-BP02, SEC05-BP03, REL06-BP03, OPS04-BP02)

Investigation

Evidence Gathered

I first checked the relevant organizational knowledge files for reliability and network/security requirements. Those standards explicitly say production workloads should avoid applying changes to all instances simultaneously without gradual rollout, and that EC2 instances must not be directly reachable from the internet. They also flag direct public EC2 endpoints as a reliability anti-pattern and broad security-group egress as a least-privilege concern.

I then examined the actual planned diffs. Only two resources are changing in this plan: EC2 instances 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa. In both diffs, the only explicit before/after change is public_ip and public_dns moving from concrete values to (known after apply). For EC2, AWS documents that auto-assigned public IPv4 addresses are released and replaced when an instance is stopped/started, and a new public IPv4 is assigned on start unless the instance uses an Elastic IP. AWS also documents that ALB target groups with target_type = instance register specific instance IDs and perform health checks against those instance targets, so replacement or downtime of the registered instance directly affects target health.

From blast-radius state, i-09d6479fb9b97d123 currently has auto-assigned public IP 35.179.137.86, sits behind ALB target group api-207c90ee-tg, and is the only target currently visible in that target group. The target group is instance-type on port 80 with /health checks, and the corresponding target-health record for i-09d6479fb9b97d123 is currently healthy. The ALB spans two ENIs and two Elastic IPs (16.60.242.196 and 13.43.201.81), so the ALB front end itself is multi-AZ and not being changed here.

The second changed instance, i-0464c4413cb0c54aa, is also publicly reachable directly at auto-assigned public IP 18.175.147.19 and public DNS ec2-18-175-147-19.eu-west-2.compute.amazonaws.com. It is not behind the ALB and is attached to a generic internet-access security group, so any public-IP churn on that instance affects direct consumers immediately because there is no load balancer or DNS abstraction shown in the change.

I also checked the Route53 health checks and alarms named in the hypothesis. Both Route53 health checks currently probe hard-coded public IPs (44.207.52.17 and 13.134.236.98) and both are already in HEALTH_ERROR due to connection timeouts. Those IPs do not match either of the two EC2 public IPs being changed in this plan (35.179.137.86 and 18.175.147.19) or the ALB Elastic IPs (13.43.201.81 and 16.60.242.196). So the hypothesis’s specific mechanism about this change breaking those particular Route53 checks is not supported by the evidence.

For network controls, the API instance security group sg-0b35287bf0a8a338c allows inbound port 80 only from the ALB security group and has explicit DB egress to sg-0fe38b77fda090133, but also has broad 0.0.0.0/0 egress. The database SG also has broad 0.0.0.0/0 egress. However, no SG diffs are part of this change, so there is no evidence that this plan is altering those relationships or widening exposure beyond the already-existing posture.

Impact Assessment

There are 2 directly affected production EC2 instances in this change: i-09d6479fb9b97d123 and i-0464c4413cb0c54aa.

For the ALB-backed path, the blast radius shows 1 currently registered target in api-207c90ee-tg: i-09d6479fb9b97d123 on port 80. That means the effective backend capacity behind api-207c90ee-alb is a single instance. If the in-place EC2 update requires a stop/start or otherwise interrupts the instance long enough for ALB health checks to fail, the target group will drop to 0 healthy targets. The direct consequence is complete outage for traffic coming through api-207c90ee-alb, along with UnHealthyHostCount alarm noise from api-207c90ee-unhealthy-targets. Because there is only one visible healthy backend, there is no redundancy to absorb even a routine instance restart.

For direct public access, i-0464c4413cb0c54aa currently exposes the service via the instance’s own public IP and EC2-generated hostname. If apply causes the auto-assigned public IP to change, any clients, allowlists, scripts, or monitoring that use 18.175.147.19 or ec2-18-175-147-19.eu-west-2.compute.amazonaws.com will break until they are updated. The same class of risk exists for i-09d6479fb9b97d123 at 35.179.137.86, but the higher-severity availability issue is the ALB path because a single target loss takes the whole load-balanced service down. The Route53 health-check portion of the hypothesis is not part of the blast radius impact here because the checks point at different IPs and are already failing independently of this change.

Conclusion

I conclude the risk is real. The hypothesis overreached on Route53 and security-group-change mechanisms, but the core concern is valid: this plan updates two production EC2 instances whose public addresses are auto-assigned, and one of them is the sole healthy ALB target, so an update that rotates its address or requires restart will cause complete ALB service outage and direct-endpoint churn for the standalone instance.

✔ Hypothesis proven

---

Root EBS volume lifecycle and data-loss risk during EC2 updates

Observations 2

Hypothesis

EBS root volumes attached to EC2 instances being updated are at risk of unintended detachment or deletion when updates involve stop/start or replacement. Volumes such as vol-0a61278f4602fc12b (root on i-0464c4413cb0c54aa with DeleteOnTermination=true) and vol-090e750179b5fa681 (root on i-09d6479fb9b97d123) may be deleted or reattached differently if the instance is terminated or replaced. If DeleteOnTermination is true or attachment semantics change, this can cause irreversible data loss or downtime for services relying on these disks. Change execution should confirm instance lifecycle actions, DeleteOnTermination flags, and that current snapshots/backups exist before proceeding, especially when diffs are empty but lifecycle operations are implied.

Investigation

Evidence Gathered

I first checked the relevant organizational guidance for compute, storage, availability, infrastructure notes, and security. The storage guidance says to flag EBS volumes used for critical data when they lack automated snapshots or backup schedules, but this hypothesis is specifically about this change causing root-volume deletion during an EC2 lifecycle action. The infrastructure quick reference also says these EC2 instances are part of Overmind’s own testing infrastructure and are often inexpensive, relationship-heavy test resources rather than business-critical services.

I then examined the planned diffs for both changed instances, 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa and 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123. The only planned attribute changes are public_dns and public_ip moving from concrete values to (known after apply). There is no diff showing a change to root_block_device, delete_on_termination, AMI, instance type, subnet, network interface, or any other attribute that would indicate instance replacement or root volume recreation.

I queried the current blast-radius state of both instances and both root EBS volumes. That confirmed each instance is currently EBS-backed with /dev/xvda root volumes and DeleteOnTermination: true, and the attached volumes are vol-0a61278f4602fc12b and vol-090e750179b5fa681. Both volumes are healthy and attached. I also checked target health for the load-balanced instance i-09d6479fb9b97d123, which is currently healthy behind the ALB.

Finally, I verified AWS and Terraform behavior in the documentation. AWS documents that when an EBS-backed EC2 instance is stopped and started, attached EBS root volumes persist and are reattached, while auto-assigned public IPv4 addresses are released and replaced on start. Terraform documentation and AWS behavior both support public_ip becoming (known after apply) without implying root-volume deletion or instance replacement.

Impact Assessment

The hypothesis names 2 root volumes and 2 EC2 instances, but the evidence does not show a lifecycle operation in this change that would delete or detach either root volume. The only concrete effect suggested by the plan is that these instances may get different public IPv4 addresses after apply. For i-09d6479fb9b97d123, there is 1 directly observed downstream dependency in blast radius target health, and it is registered healthy on port 80 today. There is no evidence that the ALB depends on the public IP; ALB-to-instance traffic typically uses the instance registration and private networking in the VPC.

So the realistic blast radius from the actual planned change is limited to public-IP churn on 2 instances, not loss of EBS-backed root disks. If Terraform performs a stop/start to reconcile computed networking attributes, AWS says the EBS root volumes persist across stop/start. If Terraform were planning a replacement, I would expect a replacement action or concrete force-new attribute diff, and none is present here. The organizational security guidance does identify a separate issue: both instances currently have public IPs, which is non-compliant, but that is unrelated to the hypothesis about root-volume deletion.

Conclusion

I conclude the risk is not real. The hypothesis points to generic EC2 root-volume deletion behavior, but the actual change only shows public IP/public DNS becoming recomputed, and AWS documentation is explicit that EBS root volumes persist across stop/start; there is no evidence of replacement, detach/recreate, or any root block device change in this plan.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 42

Edges 101

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 1 high risk requiring review

---

📊 Signals Summary

Routine 🔴 -5

---

🔥 Risks Summary

High 1 · Medium 1 · Low 0

---

💥 Blast Radius

Items 42 · Edges 101

---

View full analysis in Overmind ↗