Skip to content
RuntimeForge [ runtimeforge_ ]

ENTRY 01 · SUBJECT: hero

Production infrastructure,
forged to spec.

For startups standing up their first real AWS. For growth-stage teams cleaning up the one that got away from them. For anyone who’d rather ship than explain a post-mortem.

Start a Conversation See the Forge
engagement-map.sh — runtimeforge:~

Operating Mode

Independent, hands-on, and allowed to use the right tool.

Typical Scope

First real AWS, inherited drift, security hardening, or whatever odd production edge case has already made itself your problem.

Preferred Start

Map the system, remove lies from the environment, then make the next engineer’s life less eventful.

signal.log — runtimeforge:~

$ tail -n 3 /var/log/runtimeforge/signal.log

  • [ok] no agency relay layer between conversation and implementation
  • [hot] repo showcase now uses the real public inventory instead of the polite shortlist
  • [note] terminal navigation is live because clicking around like it’s 2012 seemed avoidable

ENTRY 02 · SUBJECT: services

What I do, and who it's for.

Engagements are scoped to the problem, not packaged. Three kinds of work, most of them overlap.

  1. Lane 01

    First real AWS

    For early-stage startups

    You've been running on a single EC2 instance and a Heroku knockoff. You just closed a round, hired your second engineer, and production is held together with SSH sessions and hope. You need real infrastructure before you scale a bug into an incident.

    What that usually includes

    • Terraform foundations — VPCs, ECS, Aurora, ALB, Route 53, Secrets Manager — structured so your next hire can read it
    • Staging and production that are actually isolated — separate accounts, separate state, no shared credentials
    • GitHub Actions deploys you don't have to babysit
    • Documentation written for the engineer who joins six months from now
  2. Lane 02

    Clean up and move

    For growth-stage teams

    The infrastructure that got you to Series A isn't the one that gets you to Series B. There's drift between staging and prod, someone's personal AWS key is buried in a dozen Lambdas, the bill doubled last quarter for reasons nobody can fully explain, and the engineer who originally built it left eight months ago. You need an outsider who can map it, fix what's urgent, and leave your team owning it again.

    What that usually includes

    • Full infrastructure audit — what's running, what's costing, what's unpatched, what's unreachable
    • Cost optimization with actual math — savings plans, rightsizing, unused everything
    • Migrations that don't break production — Terraform adoption of existing resources, account splits, region moves
    • Handoff your team can work from — documentation, runbooks, and a pairing week if you want one
  3. Lane 03

    Security and hardening

    For teams after an incident, an audit, or a compliance ask

    You got a SOC 2 readiness checklist. Or an IAM account with 47 admin users. Or a Google Workspace tenant where 30 accounts had unauthorized secondary addresses added last Thursday. You need someone who's actually responded to these, not someone reading from a compliance template.

    What that usually includes

    • IAM review and least-privilege refactor — across accounts, across federated SSO
    • Secrets hygiene — rotation, storage, access trails, leak detection
    • Incident response — containment, scoping, eviction, post-mortem
    • Hardening passes on what you already have — Google Workspace, AWS, whatever's actually in scope

Not sure which lane? Start a conversation — we'll figure it out together.

Start a Conversation

ENTRY 03 · SUBJECT: forge

Things I've built.

Different problem domains, same habit: build the thing until it stops being vague and starts being useful.

// full inventory first, curation second. civilization survives another day.

inventory.sh — runtimeforge:~

Curation rule

Not all infrastructure, on purpose. The range matters more than pretending one toolchain contains a whole working life.

Signal

Every card uses last commit so the section doesn’t become a personality test about stars.

Inventory

