DEV Community: Arsen Apostolov

I want to let an AI agent roam my homelab — looking for someone to build the MCP server

Arsen Apostolov — Sun, 07 Jun 2026 08:46:32 +0000

I maintain a small open-source tool called HomeLab Monitor — one dashboard for every box in my homelab: host vitals, containers, systemd services, GPU, and which AI model servers are loaded right now.

It's good at being a pair of human eyes. The next thing I want is to make it a source of context for an AI agent.

So the idea: give it an MCP server. Model Context Protocol is the thing that lets an agent like Claude call tools and read resources. If the monitor speaks MCP, an agent can connect and explore the whole fleet — "which container is leaking RAM?", "the GPU's been pinned for an hour, who's driving it?", "this host wants a reboot and an OS upgrade, what order is safe?" — and start helping with the maintenance instead of me squinting at graphs.

The fun part for whoever builds it: it's mostly a thin wrapper over a REST API that already exists. The monitor already serves clean, read-only JSON (/api/data, /api/fleet, /api/host_data/<name>, /metrics). MCP just adds the semantics — tools and resources with names an LLM can reason about instead of a raw blob. Read-only to start; any future write tool stays opt-in.

It's genuinely weekend-sized if you've wrapped an MCP server around an API before — and a great first one if you haven't and want to learn.

Repo: https://github.com/SikamikanikoBG/homelab-monitor
The idea + a suggested first PR: https://github.com/SikamikanikoBG/homelab-monitor/issues/70

If wiring this sounds fun, come say hi on the issue — I'll help scope the first commit.

The homelab box you forgot you own is probably 47 updates behind — here’s the safe fix

Arsen Apostolov — Sun, 07 Jun 2026 06:01:16 +0000

TL;DR: My homelab monitor flagged my Plex/Pi-hole box 47 packages and a kernel behind — and I'd forgotten the machine existed. Here's the 5-minute non-interactive fix, and the one upgrade I deliberately didn't run.

This is the dev.to short version of the Medium write-up. Same dashboard that caught a service hoarding 16GB of VRAM last week — different, more boring villain.

The signal

The overview wore one small badge: ⚠ 1 host behind. Not my GPU box that I touch daily — cloudy, the Plex / Pi-hole / Samba box that just works and therefore never gets looked at.

The monitor also flags a release upgrade as available — I'm deferring that one regardless of which version it lands on (more below).

UPDATES column: 47 pending · ⬆ 26.04 available.

The diagnosis

$ ssh anakin@cloudy
$ lsb_release -ds && uname -r
Ubuntu 22.04.5 LTS
5.15.0-179-generic          # running — but 5.15.0-181 was already installed, waiting on a reboot

$ apt list --upgradable 2>/dev/null | grep -c upgradable
47
$ cat /var/run/reboot-required
*** System restart required ***

Nothing was broken — Plex streamed, Pi-hole resolved, shares mounted. That's the trap: a box that's 47 behind doesn't tell you. Among the 47: systemd, snapd, apparmor, nftables, cloud-init, linux-firmware, openldap. Plenty of it security-relevant.

The fix (non-interactive, config-preserving)

sudo -i
export DEBIAN_FRONTEND=noninteractive NEEDRESTART_MODE=a
apt-get update
apt-get -o Dpkg::Options::="--force-confold" \
        -o Dpkg::Options::="--force-confdef" \
        -y full-upgrade
apt-get -y autoremove --purge

--force-confold → keep my existing config files, don't stop to ask.
NEEDRESTART_MODE=a → let needrestart restart affected services itself instead of showing the blue full-screen menu that hangs an unattended run.
Result: 45 upgraded, 2 newly installed, 0 removed. Clean.

Then activate the kernel/systemd the box had been holding:

$ reboot              # ~90s of no DNS for the LAN — an on-purpose action, not a background one
$ uname -r
5.15.0-181-generic    # back on the tailnet, now on the staged kernel

Before / after

47 → 0. The package badge cleared.

What I deliberately did NOT run

The monitor also flags a full Ubuntu release upgrade waiting. do-release-upgrade on a remote, headless, house-critical box is a scheduled-window job — with a backup and a console in reach — not an unattended one. The dashboard surfacing it is the win; choosing to defer it is the right call. So I left it flagged, on purpose.

The point

I'm not disciplined about my boring boxes — nobody is. The only reason this got caught is one badge in one dashboard I already look at. The tool is HomeLab Monitor — one container, MIT, no Prometheus/Grafana to stand up:

