Erik Kristensen — Engineering Leader & Principal Engineer

The open source above is what I can show you. This is the work that mattered most and lives behind a login, described at the level of decisions and outcomes instead of internals.

Video production platform SANS Institute 20% faster turnaround · six figures saved/yr

Context: Course content is the product, and video production sits on the critical path for all of it. Turnaround time bounds how fast curriculum reaches students. The pipeline behind it was fifteen-year-old technology, delivered over a general-purpose CDN doing a job it was never designed for. Rendering alone consumed a full day of every production cycle.
My role: Architected the system and set the technical direction; my org built it.
Approach: A modernization, not a patch. Replace the aging production stack outright, move rendering onto hardware built to do it, and move delivery onto infrastructure actually built for video.
Outcome: Rendering went from a full day to roughly 70 minutes, which took that day back out of the schedule: a 20% reduction in content turnaround realized immediately, and editors keep the four days the editing itself actually takes. Six figures of savings a year alongside it, and a projected 50% reduction as the rest of the work lands.

Cyber range platform SANS Institute 50,000+ students/yr · aws, azure & gcp

Context: Realistic training environments — full networks, not toy labs — had to stand up and tear down on demand across hundreds of courses, at a volume nobody could shepherd by hand. What came before was hand-built and non-reproducible, and every environment shared one network entry point, so a single failure took access away from everyone at once.
My role: Led it and built it. A team of 3–4, and everything from the architecture to the delivery was mine. I’ve kept ownership of the platform through two promotions since, still shipping features and fixing bugs on it myself.
Approach: I used Kubernetes as a state machine and drove it with GitOps, so an environment became a declared desired state instead of a deploy script. That is what made targeting any cloud platform tractable. I designed the spec for how an environment gets built, the observability layer, and the deployment system, then built all three. Every environment arrives self-monitoring and self-alerting and federates its metrics into one central view, live and historical. I also owned the cloud account lifecycle strategy: accounts allocated, reclaimed, and sanitized deterministically between uses. That is what lets a course hand a student full administrative access to a real cloud account.
Outcome: 50,000+ students a year across AWS, Azure, and GCP, at a 95%+ environment build success rate. The failures that remain are transient cloud-provider faults absorbed by automatic retry, not manual recovery. Per-environment isolation replaced the shared entry point, so blast radius is one environment instead of the whole program.

Mobile device lab NowSecure 160+ devices · 4+ clusters

Context: App security testing is only trustworthy on real devices, so the entire product was bound to physical hardware at exactly the point it needed to scale like software. We already ran everything else in containers. The question was how to marry the two instead of picking one.
My role: Three of us built it. The architecture, the hardware design, the bootstrap layer, and the delivery were mine.
Approach: Took the design cue from GitLab and its runner model: a site registers itself and pulls work instead of being centrally administered. We built physical racks of device hardware and paired them with self-bootstrapping OS installs and Kubernetes, so a rack came up, joined, and managed itself. Devices became a checkout-able resource: request one, install the app, run the test, release it, all driven remotely, with nobody needing to be in the room with the hardware. That registration pattern is the one I carried forward into the range platform above.
Outcome: 4+ self-managing clusters and 160+ devices under continuous remote control, run by three people at high reliability. Each device sustained about two app analyses an hour, so the fleet ceiling sat somewhere near 320. We rarely pushed it that far: throughput was bounded by how long instrumenting an app actually takes, and the orchestration layer always had headroom above what the testing could consume.

I lead teams that build platforms that work. I build them too.

Software I maintain in the open

Systems I owned end to end

Load-bearing systems, and the teams behind them

Where I do my best work

Technical leadership

Organizational leadership

Let’s talk