Infrastructure as a product constraint

At Unraid, cloud infrastructure sits directly under user trust. Sign-in, license state, remote access, server communication, purchase flows, support tooling, and onboarding all depend on infrastructure choices that users only notice when something breaks. I led modernization work that tied short-term reliability fixes to a longer-term architecture, and owned the change planning that made each piece safe to ship.

A redirect loop is not just an auth bug. It is a user locked out of their account. A slow license lookup is not just a backend performance issue. It is a longer support call. A flaky WebSocket service is not just ops pain; it decides whether remote product features feel dependable. That framing drove every infrastructure decision below.

What I modernized

• Identity at scale. I planned the migration of more than 70,000 accounts through AWS Cognito, including the OIDC proxy and forwarded-header handling so sign-in behaved correctly behind infrastructure layers, plus session fixes across account surfaces.
• Key signing, key management, and DNS systems. I worked across cloud services that back the product: ECS Service Connect and scaling, Graviton multi-arch rollouts, DNS rollout controls, wildcard certificate handling, and deployment hardening needed to make those changes safe. In 2026 I drove the DNS infrastructure modernization itself — PowerDNS 5, fully Terraform-managed — and the IPv6 myunraid.net certificate rollout, shipped with guarded DNS changes, CloudWatch monitoring, and a written rollback plan.
• WebSocket fleet scaling. For Mothership — the gateway holding tens of thousands of live server connections — I built a node-driven autoscaling controller with memory-led scaling and RSS overload protection, a deploy prewarm system so rollouts don’t stampede reconnections, Traefik-based ECS service discovery, and load-test harnesses for the remote-query and WebSocket paths. The same pass cut CloudWatch metrics spend materially.
• Service architecture. I moved older EC2-style deployments to containerized service patterns where the old shape was creating avoidable ops friction. The architecture is sized for tens of thousands of WebSocket-connected clients, with Redis-backed lookups for read-heavy license and support paths.
• Customer-status responses. I rewrote client-side license, trial, and download denial responses so users and support see why a denial happened instead of an opaque error.
• Deployment pipeline. I sped up account-app builds, added preview deploys for documentation, and wrote beta release docs so engineers shipping infrastructure changes had a faster inner loop and a clear paper trail.

Cloud change management I ran

I treated infrastructure changes like product releases. Every meaningful change had to answer the same practical questions: what changes, what can go wrong, what customers might notice, how support should respond, how we validate, how we communicate, and how we roll back. Examples I owned or drove include:

• Moving Forums to a hosted IPS cloud. I built a risk register, validation plan, support-readiness path, customer-communication plan, and rollback strategy for a migration that touched a core community surface.
• Craft 5 upgrade for the marketing site. I documented migration risks, validation criteria, support expectations, and rollback planning for a high-visibility web platform change.
• Deprovisioning legacy Craft AWS infrastructure. I removed the Craft preview and production instances from Terraform after the move to Craft Cloud. Modernization is partly cleanup; turning things off, not just standing things up.
• Hardening internal tooling access. I moved operational tools through a change-management process that covered operator access, validation, and continuity for support workflows.
• Safer Account and Connect-server callbacks. I shipped callback routing changes through a documented rollout and rollback plan.
• Hardening legacy key-management paths. I worked through client compatibility, routing, and validation so older paths could be tightened without breaking supported product flows.
• Renewing the code-signing path. I coordinated release-infrastructure ownership and signing continuity so the USB Flash Creator path stayed reliable.

Cost and reliability work

Cloud modernization also meant cost discipline without cutting product capability. I moved flash-backup storage to AWS EFS Intelligent-Tiering, shifting older objects to infrequent access for material monthly savings without changing the backup experience. I also coordinated security assessment and cloud-posture review work so reliability, cost, and security decisions landed in one plan instead of competing for attention.

How I ran the work

The thread tying all of this together is treating infrastructure changes like product releases. Every change answers the same questions: what will users experience, how will support recognize an issue, what does success look like after deploy, what gets measured, and how do we roll back if an assumption is wrong?

That model changes the shape of execution. A migration becomes a sequence of validated changes. Support expectations land before release, not after. Session, redirect, cache, and license-state behavior get tested from the user’s point of view, not just the service owner’s.

Outcome

This modernization opened a clearer path for scaling Unraid’s cloud services without tying every product improvement to fragile infrastructure. Identity, account, license, remote access, and support workflows are easier to reason about because boundaries are explicit, rollout knowledge is written down, and cost and observability work run in one plan.

The practical value is reliability users do not have to think about. They sign in, see the right account state, use remote features, activate products, and get support when an edge case appears. Internally, the team has release gates, incident context, and a roadmap for replacing brittle pieces with systems that match the product’s growth.

Cloud infrastructure is easy to understate on a portfolio page, since a lot of the best improvements are invisible. That’s most of what this work was: making the pieces under the visible product a bit more dependable.