docker compose up -d --build
# github.com/SikamikanikoBG/homelab-monitor

When did you last log into your most reliable box, and how would you find out it was a month behind? Mine used a badge. What's watching yours — a cron apt list --upgradable, unattended-upgrades mail you actually read, or nothing? Genuinely curious which holds up for people.

Reclaiming 16GB of idle VRAM: a 30-line sidecar that evicts ComfyUI when it stops working

Arsen Apostolov — Sat, 06 Jun 2026 10:21:05 +0000

My homelab is one Linux box with a single RTX 3090. 24GB of VRAM, and
three GPU-hungry services that all want it: ComfyUI for image generation,
WhisperX for transcription, Ollama for local LLMs. On one card, that's
already a negotiation.

Last week the negotiation broke. My own monitoring dashboard caught the
culprit at a glance, so this is the short version: what it was, how I saw
it, and the 30-line container that fixed it for good.

(If you want the prequel — the time the Ollama triage model reserved a
40,000-token context to do 8,000 tokens of work — that's
Two LLMs, One 3090, Zero OOM.
Same box. Same lesson.)

The symptom

I opened the GPU tab of my homelab dashboard for something unrelated and
saw the card sitting at 71% full while nothing was running.

16.3GB held by comfyui. GPU utilisation: 0%. The model was loaded
and doing absolutely nothing. The per-service history made it
unambiguous — ComfyUI peaked at 16.3GB and held it 100% of the window:

This is the whole reason I built the dashboard. nvidia-smi tells you
VRAM is at 17/24GB. It does not tell you which service, which model,
and since when. The GPU tab maps every VRAM-using PID back to its
container automatically, so "who is holding my GPU" is a glance, not five
minutes of ps -o cgroup archaeology.

The diagnosis

nvidia-smi on the host confirmed it:

$ nvidia-smi --query-compute-apps=pid,used_memory,process_name --format=csv,noheader
111465, 16666 MiB, python3      # <- ComfyUI, idle
109583, 588 MiB, /app/.venv/bin/python

ComfyUI keeps the checkpoint resident after a generation so the next
request is fast. Sensible on a dedicated image-gen box. On a shared 24GB
card it is hostile: the FLUX fp8 checkpoint is ~16GB, and ComfyUI 0.22
has no idle timeout to give it back. Once you've generated one image,
that 16GB is gone until you restart the container.

Good news: ComfyUI has an API for exactly this. POST /free with
unload_models drops the model out of VRAM.

$ curl -X POST http://localhost:8188/free \
    -H 'Content-Type: application/json' \
    -d '{"unload_models": true, "free_memory": true}'

One call took ComfyUI from 16666 MiB to 378 MiB. The model reloads
automatically on the next /prompt — about 20–30s added to that one
request, which for an image I generate a few times a day is free.

So I don't want to call /free after every job (kills warm-cache speed
for bursts). I want to call it after ComfyUI has been idle for a
while. ComfyUI won't do that itself, so I bolted it on from outside.

The fix: an idle-unload sidecar

No ComfyUI fork, no custom node. A tiny container that watches the queue
and evicts the model after a few minutes of inactivity.

