About

I'm Josh — a systems specialist, documentation gremlin, automation enthusiast, and part-time infrastructure goblin wrangler.

I like taking messy workflows, half-documented processes, mystery services, and “why is this broken again?” situations and turning them into something structured, observable, repeatable, and preferably less cursed.

Professionally, I work around systems, software, operations, and technical support. Personally, I apparently relax by deploying more services, writing documentation, naming infrastructure like it has lore, and convincing containers to behave like responsible members of society.

What I do

Most of my work lives somewhere in the overlap between systems thinking, technical problem-solving, and operational sanity.

I’m usually doing some combination of:

• Systems and infrastructure work — keeping services organized, understandable, and maintainable
• Self-hosting and homelab projects — running, testing, breaking, fixing, and documenting services on hardware I control
• Automation and tooling — building scripts, workflows, and small tools that reduce repetitive work and human suffering
• Documentation — writing things down before “I’ll remember this later” becomes a lie with consequences
• Process improvement — taking chaotic or manual workflows and giving them a spine
• Project planning — turning vague ideas into structures, requirements, architecture notes, and eventually working tools

Basically: if there is a process being held together by vibes, screenshots, and one person’s memory, I want to make it less fragile.

How I think

I like systems that are:

• Reliable enough to trust
• Observable enough to troubleshoot
• Documented enough to survive future questions
• Simple enough to reason about
• Flexible enough to evolve without becoming a haunted mansion
• Boring enough in production that nobody has to light a candle

I am not allergic to complexity. Sometimes complexity is earned.

But I am deeply suspicious of complexity that shows up uninvited, uses the phrase “enterprise-grade,” and somehow requires three dashboards, a wiki page, and a blood oath to restart.

What I build

This site includes projects and notes around:

• Internal tools
• Desktop utilities
• Labeling and receipt-design workflows
• Volunteer operations systems
• Media launchers
• Homelab infrastructure
• Reverse proxies
• Monitoring
• Self-hosted services
• Automation workflows
• Documentation systems

Some projects are polished. Some are prototypes. Some are still in the “what if this existed and wasn’t terrible?” phase.

That is fine. A useful project does not have to arrive fully formed in a blazer. Sometimes it starts as a weird little idea with a README and unresolved emotional baggage.

Why this site exists

Viles.info is part technical portfolio, part project archive, and part public notebook.

It exists so I can:

• Show the kinds of technical problems I like working on
• Document projects as they evolve
• Keep notes somewhere more durable than a random text file named final_final_notes_v3.md
• Share enough context that future employers, collaborators, or curious humans can understand how I approach systems and tools
• Prove that yes, I do in fact document things voluntarily, which should count as a minor miracle

This is not meant to be a glossy corporate portfolio with stock photos of laptops and someone pointing at glass.

It is a working record of how I think, build, troubleshoot, organize, and occasionally argue with computers until they make better choices.

What I care about

I care about practical technical work.

The kind where:

• A workflow gets easier
• A system becomes more reliable
• A service becomes easier to monitor
• A process becomes less dependent on tribal knowledge
• Documentation actually helps someone later
• A small tool saves someone from doing the same annoying task 400 times

I like tools that solve real problems. I like systems that can be explained. I like infrastructure that does not require a séance.

The short version

I build useful things, document how they work, and try to make systems less chaotic.

Sometimes that means writing code.

Sometimes that means fixing infrastructure.

Sometimes that means creating documentation because the existing process was apparently assembled during a thunderstorm.

Either way, I take notes, clean up the mess, and leave things better than I found them.

Usually.

Unless YAML is involved.