Running AI locally used to mean either spending a fortune on hardware or accepting that you’d be waiting minutes for results. That’s changed a lot. I’ve been running local AI models on my homelab for a while now — image generation, language models, text-to-speech — and the experience has gone from “technically possible but painful” to genuinely useful. Here’s what I’ve learned and what actually matters when you’re setting this up yourself.

Why Run AI Locally at All

The obvious answer is privacy — nothing you generate or type goes to an external server. But honestly that wasn’t my main motivation. I got into it because I wanted to experiment with image generation without worrying about content policies, rate limits, or paying per generation. Once you have the hardware it’s essentially free to run as many generations as you want.

The other reason is customization. Cloud AI services give you what they give you. Running locally means you can load specific models, use fine-tuned versions trained on particular styles, and configure things exactly how you want them. For image generation especially, the difference between a generic cloud result and a carefully configured local setup is significant.

What Hardware You Actually Need

VRAM is the bottleneck for almost everything AI-related. More VRAM means you can run larger models, generate at higher resolutions, and keep more things loaded simultaneously. Here’s a rough breakdown of what you can do at different VRAM levels:

My gaming PC runs a 12GB card which hits the sweet spot for most of what I do. My home server runs a 6GB card which handles image generation fine but shows its limitations with larger language models — upgrading that is the next thing on my list.

Beyond VRAM, you want fast storage because model files are large and load times matter, and enough system RAM to handle models that spill over from VRAM. 32GB of system RAM is comfortable, 16GB works but you’ll feel the edges.

Image Generation — What the Setup Looks Like

The image generation ecosystem has matured a lot. There are several well-developed frontends that handle model management, prompt building, and generation queue. Most of them install relatively cleanly if you’re comfortable with the command line and have Python set up.

The learning curve isn’t really the software — it’s understanding how to prompt effectively and how to pick and combine models. The base models are a starting point. The community-trained fine-tunes, LoRAs, and other add-ons on top of them are where it gets interesting. Finding ones that work well for your use case takes experimentation.

Storage warning: Model files add up fast. A single checkpoint file can be 2-7GB. If you start collecting models, embeddings, LoRAs, and VAEs you’ll fill up storage faster than you expect. Plan for this before you start downloading everything.

Local Language Models

Running large language models locally is more hardware-demanding than image generation. The models that run well on consumer hardware are the quantized versions — compressed versions of larger models that trade some quality for dramatically lower VRAM requirements. A well-quantized 7-8 billion parameter model runs fine on 8GB VRAM and produces genuinely useful results for most tasks.

The tools for serving local language models have gotten much better. Several projects now expose an API-compatible interface which means you can point applications that support configurable AI backends at your local model instead of a cloud service. I use this to run a local chat interface that talks to models running on my own hardware — it works well for anything that doesn’t require the absolute latest model capabilities.

Text-to-Speech

This one surprised me with how good it’s gotten. Local TTS models can now produce natural-sounding speech that’s hard to distinguish from cloud services in many cases. The latency is low enough for real-time use on decent hardware. I run a TTS service on my homelab that integrates with my local chat interface — it’s a small thing but it makes the whole setup feel more complete.

The Honest Tradeoffs

Running AI locally isn’t strictly better than cloud services — it’s different. Cloud services have newer models, more compute, and zero setup friction. Local setups have privacy, no per-use costs, and full control over configuration. Which matters more depends entirely on what you’re doing.

For experimentation, creative work, and anything privacy-sensitive, local is genuinely the better choice once you have the hardware. For tasks where you need the absolute best model quality and don’t want to think about infrastructure, cloud is still easier.

The hardware investment pays off faster than you’d expect if you use it regularly. The setup time is a one-time cost. And there’s something satisfying about generating images or chatting with an AI that runs entirely on hardware in your own house, with no external dependencies and no one else involved.

If you’re thinking about trying it — start with image generation on whatever GPU you already have. The barrier to entry is lower than it used to be and you’ll figure out pretty quickly whether you want to invest further.