Cloud, networking, firmware, embedded, ops automation, creative experiments, and one useful little market-data obsession.

  • ENTRY · NoSleep-Ops

    Last commit · 2026-03-26

    NoSleep-Ops

    python docker zeek suricata elk

    A detection lab for hostile traffic you would rather not generate in production. Sensible boundary, that.

    GitHub

  • ENTRY · FireRouter

    Last commit · 2026-01-27

    FireRouter

    rust networking routing systems

    A Rust networking build for when "the router is fine" is technically true and operationally nonsense.

    GitHub

  • ENTRY · dsl-asuswrt-merlin.ng

    Last commit · 2023-10-25

    dsl-asuswrt-merlin.ng

    firmware asuswrt-merlin router embedded

    Custom Merlin firmware for a DSL-AC68U, because discarded hardware and unsupported firmware make a miserable pair.

    GitHub Live

  • ENTRY · Marlin_corexy_SKR-Pro1.1_bltouch

    Last commit · 2023-05-23

    Marlin_corexy_SKR-Pro1.1_bltouch

    c++ marlin 3d-printing hardware

    A printer firmware fork to make a stubborn hardware stack behave without pretending upstream defaults were enough.

    GitHub

  • ENTRY · opscraft

    Last commit · 2025-06-27

    opscraft

    powershell automation ops tooling

    PowerShell utilities for repetitive infrastructure work that should have been one command three migrations ago.

    GitHub

  • ENTRY · Comicquant

    Last commit · 2026-01-23

    Comicquant

    typescript creative ui experiments

    A TypeScript experiment on the creative side of the desk, where structure and visual systems are allowed to have opinions.

    GitHub

  • ENTRY · ebay-sold-scrapper

    Last commit · 2026-04-20

    ebay-sold-scrapper

    javascript scraping market-data personal-tool

    A pricing tool built around sold listings, because asking prices are mostly fiction with better typography.

    GitHub

  • Full inventory

    See the full list on GitHub

    Everything else: one-offs, old firmware work, experiments, and the occasional useful mistake.

ENTRY 04 · SUBJECT: writing

Field notes from production.

War stories, IaC opinions, and post-mortems from real engagements. Names redacted, technical detail intact.

// filed for the Guide, not a deposition.

  • iac tooling · Draft

    When Terraform isn't the answer.

    Pulumi, CDK, Ansible, plain shell — and the project shapes where Terraform is actually the wrong pick. A working taxonomy for choosing which IaC tool fits a job, written for teams who’ve only ever used one of them.

    Read →
All entries ↗

ENTRY 05 · SUBJECT: about

One engineer. Real production. Right tool for the job.

I’m Dean Whitlock. RuntimeForge is my independent DevOps, cloud, and security practice. My day-to-day is hands-on — running production AWS environments on ECS, Aurora, ALB, Secrets Manager, and enough Terraform to stop being novel. I also administer Google Workspace, maintain home-networking firmware I actually use, and occasionally flash a 3D printer board at 2am because the upstream firmware is cowardly about BLTouch pin mappings.

The range is the point. A lot of consultancies will sell you whatever they happen to be good at. I’d rather pick the tool that fits the job and write the runbook so your team can own it after I leave. Sometimes that’s Terraform. Sometimes it’s Pulumi because you already have TypeScript engineers. Sometimes it’s fifty lines of shell because a Kubernetes operator is absurd overkill.

Independent, not an agency. You’re talking to the person doing the work. No sales team between us, no offshore handoff after the kickoff call, no “let me loop in our practice lead.”

// I have references. I just don’t have logos.

known_tools[]

terraform , pulumi , aws-cdk , ansible , kubernetes , github-actions , google-admin-sdk , asuswrt-merlin , marlin-firmware , nftables , wireguard , docker , elk-stack , cloudflare , caddy

// not exhaustive. right tool, not favorite tool.

Start a Conversation

ENTRY 06 · SUBJECT: contact

Start a conversation.

Paid pilots, scoped engagements, or an exploratory call — all fine. Reply time is one business day.

response window

Usually same day. Official answer: one business day, because optimism is not a process.

best fit

AWS cleanup, security hardening, Terraform reality checks, and odd infrastructure problems that have already annoyed at least three people.

preferred intake

Use the form for context, email for details, or book a call if calendars are already involved.

direct.sh — runtimeforge:~

$ ./direct --channels --availability

Short version: you are talking to the person doing the work. No intake maze, no account handoff, no decorative urgency theater.

engagement types

  • Scoped build or cleanup work
  • Audit and hardening passes
  • Production incidents and unpleasant Thursdays

email

phone

book a call

Kept behind a click because scheduling widgets do not need to be in the room until someone actually asks for one.

// loads Cal.com on click. nothing phones home before that.

contact.sh — runtimeforge:~

$ ./contact --from=you --to=runtimeforge

A few concrete details help: what is broken, what is risky, what already exists, and when it starts costing money or sleep.

> form relay not configured in this environment.

The form UI still validates locally. For an actual send, set PUBLIC_FORMSPREE_ID or use the direct-contact panel.

// the button below doesn't open a chatbot. a human replies. usually me.

No reload. No mystery workflow.

site-terminal.sh — runtimeforge:~

ENTRY · terminal

Slash opens it. Tab completes. Up and down walk history. When suggestions are visible, Ctrl+J and Ctrl+K move through them.

$ help

Available: help, services, forge, writing, about, contact, top, github, email, phone, book, clear, plus a few that are better discovered than advertised.

Try services, forge, contact, or github.