KanterLabs

Developer tools, self-hosted platforms, and practical software, built with the infrastructure to run them.

Featured · Projects · Infrastructure · How we work

KanterLabs is an independent product and infrastructure studio founded and operated by Shane Kanterman. The work spans Linux systems, networking, continuous delivery, developer tooling, and user-facing applications, with an emphasis on clear boundaries, repeatable operations, and honest documentation.

Every game at a glance. Live games first, with the clock, down and distance, possession, and red-zone tags. Fresh scores flash for 30 seconds.	A gamecast drawn on the field. Passes and kicks fly in arcs, runs travel the turf, and banners call out touchdowns, turnovers, and sacks as they happen.
Play by play. Every play grouped by drive, with colored type tags and yards gained or lost.	Box score. Points by quarter, scoring plays, team stat comparisons, and the leaders.

Frosted liquid-glass styling, animations drawn with Cairo, and no account, no API key, and no tracking. It only fetches data while the popup is open.

git clone https://github.com/KanterLabs/nfl-scores.git && cd nfl-scores && make install

View NFL Scores on GitHub →

Projects are at different stages of development. Each repository's README is the source of truth for its current status, supported platforms, and usage.

KanterLabs runs a small Proxmox-based Linux platform. Public traffic enters through Cloudflare and a shared Caddy edge before reaching isolated application workloads. Private services use a separate Tailscale path, and management access is not treated as application ingress.

flowchart LR
    users(["🌐 Public users"]) --> cf["Cloudflare"]
    cf --> edge["Caddy edge"]
    edge --> apps["Public app workloads"]

    team(["🔒 Private access"]) --> ts["Tailscale"]
    ts --> priv["Private services"]

    subgraph host["Proxmox Linux platform"]
        edge
        apps
        priv
    end

    classDef ext fill:#f38020,stroke:#c2600f,color:#fff
    classDef edgeC fill:#1f88c0,stroke:#166a96,color:#fff
    classDef pub fill:#2e7d32,stroke:#1b5e20,color:#fff
    classDef prv fill:#37474f,stroke:#263238,color:#fff
    class cf ext
    class edge edgeC
    class apps pub
    class ts,priv prv

GitHub Actions jobs run on a dedicated k3s environment. Actions Runner Controller creates an ephemeral runner pod on demand, the pod handles exactly one job with its own Docker daemon, and the job environment is removed afterward.

sequenceDiagram
    autonumber
    participant GH as GitHub Actions
    participant ARC as ARC on k3s
    participant Pod as Ephemeral runner pod
    GH->>ARC: Job queued
    ARC->>Pod: Create a fresh pod with its own Docker daemon
    Pod->>GH: Register and pick up one job
    Pod->>Pod: Build, test, and validate the release
    Pod-->>GH: Report results
    ARC->>Pod: Tear down, nothing persists

ActionView puts that runner fleet in the GNOME top bar. A badge shows what's running and queued, and turns red on a failure you haven't seen. When the data is stale or the dashboard is unreachable, it says so instead of showing "all quiet". Running jobs with live timers, the runner, and CPU and memory. Queued jobs, flagged when they wait longer than that repo's p95. Notifications for failures, stuck queues, and alerts. A failed matrix run is one notification, not six. It is a read-only client of the fleet dashboard, so there are no GitHub or Kubernetes tokens on the desktop. Every screenshot is a real render from its CI, which runs a headless gnome-shell against sanitized fleet data.

The platform is built around a few operating principles:

This is intentionally an architecture-level view. Network addresses, internal endpoints, capacity, credentials, and recovery procedures are not public documentation.

• Build product code and the delivery path together.
• Prefer small systems with explicit ownership and failure boundaries.
• Minimize persistent privilege and state in automation.
• Document limitations as carefully as capabilities.