Sheldon Lewis

Projects / operating notes

Projects shaped by what happens after the first build.

Public and personal systems where maintenance, recovery, performance, access, and hardware behavior are part of the design.

Registry Control Plane operator interface showing registry access and daily control surfaces.

01 · Self-hosted registry operations

Active · Public project

Registry Control Plane

A management layer for Docker Distribution that makes routine access, cleanup, and maintenance work repeatable.

The operating problem

The standard registry path works well for image distribution, but routine operator work still spills into scripts, direct API calls, and one-off cleanup steps.

Design decision
I left Docker Distribution in the data path and added a separate management layer for credentials, repository access, cleanup, maintenance mode, and repeatable operator workflows.
Current state
The source is public and packaged for repeatable deployment. I continue to refine the performance and interface paths used in day-to-day operation.
View sourcePerformance notesInterface notes

Ongoing systems work

The useful details show up while operating the system.

These projects stay intentionally open-ended. The notes record what changed, what failed, and which constraint became decisive.

  1. 02

    Local AI infrastructure

    Active · Experimental

    Local AI infrastructure on AMD hardware

    A 128 GB AMD Strix Halo system serves as a local lab for model serving, orchestration, retrieval, coding agents, and tool use.

    Problem
    A model can fit within the available memory and still behave poorly when the loader, memory mapping, and unified-memory architecture interact in the wrong way.
    Approach
    I isolate one variable at a time, observe the host rather than only the model server, and keep the findings scoped to the exact hardware and workload under test.
    Result
    In one controlled 32K text-only run, disabling memory mapping reduced the measured load time to 18.36 seconds.

  2. 03

    Network systems

    Active · Personal infrastructure

    OpenWrt and network systems

    OpenWrt provides direct control over reliability, recovery, and network arrangements that consumer router interfaces do not expose.

    Problem
    Firmware work becomes fragile when upstream image builders are overloaded or when the build path hides the details needed for diagnosis and recovery.
    Approach
    I run the OpenWrt Attended Sysupgrade builder locally, with container behavior, retries, diagnostics, and network access kept explicit.
    Result
    The local builder keeps firmware generation available when upstream capacity is constrained and makes the failure path easier to inspect.

  3. 04

    Personal infrastructure

    Ongoing · Private systems

    Self-hosting, delivery, and recovery paths

    I maintain a small collection of hosts, containers, runners, and network services where deployment and recovery matter as much as initial setup.

    Problem
    Personal infrastructure still needs an answer for failed hosts, inaccessible networks, temporary capacity, stale build cache, and the awkward moments when the normal control path is unavailable.
    Approach
    I use repeatable container builds, runner-based recovery, bounded temporary access, explicit cleanup, and written operating notes instead of relying on memory.
    Result
    The result is an environment I can change deliberately and recover without turning every incident into a rebuild.

Project log

The notes record the work.

Investigations, performance measurements, recovery paths, and the implementation details that are too useful to flatten into a card.

Browse all notes