I’ve been building PCs long enough to know that the “best” build is the one that fits your actual use case — not the one that looks good in a benchmark video. My current setup is built to handle gaming, AI workloads, video encoding, and running a dozen background processes simultaneously without breaking a sweat. Here’s every part, why I picked it, and what I’d tell someone considering a similar build.

The Full Parts List

Before getting into the reasoning, here’s the complete build at a glance with links to each part on Amazon:

Why the Ryzen 9 5950X

The 5950X is 16 cores and 32 threads on the AM4 platform — which means it works with a huge range of motherboards and has been around long enough that used pricing is genuinely reasonable now. I picked it because I needed a CPU that could handle gaming without bottlenecking the GPU while also running heavy background workloads. AI image generation, video encoding, and a browser with too many tabs open — it handles all of it without the gaming performance taking a hit.

If you’re building purely for gaming, the 5950X is overkill. A 5800X3D would actually give you better gaming performance at lower cost thanks to the 3D V-Cache. But if you do anything compute-heavy alongside gaming, the extra cores earn their keep fast.

Why the RX 6750 XT

The 12GB of VRAM is the main reason I went with this card. At the time I was choosing, 8GB cards were starting to show their age in newer titles and I knew I wanted to run local AI image generation which eats VRAM fast. The 6750 XT sits in a sweet spot — solid 1440p gaming performance, 12GB of fast GDDR6, and AMD’s open ecosystem plays well with Linux tools I run on my homelab.

It’s not the fastest card at its price point if pure gaming frames are your only metric. An NVIDIA card in the same price range might edge it out in rasterization. But for my mixed workload including AI, the 12GB VRAM and AMD’s software ecosystem made it the right call.

64GB of RAM — Is It Overkill?

Yes. For pure gaming, absolutely yes. 32GB is the sweet spot for most gaming setups right now. I went to 64GB because I run AI models that like having headroom, I sometimes have virtual machines running in the background, and I have a bad habit of keeping way too many browser tabs open. Once you stop having to think about RAM you realize how much mental overhead it was taking up.

Crucial’s DDR4 kits are boring in the best possible way. They work, they’re reliable, and they don’t cost a premium for RGB you’ll never see inside the case. If you want flashy RAM there are better options. If you want RAM that just works, Crucial is fine.

The Corsair 5000D Airflow — Best Case Decision I Made

I’ve built in a lot of cases over the years. The 5000D Airflow is the best one I’ve used. The mesh front panel actually moves air instead of restricting it, cable management is genuinely painless, and there’s room for proper fan placement. In Florida where ambient temps work against you year-round, a case that breathes well isn’t optional — it’s a requirement.

If you’re in a hot climate: Prioritize airflow over aesthetics. A tempered glass front panel looks great until your thermals climb 10°C because nothing can get in. Mesh front cases run meaningfully cooler — the 5000D Airflow is my top recommendation at this price point.

Storage — Why So Much?

I’m running a 2TB NVMe as the primary drive for Windows, games, and applications, plus three SATA SSDs adding up to an additional 3.5TB. The reason is AI model files — they’re enormous. A single Stable Diffusion model checkpoint can be 2-7GB, and when you have a collection of them plus LoRAs and other add-ons, storage fills up faster than you’d expect. Having all-SSD storage means load times stay fast across the board regardless of which drive something lives on.

If you’re building a gaming-only machine, 1-2TB NVMe is plenty. The extra storage is specific to my workload.

What I’d Change

Honestly not much. If I was building from scratch today I’d look hard at AM5 platform options — the upgrade path is better and DDR5 prices have come down significantly. But for a build that’s already running, upgrading to AM5 would mean replacing the CPU, motherboard, and RAM simultaneously which is basically a full rebuild. The 5950X still holds up well enough that it’s not worth it yet.

The one thing I’m actively planning to upgrade is the GPU in my home server — that’s a separate machine from this gaming build, but it handles the AI generation workloads and the current card is showing its age. That’s what the affiliate earnings from this site go toward.

