I’m Nate. I fix engines, run servers, and make stuff when I can’t find what I want.
I’m in Louisville, Kentucky. I run Dad’s Small Engine Garage on the side, I run my own servers and cameras, and I’m usually working on something because I looked at the way it already worked and thought, there has to be a better way to do this.
I’m building it now. Some of the pieces already run every day in my own setup, and some of the bigger SentryOSM pieces are still being written.
I usually learn something because I need it to work.
I’m not very interested in getting something to work once and calling it done. I want to know why it failed, what happens after a reboot, whether it comes back on its own, and whether I can figure it out again six months later.
I learn by using the thing for real.
Servers, cameras and network gear get a lot more interesting after a bad update, a dead drive, a broken route or a service that quietly stopped working three hours ago. That is why I ended up building backups, health checks, alerts and restart logic instead of just installing apps and walking away.
I like knowing what actually failed.
At Dad’s Small Engine Garage, guessing gets expensive fast. A no-start can be fuel, ignition, wiring, a sensor, compression, or more than one problem at the same time. I try to carry that same habit into the computer stuff: test it, prove it, then fix the thing that is actually wrong.
A few projects that are actually mine.
No giant skill list. These are things I built because I wanted them, needed them, or got tired of the way the existing thing worked.
My local server setup
I run Proxmox and Debian with VMs and containers for cameras, Home Assistant, AdGuard, Immich, Plex and other services. Over time I added backups, monitoring, restart scripts and remote access because I actually use this stuff and notice when it is down.
My Frigate setup
I run local IP cameras through Frigate with local recording and a Coral for detection. I’ve spent plenty of time chasing dropped streams, recording problems, network issues and detections that did not do what I expected. A lot of the idea behind SentryOSM came from using that setup and thinking it could be a whole lot smarter.
PointOSM
I wanted a better chore system for my family, so I made one. The kids do chores for points, parents verify the work, and the points can be spent on rewards. It runs on my own server and does the job I built it for.
Dad’s Small Engine Garage
I work on mowers, golf carts, ATVs, dirt bikes, generators, go-karts, scooters and whatever else rolls in. A lot of the job is figuring out whether the problem is electrical, mechanical, fuel-related, wiring, a sensor, or several problems stacked on top of each other.
Scripts, monitoring and deployment
I’ve built health checks, restart scripts, alerts, backups and deployment checks because I got tired of finding out something broke long after it happened. The Dad’s and SentryOSM sites live in GitHub and deploy through Cloudflare. I also keep a verification step because “the code changed” and “the public site actually changed” are not the same thing.
I got tired of every piece of the system knowing only its own little part.
The camera knows video. The door sensor knows open or closed. Home Assistant knows device state. The router knows the network. An AI model can describe what it sees. But when something actually happens, I still have to put the whole story together myself.
SentryOSM is me trying to make those pieces act like one system.
It is still a prototype. I’m building the software and testing the hardware around it now. I would rather show exactly where it is than dress it up like there is already a finished box sitting on a shelf somewhere.