#!/bin/sh
# Unload ComfyUI models from VRAM after a period of queue inactivity.
INTERVAL=${INTERVAL:-30}
IDLE_SECONDS=${IDLE_SECONDS:-300}
URL=${COMFY_URL:-http://localhost:8188}
idle=0
while true; do
  sleep "$INTERVAL"
  q=$(curl -s -m 10 "$URL/queue" 2>/dev/null) || continue
  [ -z "$q" ] && continue
  # idle == both queue_running and queue_pending are empty arrays
  if [ "${q#*\"queue_running\": []}" != "$q" ] && \
     [ "${q#*\"queue_pending\": []}" != "$q" ]; then
    idle=$((idle + INTERVAL))
    if [ "$idle" -ge "$IDLE_SECONDS" ]; then
      curl -s -m 30 -X POST "$URL/free" -H 'Content-Type: application/json' \
        -d '{"unload_models":true,"free_memory":true}' >/dev/null 2>&1
      idle=0
    fi
  else
    idle=0          # a job ran — reset the idle clock
  fi
done

It polls /queue every 30s. If both queue_running and queue_pending
are empty, it adds to an idle counter. After 300s of continuous idle it
POSTs /free and resets. Any job resets the counter, so a burst of
generations keeps the model warm — eviction only happens once you've
genuinely stopped.

No new image to build — curlimages/curl already has sh and curl:

docker run -d --name comfyui-idle-unloader --restart unless-stopped \
  --network host -e IDLE_SECONDS=300 -e INTERVAL=30 \
  -v /opt/comfyui-idle-unloader/unload-idle.sh:/unload-idle.sh:ro \
  --entrypoint sh curlimages/curl:latest /unload-idle.sh

--network host so it can reach ComfyUI on localhost, --restart unless-stopped so it survives reboots. That's the whole deployment.

Before / after

Watching it on the same dashboard, the story is one cliff:

ComfyUI, idle	VRAM held	GPU "full"	Free for WhisperX + Ollama
Before	16.3 GB	71%	~7 GB
After	0.37 GB	5%	~23 GB

~16GB back, for the cost of one slightly slower image every once in a
while. WhisperX and Ollama stopped fighting over the leftovers.

No fork, no patch, no upstream PR to wait on. Thirty lines of sh and a
container that does one thing. If ComfyUI ships an idle TTL tomorrow, I
delete it and lose nothing.

Why a sidecar and not a patch

Decoupled. It knows nothing about ComfyUI's internals — just the public /queue and /free endpoints. ComfyUI can update under it.
Nothing to maintain. It rides ComfyUI's stable HTTP API; an update to ComfyUI doesn't touch it.
Same pattern works elsewhere. Anything with a "unload model" endpoint (A1111, vLLM with sleep mode, TGI) can be evicted the same way.

The meta-point, and the reason I keep building on the dashboard: I didn't
find this by reading logs. I found it because a tool attributed 16GB to a
named, idle service on one screen. You can't reclaim VRAM you can't see.

The monitor is one container, MIT-licensed, docker compose up -d --build
to try. NVIDIA-only on the GPU panel for now, single-host by design:

github.com/SikamikanikoBG/homelab-monitor

How does everyone else handle idle model eviction on a shared GPU — a
sidecar like this, a TTL in the model server, or do you just docker restart and move on? Genuinely curious which approach holds up.

Fitting WhisperX large-v3 + a 24B LLM on one 3090: a reproducible context-capping recipe

Arsen Apostolov — Wed, 03 Jun 2026 03:35:14 +0000

This is the technical, reproducible version of a fix I shipped on my own homelab. If you want the narrative version, that's on Medium. This one is the recipe: the measurements, the math, the Modelfile, and the exact prompt I gave Claude Code to generate it. Copy-paste friendly.

Repo for the dashboard used throughout: https://github.com/SikamikanikoBG/homelab-monitor

TL;DR

One 24GB RTX 3090, two GPU services: WhisperX large-v3 (STT, 7.7GB peak) and a Devstral Small 24B email-triage LLM (Q4_K_M, ~18.3GB).
18.3 + 7.7 = 26GB → CUDA OOM whenever they overlapped.
The LLM was loaded with a 40k context window but the triage job never needed more than ~5–8k tokens.
Capped num_ctx to 8192 → KV cache drops from ~6.1GB to ~1.25GB → model footprint ~18.3GB → ~14.2GB.
14.2 + 7.7 = 21.9GB → both resident, zero OOM, no quality loss.

The setup

Host:    openSUSE, Xeon (56 threads), 125GB RAM, 1x RTX 3090 (24GB)
GPU svc: WhisperX large-v3  (speech-to-text)
GPU svc: Ollama -> devstral-small-2 (24B, Q4_K_M) for background email triage

Both services run all the time. The OOM only happened when I dictated to my assistant (WhisperX) while the triage loop was active.

Step 1 — Make the contention measurable

nvidia-smi shows instantaneous VRAM. It can't show you which service spiked or when two of them overlapped — and an intermittent OOM is a timing problem. You need per-service VRAM history.

I use my own dashboard (homelab-monitor) for this. The relevant view is "AI Models", which attributes VRAM per model server and per loaded model, over a time range, with OOM markers and a capacity ceiling line.

What the history showed at the overlap window:

Service	Peak VRAM
Devstral 24B (triage)	~18.3 GB
WhisperX large-v3	7.7 GB
Total	~26 GB on a 24 GB card

If you want to reproduce the measurement, the dashboard runs as a single container:

git clone https://github.com/SikamikanikoBG/homelab-monitor
cd homelab-monitor
docker compose up -d --build
# open http://<host>:9800  -> AI Models / GPU views

(NVIDIA Container Toolkit required for GPU metrics. Remote hosts are monitored over SSH, no agent.)

Step 2 — Measure what the job actually needs

Weights are a fixed cost (~15GB for Devstral 24B at Q4_K_M). The variable cost is the KV cache, which scales linearly with num_ctx. So the question is: how much context does background email triage actually use?

I pulled the request traces from Langfuse. The triage pipeline:

truncates each email body to 300–500 chars,
batches ~10 emails per call,
caps generation around 2k tokens.

Real prompts never exceeded ~5–8k tokens. The model was loaded with a 40k window — ~32k tokens of reserved KV cache doing nothing.

Step 3 — Do the KV-cache math

Devstral Small is mistral3. Pull the architecture straight from Ollama:

curl -s http://localhost:11434/api/show -d '{"name":"devstral-small-2:latest"}' \
  | python -c "import sys,json;mi=json.load(sys.stdin)['model_info'];\
print({k:v for k,v in mi.items() if 'head_count' in k or 'block_count' in k or 'length' in k})"

Relevant values:

block_count (layers)      = 40
attention.head_count_kv   = 8
attention.key_length      = 128
attention.value_length    = 128
context_length (native)   = 8192   # rope-extended to 393216

KV cache per token (f16) = 2 (K+V) × layers × kv_heads × head_dim × 2 bytes:

2 × 40 × 8 × 128 × 2  =  163,840 bytes  ≈  0.156 MB / token

So:

num_ctx	KV cache (f16)
40,960	~6.1 GB
16,384	~2.5 GB
8,192	~1.25 GB
4,096	~0.6 GB

8192 is the sweet spot: it's above the real worst-case prompt (~5–8k) and it's the model's native context length, so there's no rope extrapolation quality hit. I rejected 4096 — a 10-email batch with 2k generation can brush up against it.

Step 4 — Generate the capped model

Ollama lets you inherit existing weights and override parameters in a Modelfile, so this costs no extra disk and no re-download.

Modelfile.triage:

FROM devstral-small-2:latest

# Native 8K window: covers every triage prompt (10-email batches + 2K generation)
# while keeping the KV cache ~1.25GB so the model + WhisperX fit on one 24GB GPU.
PARAMETER num_ctx 8192
PARAMETER temperature 0
PARAMETER num_predict 2048

SYSTEM """You are a background email-triage engine. Follow the exact output
format in each request. Output only the requested label(s) or field(s). Never
add explanations, preamble, or commentary. When uncertain, pick the closest
valid option. Be terse and deterministic."""

Build it:

ollama create devstral-small-2:triage -f Modelfile.triage

The optional SYSTEM block is a small bonus: triage prompts want terse, structured output, and pinning that behaviour cuts stray preamble (fewer reparse/retry calls = less GPU time).

The Claude Code prompt I used

I let Claude Code do the measuring and the Modelfile generation. The prompt, roughly:

Analyze my background email triage. Pull the Langfuse traces to find the real prompt/context sizes the triage job uses, decide a safe num_ctx cap that won't truncate worst-case batches, confirm the KV-cache savings against the model's actual architecture, and generate an Ollama Modelfile for a context-capped :triage variant. Then tell me the expected VRAM footprint.

It came back with: traces show ≤8k tokens, cap at 8192 (native window), ~5GB KV saved, expected footprint ~14–16GB. Which matched what the dashboard measured after I deployed it.

Step 5 — Verify on the GPU

# load it
curl -s http://localhost:11434/api/generate \
  -d '{"model":"devstral-small-2:triage","prompt":"ping","stream":false}' >/dev/null

# check resident VRAM + context
curl -s http://localhost:11434/api/ps \
  | python -c "import sys,json;[print(m['name'],round(m['size_vram']/1e9,1),'GB ctx',m['context_length']) for m in json.load(sys.stdin)['models']]"

Result: the triage model holds ~14GB resident at ctx=8192, down from ~18GB.

Result

	Before	After
Triage LLM	~18.3 GB	~14.2 GB
WhisperX large-v3	7.7 GB	7.7 GB
Combined	~26 GB → OOM	~21.9 GB → fits

Both services now sit on the card together. Full STT quality, email triage in parallel, ~2GB headroom. No quant change, no CPU offload, no smaller Whisper.

Takeaways

A shared-GPU OOM is a timing problem. Point-in-time nvidia-smi can't diagnose it — get per-service VRAM history.
Match num_ctx to the real workload. Reserved context is pure VRAM cost. Background jobs almost always over-reserve.
Prefer the model's native context length as your cap when you can — no rope-extrapolation quality hit.
Measure twice (traces + GPU history), cap once. The fix was three lines; knowing it was the right three lines took the data.

Dashboard used for the per-service VRAM history: https://github.com/SikamikanikoBG/homelab-monitor — it's open source, runs in one container, and exists because I needed exactly this view and nvidia-smi wouldn't give it to me.

I got tired of guessing which model holds my VRAM, so I built a tiny dashboard

Arsen Apostolov — Tue, 26 May 2026 19:32:29 +0000

Quick story.

I run a small homelab — one box, an NVIDIA card, around ten Docker containers, and a couple of local model servers (Ollama mostly, vLLM when I'm playing around).

Every "why is this model OOM-ing" turned into the same five minutes of archaeology:

nvidia-smi → pick a PID
ps -o cgroup -p → find the container ID
docker ps → map ID to name

Just to answer: which container, which model, is eating my VRAM right now?

I tried Prometheus + Grafana + node-exporter + dcgm-exporter. It works, but for one box it's a stack-on-a-stack to answer a single question.

So I built a third option: one container, one page. GPU panel maps VRAM-using processes back to their Docker container automatically. AI Models panel queries each model server's own API (Ollama /api/ps, vLLM /v1/models, llama.cpp, TGI, A1111, ComfyUI) and shows you which model is loaded.

docker compose up -d --build and that's the whole setup.

History in SQLite, downsampled on read. No agents, no cloud, no Prometheus.

The repo, with the longer technical write-up and screenshots:

👉 github.com/SikamikanikoBG/homelab-monitor

MIT licensed. NVIDIA-only on the GPU panel for now — AMD/Intel back-ends are a good first issue if anyone wants to extend.

Curious how others here solve the "who holds my VRAM" problem. Different tool? Different stack? Or did you also build something tiny because the big stacks felt like too much for one box?

Building a Game for My Daughter with AI — Part 1: What If She Could Build It Too?

Arsen Apostolov — Sun, 22 Mar 2026 08:35:15 +0000

She drew a purple dragon with six legs and called it "a dragon but also a dog."

Capped the marker. Moved on. Zero doubt.

I thought: what if that drawing could actually come to life?

So I started building it. In secret.

The full story — the design thinking, the tech stack, and why the reveal moment matters more than the launch — is on Medium:

👉 https://medium.com/@arsen.apostolov/building-a-game-for-my-daughter-with-ai-part-1

Part 2 (Lovable vs Replit, MCP architecture, GPT-4 Vision pipeline) drops next week.

Follow if you want to watch a slightly obsessed AI developer build something for an audience of one.

I Hit a $200 AI Bill and Built My Own Server Instead - Complete Guide!

Arsen Apostolov — Sat, 07 Jun 2025 17:03:36 +0000

Hit a $200 Claude API bill last month ($2400 and above on yearly basis!). That was my wake-up call.

Built my own AI server instead:

RTX 3090 24GB (used): $750 one-time
Zero monthly costs
Access from anywhere via VPN
Unlimited usage

The Setup

# Install Ollama locally
curl -fsSL https://ollama.ai/install.sh | sh

# Download coding models
ollama pull qwen2.5-coder:14b
ollama pull devstral

# Use with aider
aider --model ollama_chat/devstral --api-base http://10.0.0.1:11434

Remote Access via WireGuard

The trick: secure VPN tunnel to home server.

Tech stack:

Linux server running Ollama
WireGuard VPN for encrypted access
Router port forwarding (UDP 51820)

Works from coffee shops, client offices, anywhere.

Results After 6 Months

$0 monthly bills (was $40-60/month)
Faster responses than cloud APIs
No rate limits
100% private - code never leaves my network

Want the Full Guide?

Complete walkthrough here: Stop Paying for ChatGPT - Run Your Own AI Models

Covers:

Step-by-step server setup
WireGuard VPN configuration
Router setup
Client configs for all platforms
Troubleshooting

Why This Matters

Beyond saving money, you learn:

Infrastructure management
VPN security
Cost optimization
Enterprise-ready solutions

Companies increasingly want AI that keeps data internal. This gives you both the skills and the setup.

*Connect: LinkedIn

Stop Copy-Pasting Your Code to LLMs — I Built a Tool That Does It Automatically

Arsen Apostolov — Sun, 23 Mar 2025 06:46:18 +0000

Ever wanted to ask ChatGPT or Claude about your codebase, but got tired of copy-pasting files one by one? Yeah, me too. It was driving me crazy.

Why I Built This
I was working on a project with multiple files and needed some help understanding how everything connected. So I started copy-pasting files into ChatGPT, one after another, trying to give it enough context.

It was a complete pain:

The context window would fill up
I’d forget important files
I had to manually explain connections between files
The LLM would lose track of what was what
After the third time doing this dance, I decided to just build something to solve it myself.

Find the full guide in my Medium article

Testing Aider: Practical Experience with Different Models

Arsen Apostolov — Mon, 17 Feb 2025 05:14:13 +0000

I like coding agents and all kind of supportive plug-ins to make my day easier. From Continue to Copilot. I must say that the most complete solution so far for me was Cursor, yet it is not free (see the plans).

So i found this super cool alternative - Aider chat.

I tested Aider with multiple AI backends: OpenAI, Claude, and local Ollama server.

First 30 minutes were spent learning the tool - understanding commands and workflow. After this initial setup phase, development speed increased significantly.
Model comparison from practical use:

Claude: Best performance when working remotely
Local setup: Ollama with deepseek r1 7b and qwen coder 2.5 7b
Home setup preference: Architect mode with Ollama models

Key observation: Local models provide good performance without cloud dependencies. The initial learning curve is worth the productivity gain.

What's your experience with Aider? Particularly interested in local model configurations and performance comparisons.

I’m sharing my LLM Code Lens Python package: My Secret Weapon for AI-Powered Coding

Arsen Apostolov — Fri, 10 Jan 2025 04:56:15 +0000

Hey everyone,

I want to share my tool that has completely transformed how I work with AI assistants. If you're tired of writing endless, complex prompts and struggling to get precise code insights, this is for you.

The Problem

Working with large language models like ChatGPT, Claude, or Mistral always felt like a communication battle. How do you explain an entire project's context in a single prompt?

My Solution: LLM Code Lens

I built a simple, powerful package that generates a comprehensive project context file in seconds.

Go to the output dir:

Preview the analysis.txt It contains summary of your codebase - imports, functions, documentation etc so that LLMs can have pretty good context.

Preview the full.txt It contains your codebase aggregated in a file. Great for smaller projects (bellow 10K lines of code based on my experience).

How to Use It

Install the package

pip install llm-code-lens

Generate project context

# Create condensed description of the project. Sufficient for big projects to provide context to LLMs.
# Generates analysis.txt in the output folder. Default folder: .codelens
llmcl

# On top of the analysis.txt it generates all the codebase in full.txt so that LLM can see all your projects. The output files are divided into 100K tokens file so that they can fit in any LLM including local Llama3.3 70B
llmcl --full

Get context files in .codelens/
analysis.txt
analysis.json
Paste these directly into your AI assistant

The prompt

Immediate result

Instant Efficiency!

No more:

Writing 500-word explanations
Struggling to provide context
Wasting time on prompt engineering

Just pure, efficient code insights.

My Personal Experience

This tool has been an essential part of my daily coding routine for months. It has significantly improved my development performance.

Your Turn

🚀 Star the Project on GitHub

Try it. Love it. Share it.

Hope it helps you as much as it's helped me.

Cheers,
Arsen

Let's Connect! 🤝

💼 Connect with me on LinkedIn
🎮 Join our Random42 community on Discord - AI news, Success stories, Use cases and Support for your project!
📝 Follow my tech journey on Dev.to

My Weekend project on GitHub: Making AI Art Creation Simple For Everyone 🎨

Arsen Apostolov — Sun, 05 Jan 2025 12:30:39 +0000

Check out the project on GitHub and give it a ⭐ if you find it useful!

As a developer passionate about AI, I saw an opportunity to make image generation more accessible. I wanted to create something that would enable everyone to explore the amazing possibilities of AI art without getting caught up in technical complexities. That's why I built ImageGenerator - a tool I crafted from the ground up to handle all the technical aspects behind the scenes, letting you focus purely on creativity.

Why I Built ImageGenerator Different

A key feature that sets ImageGenerator apart is that it runs completely locally on your machine. Unlike cloud-based solutions, your data never leaves your computer - there's no uploading to external servers, no privacy concerns, and no usage limits. You have full control over everything.

What also sets my implementation apart is that it's built by a developer who prioritizes both user experience and data privacy. Every feature comes from solving real problems I encountered, and I've refined the interface based on actual usage and feedback. Whether you're working on personal projects or professional tasks, you can use ImageGenerator with complete peace of mind.

Here's what you get out of the box:

🏠 100% local setup - your data never leaves your machine
🔒 Complete privacy - no cloud services or external servers needed
🎯 Simple web interface - no command line needed
🚀 One-click installation with all dependencies handled
🎨 Support for both local and online AI models
🎥 Built-in image-to-video conversion
📊 Real-time generation progress and status updates
⚡ No usage limits or API costs - generate as much as you want

See It In Action

Here are some images I generated using ImageGenerator:

Getting Started in 2 Minutes

The best part? Everything runs locally on your machine. No accounts to create, no API keys to manage, and no data privacy concerns. Just follow these simple steps:

# Clone the repository
git clone https://github.com/SikamikanikoBG/ImageGenerator
cd stable-diffusion-client

# Install dependencies
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118
pip install -r requirements.txt

# Start the server
python server.py

# In a new terminal, start the client
python client.py

That's it! Visit http://localhost:7860 in your browser, and you're ready to start generating images.

Key Features That Make Life Easier

🏠 True Local Processing

All processing happens on your machine
No internet connection needed after setup
Your images and prompts stay private
Generate unlimited images without restrictions
Full control over your data and models

🎨 Intuitive Web Interface

No more juggling with command-line parameters. Everything you need is organized in clear, easy-to-understand tabs:

Connection settings
Project management
Generation parameters
Output gallery
Video conversion

🤖 Smart Model Management

Automatic scanning and loading of models
Support for both local and Hugging Face models
Easy model comparison to find what works best for you

🎥 One-Click Video Creation

Transform your still images into videos with preset animations:

Subtle movements
Normal flow
Slow motion
Ultra-slow effects

Real-World Applications

Students and developers are already using ImageGenerator for:

Creating custom artwork for projects
Generating placeholder images for websites
Experimenting with AI art styles
Building portfolios of AI-generated content

Join Our Community!

If you find ImageGenerator useful:

⭐ Star the GitHub repository
🤝 Join our Discord server for:
- Tips and tricks
- Showcase your creations
- Get help when needed
- Connect with other creators

Behind the Scenes: How I Built It

I carefully chose each technology to create the most robust and user-friendly experience possible:

Python 3.8+ for its stability and extensive AI libraries
FastAPI for a lightning-fast, modern backend that can handle heavy processing
Gradio for building an intuitive interface that anyone can use
CUDA support for GPU acceleration, which I optimized for both performance and memory usage

The entire system took several iterations to get right. I spent considerable time optimizing the model loading process, fine-tuning the memory management, and creating a seamless experience between the backend and frontend.

I'm releasing all of this under the MIT license because I believe in open source and want others to build upon what I've created. Feel free to use it in your own projects - that's exactly why I built it!

Next Steps

Ready to start creating? Head over to the GitHub repository and follow the quick start guide. Don't forget to star the repo if you find it useful!

Have questions or want to connect with other users? Join our Discord community - we'd love to see what you create!

Looking for feedback on the next article about home lab setups - AI, automation, or ML?

Arsen Apostolov — Fri, 03 Jan 2025 07:27:31 +0000

Last year, I wrote this comprehensive guide about transforming a regular home PC into a powerful learning environment using open-source tools like Linux, Anaconda, Apache Airflow, and more. The article continues to help newcomers and intermediate users get more value from their hardware.

Check it out here:

medium.com

I'm planning to write Part 2, and I'd love your input on which topic would be most valuable:

Home GenAI Lab Setup: Running LLMs locally, experimenting with different models
Home Automation System: Smart home integration, custom automation solutions
Home ML Lab: Setting up for machine learning experiments and model training

What would you like to learn about? Share your preference in the comments!

Let's Connect! 🤝

💼 Connect with me on LinkedIn
🎮 Join our Random42 community on Discord - AI news, Success stories, Use cases and Support for your project!
📝 Follow my tech journey on Dev.to