Full parts list with pricing is on the My Rig page — everything links directly to Amazon with my affiliate tag. If you’re copying any part of this build, that’s the best way to support the site.

Most people pay for web hosting without thinking too hard about it. $10, $15, maybe $20 a month — it’s not a lot on its own, but it adds up, and you’re essentially renting space on someone else’s computer forever. I got annoyed at that and decided to just use hardware I already owned. The site you’re reading right now costs me $0/month to host.

Here’s how it works and what you’d need to pull it off yourself.

The Basic Idea

The concept is simple: instead of paying a hosting company to run your website on their servers, you run it on your own hardware at home. A computer that’s already on 24/7 — like a NAS, an old desktop, a mini PC, whatever — becomes your web server.

The catch has always been getting traffic to reach your home network without exposing your IP address or messing with your router. That used to require port forwarding and a static IP, which was a pain and a security risk. There’s a better way now.

What You Actually Need

Hardware: Anything that can run Linux or Windows and stay on. An old laptop, a mini PC, a Raspberry Pi, a repurposed desktop. It doesn’t need to be powerful for a personal site — even something with 2GB of RAM can handle WordPress traffic comfortably if you’re not running a massive operation.

Web server software: I use WordPress because it’s flexible and well-documented, but you could run anything — a static site, Ghost, a custom Node app, whatever. The hosting method doesn’t care.

A tunnel service: This is the piece that changed everything. Instead of port forwarding, you run a lightweight agent on your home server that creates an outbound-only encrypted tunnel to a tunnel provider. Your traffic comes in through their edge, gets routed through the tunnel to your machine, and your home IP stays invisible. There are a few providers that offer this — some with free tiers that are more than enough for a personal site.

A domain name: You’ll need to buy a domain — that’s the one actual cost here. Domains run $10–15/year for a .com, less for other TLDs. Point it at your tunnel and you’re set.

The Setup Process (Roughly)

I’m keeping this intentionally vague because the specific steps vary a lot depending on your OS, your hardware, and which software you choose. But the general flow looks like this:

1. Get your server software running locally. Install your web server stack on your home machine and confirm it works on your local network. If you can hit it from your phone on WiFi, you’re good.

2. Set up the tunnel. Install the tunnel agent, authenticate with the provider, and create a tunnel that points at your local web server’s port. The provider gives you a generated URL that works immediately.

3. Point your domain at the tunnel. In your domain registrar’s DNS settings, add a CNAME record pointing your domain (or subdomain) at the generated tunnel URL. This usually propagates within minutes.

4. SSL is handled for you. Most tunnel providers handle HTTPS automatically — you get a valid SSL certificate without touching certbot or dealing with renewals. This was a massive quality-of-life improvement over older self-hosting setups.

What It Actually Costs

Running costs for my setup: the domain (~$12/year) and the electricity to keep the server on. The server hardware I already owned. The software stack is all free and open source. The tunnel has a generous free tier I haven’t come close to exceeding.

Compare that to $15–20/month for a managed WordPress host and you’re looking at saving $150–200 a year while learning a ton about how the web actually works under the hood.

Is It Worth It?

Depends on what you want out of it. If you just want a site online with minimal effort, pay for hosting — it’s genuinely easier. But if you like tinkering, already have hardware sitting around, care about privacy, or just want to understand how this stuff works, self-hosting is genuinely satisfying. You own the whole stack. Nothing is a black box.

I’ve learned more about networking, Linux, web servers, and DNS from running this setup than I did from years of using managed hosting. That alone was worth it for me.

Security note: Self-hosting means you’re responsible for keeping your software updated and your server locked down. Keep your OS and web server patched. Use strong passwords. Don’t expose services you don’t need to. The tunnel approach helps a lot with this by not requiring open ports, but it’s not a substitute for good security hygiene.

If you’re curious about going deeper on any part of this — the hardware choices, the software stack, the DNS setup — drop me a message on X @Ok_Bugz. Happy to point you in the right direction.