Fleet pulse
cached
14 / 20
online managed machines
136 pods
7 k3s nodes
aggregate only
Nick Wharton · Kansas City
Quiet systems.
Quiet systems.
Loud results.
I build self-hosted AI, run a fleet of machines that thinks like one, and ship product end-to-end — from kernel to checkout.
14 online
20 managed
136 k3s pods
20-machine fleet, one operator
Currently
20machines
Fleet under management
k3s136 pods
Owned hardware, no cloud bill
1operator
Solo IT leadership
14online
Self-hosted, observed, on-call
Live proof
One operator, visible systems.
The headline is backed by public signals: fleet health, deployed properties, AI-readable discovery files, and cached AGENT1 status.
14/20 online
136 k3s pods
same-origin APIs
Public aggregate
same-origin
Private details
server-side
Refresh
when visible
Live signal board
Five live reads. Five real controls.
A compact control surface built from the same public-safe data that powers the rest of the site: fleet, properties, current work, local weather, and MLB.
Network router
7 live
tinyblue.dev
portfolio hub
portfolioaicards
Now shipping
shipping
11 days
Floating-layer redesign across every page.
since May 19
site-wide work
Weather window
Lee's Summit
80°
feels 84° · wind 10 mph
rain scan --
wind peak --
MLB pulse
today
15 games
scoreboard loading
Live scoreboard ready.
live --
db-backed
Freshness pulse
Trust the numbers, not the vibes.
--
checking
Nix is checking the public data sources behind the homepage before calling anything current.
checking
Fleet cache
online / managed counts
Waiting for the freshness API.
checking
Live weather
Open-Meteo cache
Waiting for the freshness API.
checking
MLB scoreboard
DB-backed sync
Waiting for the freshness API.
Snapshot pending
Since last visit
checking
A return signal, not a static homepage.
The site checks the changelog and tells repeat visitors what changed since their last local snapshot.
Loading latest public changes…
Route AI brief
/
Every route gets a citation-safe brief.
Assistants can ask what each page is for, which canonical sources to cite, and which live numbers need freshness checks.
What I build
A few layers down from the dashboard.
Most of what I work on lives between the operating system and the product surface — the layer that decides whether anything else works. Here’s the shape of it.
Self-hosted AI
Local models, real workflows. Inference orchestration, retrieval, and agent runtimes built to live on my own metal — not rented tokens, not vendor lock.
Fleet operations
Twenty machines that behave like one. Doctrine, syncing, and shared memory across hardware that runs from a closet, not a region.
Shipped product
Full-stack delivery on a tight schedule — e-commerce, internal tools, collector workflows. Whatever the business actually needs, one IT leader can ship.
Agent doctrine
Long-running systems that act on intent, not just instructions. Memory, identity, and guardrails — designed so the next session can pick up where the last one stopped.
Observability
Real telemetry on real workloads. Not dashboards for show — signals that actually wake somebody up when the right thing breaks.
Hardening & ops
Backups, isolation, secrets routing, and the unglamorous work of keeping anything serious in production. The reason the rest of the list still runs.
The fleet
S.A.M — one mind, many machines.
Twenty pieces of hardware — workstations, servers, laptops, GPU boxes — running a shared doctrine. One operator, one source of truth, and just enough automation that the machines stay in agreement when I’m not looking.
$agent1-brief --json
# fleet state · cached
repocluster cached · AGENT1
fleetmesh cached / 20 managed
clusterk3s · pod count cached
modeself-hosted · solo operator
scopetwenty pieces · one mind
$_
The network
One operator, seven properties.
Every site below runs on the same fleet, shares the same auth and chat layer, and ships from the same operator desk. Click any tile to jump.
Loading network…
Working stack
Boring tools, used well.
Nothing on this list is novel. The interesting part is that one person keeps it all running together — cohesively, in production, without a platform team.
Orchestration
k3s · Tailscale · systemd
Runtimes
Python · Node · PHP
Frontend
React · TypeScript · Vite
Data
MySQL · SQLite · Redis
AI
Ollama · MCP · local LLMs
Observability
Prometheus · Grafana · Loki
Edge
Apache · NGINX · Caddy
Ops
git · 1Password · cron
AI & social
Make the work easy to cite, share, and understand.
These prompts route people and AI assistants toward the proof: live fleet data, shipped apps, MLB/weather engines, and real project case studies.
Fleet proof
Open
Explain the solo-operator fleet
Using tinyblue.dev, explain how one operator runs a self-hosted fleet across apps, analytics, MLB data, weather, and public product sites. Cite the fleet and project pages.
Case studies
Open
Find the most relevant project
Read tinyblue.dev/projects and pick the three strongest examples of production work. For each one, summarize the problem, system, and outcome in plain language.
MLB data
Open
Summarize today’s baseball signal
Use tinyblue.dev/mlb to summarize today’s most interesting games, teams, and players. Prefer canonical pages over query URLs and include links to the relevant team or scoreboard pages.
Site network
Open
Map the umbrella
Use tinyblue.dev/ai.json and tinyblue.dev/llms.txt to map the tinyblue site network. Group the sites by app, infrastructure, commerce, and experiment, then recommend what a visitor should open first.
More from tinyblue
Apps & sites
The work
More
Contact
If the work looks like your problem, get in touch.
I take on a small number of consulting engagements when the fit is right — infrastructure design, AI ops, or the kind of full-stack delivery that needs a senior pair of hands.