Blog | Sergio Saucedo

Powering a GPU Node On-Demand with iDRAC and Redfish

Wed, 15 Apr 2026 00:00:00 +0000

There’s a Dell PowerEdge R630 in my homelab whose only job is GPU work — mainly Ollama for self-hosted LLM inference. Rack servers are power-hungry, and paying to idle one 24/7 for something I use a few hours a week is absurd. So the machine stays off by default and boots on demand.

Redfish: the API your server already has

Every server with a BMC (iDRAC on Dell, iLO on HP) exposes the Redfish API — a REST interface to the hardware itself. The BMC draws a couple of watts and is always reachable, even when the host is powered off. Power control is a single POST:

curl -sk -K ~/.bmc-creds \
 -H 'Content-Type: application/json' \
 -X POST "https://$BMC/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset" \
 -d '{"ResetType": "On"}'

Two details worth stealing:

Keep credentials out of argv. Curl’s -K flag reads options from a file, so the BMC password never shows up in ps or shell history. The creds file is chmod 600, owned by root.
GracefulShutdown first, ForceOff as the escape hatch. Redfish supports both; the graceful path lets the OS unmount cleanly.

I wrapped this in a ~40-line script (esxi up | down | status) that also queries PowerState, so any machine on my VPN can check or change the server’s state in one command.

Making it a button

CLI is fine at a desk, but the whole point is “I want to ask a model something now.” So the script is wired into a small dashboard on my hypervisor — one page showing every service’s health, with Power on / Shut down buttons for the GPU node. Boot to Ollama-ready takes about four minutes; the dashboard’s status dot flips green when the tunnel to it comes back up.

The pattern generalizes to anything with a BMC:

State lives in the BMC, not the OS — you can always trust it.
Actions are idempotent Redfish POSTs — safe to put behind a button.
Health is best checked end-to-end — I probe the actual Ollama endpoint, not just a ping.

The economics

An R630 idles around 90–120 W. At my rates, leaving it on costs roughly $10–15/month to do nothing; on-demand it’s pennies. The four-minute boot is a fair trade for inference that runs on my hardware, on my network, with no tokens metered by anyone.

Zero Open Ports: Publishing Homelab Services with Cloudflare Tunnel

Sun, 15 Mar 2026 00:00:00 +0000

Port forwarding is how homelabs get owned. Every forwarded port is a doorbell on the public internet, ringing straight into your house, answered by whatever software you last remembered to patch. My rule for the homelab is simple: zero open inbound ports, ever.

How the traffic flows

Cloudflare Tunnel inverts the connection. A lightweight daemon (cloudflared) runs inside the network and dials out to Cloudflare’s edge. Public hostnames — grafana.example.com, monitor.example.com — are DNS records pointing at the tunnel, and Cloudflare routes each one to an internal address the daemon can reach:

ingress:
 - hostname: grafana.example.com
 service: http://monitoring-vm:3000
 - hostname: sites.example.com
 service: http://caddy:80
 - service: http_status:404 # explicit default: drop everything else

The router does nothing. There is nothing to scan. From outside, my house looks like a device that never answers.

The layers, in order

Cloudflare edge — TLS termination, DDoS absorption, and the only surface an attacker can see.
The tunnel — outbound-only; a connector VM runs cloudflared as a systemd service, and a second connector runs in Docker for a separate domain serving static sites through Caddy.
The service’s own auth — everything published still has a login (Grafana, Beszel, the Proxmox UI). A tunnel hides the network, not a weak password.
Everything else stays private — admin surfaces I don’t need public (the control dashboard, SSH to most machines) live only on Tailscale, the overlay VPN layered across every node.

For the services that should be really private — SSH in particular — Cloudflare Access sits in front of the tunnel hostname, requiring an identity check before the connection ever reaches my network.

Lessons learned

End the ingress list with an explicit 404. The default catch-all is the difference between “I exposed three services” and “I exposed whatever happened to respond.”
One tunnel per trust domain. My personal-brand services and my throwaway static sites run on separate tunnels with separate credentials; a leaked token compromises one, not both.
Auth-gated is not the same as private. A public login page is still public. If you wouldn’t want the URL in a search index, put it behind Access or keep it VPN-only.
Monitor from inside. Blackbox-exporter probes both the internal address and the public hostname, so I can tell “service is down” apart from “tunnel is down” at a glance in Grafana.

The result: friends reach the Minecraft server, recruiters reach my dashboards, and my router’s port-forwarding table has been empty for a year.

Running AWS ECS Anywhere on a Proxmox Homelab

Sun, 15 Feb 2026 00:00:00 +0000

My side projects need real infrastructure — APIs, scheduled scrapers, background workers — but paying for EC2 to run workloads that fit comfortably on hardware I already own never sat right with me. ECS Anywhere is the compromise I settled on: AWS owns the control plane, my Proxmox server owns the compute.

The setup

The homelab runs Proxmox VE on a 12-core, 32 GB machine. One VM is dedicated to ECS: it runs the amazon-ecs-agent registered as an external instance in a regular ECS cluster. From the AWS console it looks like any other container instance — task definitions, services, deployments, CloudWatch — but the tasks execute at home.

Registration is a one-time SSM activation:

aws ssm create-activation --iam-role ecsAnywhereRole
curl -o ecs-anywhere-install.sh https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh
sudo bash ecs-anywhere-install.sh \
 --cluster homelab \
 --activation-id "$ACTIVATION_ID" \
 --activation-code "$ACTIVATION_CODE" \
 --region us-east-1

After that, deploying to my house is identical to deploying to Fargate: push an image to ECR, update the task definition, and the agent pulls and swaps containers. My CI pipeline doesn’t know or care that the target is a VM under my desk.

What runs on it

Right now the external instance runs the production API and scraper for Qanto, my personal finance app. The scraper is exactly the kind of workload this shines for: long-running, bursty, and completely indifferent to latency — but expensive to keep on a cloud instance 24/7.

The honest trade-offs

You are the datacenter. Power outage, ISP hiccup, dead disk — that’s your pager. I mitigate with Proxmox snapshots and a monitoring VM (Prometheus + Grafana + Loki) that alerts me before users notice.
ECS Anywhere still costs money — about $0.01/hour per registered instance. For one instance that's ~$7/month, far below the EC2 equivalent for the same cores and RAM.
No ALB integration on-prem. Ingress is my own problem; I solve it with Cloudflare Tunnel, which also means zero open ports on my router.

Why not just Docker Compose?

I ran plain Compose for years. What ECS Anywhere buys me is the deployment story: immutable task definitions, rollbacks, the same aws ecs update-service muscle memory I use professionally, and one console showing every environment. The homelab stopped being a snowflake and became just another cluster.