<\/span><\/h2>\nI run quizwrap.com \u2014 an educational quiz platform that’s organically grown to 314 post-launch users across 60 countries and 28 institutions \u2014 entirely without paid acquisition. I’m a solopreneur. I run everything on a single Linode server. I watch costs carefully.<\/p>\n
Better Stack was doing log ingestion for me on their free tier. It worked well \u2014 clean UI, SQL queries, good retention. I have nothing against them; it’s a solid product. Then this morning I got an email: “Your organization cyberaka.com is at 80% of your plan quota. Any new data will be dropped once you hit the limit.”<\/em> I clicked through to the upgrade page. The entry-level paid plan starts at $38\/month.<\/p>\nI closed the tab.<\/p>\n
To put that number in context: I pay $72\/month for an 8GB dedicated Linode that runs five production websites. Being asked to pay half my entire server bill just for log ingestion \u2014 on top of everything else \u2014 didn’t make sense. Better Stack is a great product for teams that need it. I’m a solopreneur who needed to do the math.<\/p>\n
I had compute sitting idle at home. I had a public-IP Linode that could act as a coordination hub. The only thing I lacked was the motivation to set it up. The upgrade prompt provided it.<\/p>\n
Log ingestion is two things: a shipper that collects logs and sends them somewhere, and a store that holds and queries them. Better Stack bundled both behind a nice UI. But the open-source world has perfectly good equivalents \u2014 I just needed to wire them together.<\/p>\n
\n<\/span>The Stack I Chose<\/span><\/h2>\nAfter evaluating options, I landed on:<\/p>\n
\n- OpenObserve<\/strong> \u2014 single binary (or container), SQL-based querying, built-in UI, runs on 512MB RAM. The closest open-source match to the Better Stack experience.<\/li>\n
- Vector<\/strong> \u2014 log shipper from the folks at Datadog (open-source). Reads nginx access and error logs and ships them over HTTP.<\/li>\n
- WireGuard<\/strong> \u2014 encrypted peer-to-peer tunnel. My Linode is the hub; the laptop is a peer.<\/li>\n
- Docker Desktop on Windows<\/strong> \u2014 to run OpenObserve as a container with persistent storage.<\/li>\n<\/ul>\n
The architecture is simple:<\/p>\n
quizwrap.com traffic\n \u2193\n Nginx on Linode\n \u2193\n Vector (ships logs over HTTP)\n \u2193\n WireGuard encrypted tunnel\n \u2193\n OpenObserve on old HP laptop at home\n \u2193\n Dashboard in browser<\/code><\/pre>\n
\n<\/span>The Laptop Nobody Wanted<\/span><\/h2>\nLet me tell you about this HP Notebook. BIOS date: May 2016. Factory-installed OS: Windows 10. It had been sitting unused because the internal Wi-Fi chip had died \u2014 Hardware not present<\/code> in Device Manager. I’d plugged a TP-Link USB Wi-Fi dongle into it as a workaround, which is the kind of solution that works until it doesn’t.<\/p>\nBefore I could use it as a server, I needed to fix a few things:<\/p>\n
First: enable Intel VT-x in BIOS.<\/strong> The HP Insyde BIOS had virtualization disabled by default \u2014 their own help text says “HP recommends this feature remain disabled unless specialized applications are being used.” Docker Desktop needs VT-x. Into the BIOS I went (F10 on boot), navigated to System Configuration, toggled Virtualization Technology from Disabled to Enabled. One reboot.<\/p>\nSecond: install WSL2 and Docker Desktop.<\/strong> With VT-x now enabled, wsl --install<\/code> worked cleanly. Docker Desktop 4.77.0 installed with the WSL2 backend. The first launch timed out \u2014 a known issue on older Haswell hardware where the WSL2 VM takes longer to initialise than Docker’s default timeout. Running wsl --shutdown<\/code> and relaunching Docker Desktop a second time fixed it. docker run hello-world<\/code> printed its success message.<\/p>\nThird: kill sleep forever.<\/strong> A server cannot sleep. Power & Sleep \u2192 all dropdowns to Never. powercfg \/hibernate off<\/code> in PowerShell. Control Panel \u2192 Power Options \u2192 lid close action \u2192 Do nothing on both battery and plugged in. This is the step most people forget, and it’s the one that kills your uptime at 3am when nobody’s watching.<\/p>\nFourth: plug in ethernet.<\/strong> The USB Wi-Fi dongle is a single point of failure. I have two internet connections at home. The fast one via ethernet \u2014 now plugged directly into the laptop. The USB dongle stays connected for local network RDP access within the home. Two separate interfaces, two separate purposes, route metrics set so ethernet wins for internet traffic.<\/p>\n
\n<\/span>WireGuard: The Networking Problem That Wasn’t<\/span><\/h2>\nThe obvious challenge with running a server at home is that your laptop is behind NAT. It has no public IP. Port-forwarding your home router to expose port 5080 to the internet is both fragile (dynamic home IPs) and a security liability.<\/p>\n
WireGuard solves this elegantly. The Linode \u2014 which has a static public IP \u2014 becomes the hub. The home laptop dials outbound<\/em> to the Linode on UDP 51820. Because the connection is initiated from the laptop side, it punches through NAT without any port forwarding. PersistentKeepalive = 25<\/code> keeps the NAT mapping open so the Linode can initiate connections back through it.<\/p>\nThe setup:<\/p>\n
\n- Linode gets tunnel IP
10.10.0.1<\/code><\/li>\n- Laptop gets tunnel IP
10.10.0.2<\/code><\/li>\n- OpenObserve listens on
10.10.0.2:5080<\/code><\/li>\n- Vector on Linode ships logs to
http:\/\/10.10.0.2:5080<\/code><\/li>\n<\/ul>\nKey generation on Linode:<\/p>\n
wg genkey | sudo tee \/etc\/wireguard\/linode_private.key | \\\n wg pubkey | sudo tee \/etc\/wireguard\/linode_public.key<\/code><\/pre>\nThe Windows WireGuard GUI generates its own keypair \u2014 just add the config and activate. Within seconds: Latest handshake: 14 seconds ago. Transfer: 92 B received, 180 B sent.<\/code> Tunnel confirmed.<\/p>\nOne gotcha: my Linode has a cloud firewall managed at the dashboard level, not via ufw on the box. I’d opened ports there for SSH, HTTP, and HTTPS \u2014 but not WireGuard’s UDP 51820. Add that rule and save, or handshakes never complete. The Linode dashboard shows a pending indicator (\u21ba) until you hit Save Changes \u2014 easy to miss.<\/p>\n
\n<\/span>OpenObserve in Five Minutes<\/span><\/h2>\nversion: '3.3'\nservices:\n openobserve:\n image: public.ecr.aws\/zinclabs\/openobserve:latest\n container_name: openobserve\n restart: always\n environment:\n - ZO_ROOT_USER_EMAIL=your@email.com\n - ZO_ROOT_USER_PASSWORD=yourpassword\n ports:\n - \"5080:5080\"\n volumes:\n - C:\\openobserve\\data:\/data<\/code><\/pre>\ndocker compose up -d<\/code> and thirty seconds later http:\/\/localhost:5080<\/code> shows the OpenObserve home screen: No Data Ingested<\/em>. Exactly right. The pipeline just needs to be connected.<\/p>\nOne follow-up command worth running immediately:<\/p>\n
docker update --restart always openobserve<\/code><\/pre>\nThis ensures OpenObserve restarts automatically after a Windows Update reboot, without needing you to manually run docker compose up.<\/p>\n
\n<\/span>The Unexpected Unlock: RDP From Anywhere<\/span><\/h2>\nHere’s the thing I didn’t plan for but got for free.<\/p>\n
Once you have WireGuard connecting your Linode to your home laptop, you can use that same tunnel for anything TCP. Including RDP.<\/p>\n
One command on your Mac:<\/p>\n
ssh -L 3389:10.10.0.2:3389 -L 5080:10.10.0.2:5080 your-user@your-domain.com -N<\/code><\/pre>\nThis creates two local port forwards over the SSH connection:<\/p>\n
\nlocalhost:3389<\/code> \u2192 Windows laptop RDP (via WireGuard tunnel)<\/li>\nlocalhost:5080<\/code> \u2192 OpenObserve dashboard (via WireGuard tunnel)<\/li>\n<\/ul>\nOpen Microsoft’s Windows App (the new name for Microsoft Remote Desktop), connect to localhost<\/code>, enter Windows credentials \u2014 and you’re looking at the desktop of a laptop sitting in your home, tunnelled through a server in the US, from wherever you are in the world.<\/p>\nThe security picture is clean. Port 3389 is not exposed to the internet at all. Only traffic that arrives through your SSH tunnel (protected by your SSH key) can reach the WireGuard tunnel, which then reaches the laptop. There’s no attack surface for random scanners.<\/p>\n
One prerequisite I’d missed: AllowTcpForwarding<\/code> in \/etc\/ssh\/sshd_config<\/code> was set to no<\/code> on the Linode. The error channel 2: open failed: administratively prohibited<\/code> tells you exactly what’s wrong once you know what to look for. Set it to yes<\/code>, sudo systemctl restart ssh<\/code>, done.<\/p>\n
\n<\/span>“It Posts 200s” Is Not “It’s Done”<\/span><\/h2>\nWhen I came back to wire up the last piece \u2014 Vector actually shipping to OpenObserve \u2014 I found it was already working. docker logs openobserve<\/code> had the smoking gun:<\/p>\nPOST \/api\/default\/quizwrap\/_json HTTP\/1.1\" 200 ... \"Vector\/0.56.0\"<\/code><\/pre>\nLogs were arriving. Pipeline complete, right? Not even close. “Bytes are landing in the database” is the demo. The gap between that and something I’d actually rely on took longer than everything before it \u2014 and it’s the part nobody blogs about.<\/p>\n
<\/span>Raw lines are useless; parse at the edge<\/span><\/h3>\nThe logs landing in OpenObserve were raw nginx strings stuffed into a single message<\/code> field:<\/p>\n104.22.24.138 - - [14\/Jun\/2026:12:18:05 +0000] \"GET \/ HTTP\/1.1\" 200 1978 \"-\" \"curl\/8.5.0\"<\/code><\/pre>\nYou can full-text search that, but you can’t ask the questions that matter: show me every 5xx<\/em>, which IPs are hammering \/api<\/em>, what’s my 404 rate<\/em>. For that you need structured fields \u2014 and the cleanest place to create them is at the shipper, before they ever hit storage.<\/p>\nVector has a built-in VRL function for exactly this. I dropped a remap<\/code> transform between the file source and the HTTP sink:<\/p>\ntransforms:\n parse_access:\n type: remap\n inputs: [nginx_access]\n source: |\n parsed, err = parse_nginx_log(.message, \"combined\")\n if err == null {\n . = merge(., parsed)\n .log_type = \"nginx_access\"\n } else {\n .log_type = \"nginx_access_unparsed\"\n .parse_error = err\n }<\/code><\/pre>\nThe if err == null<\/code> branch matters: a malformed line still gets shipped (tagged _unparsed<\/code>) instead of silently vanishing, and the raw text stays in message<\/code>, so nothing is ever lost. Same pattern for the error log with format \"error\"<\/code>.<\/p>\nAfter that, the same request arrives as:<\/p>\n
{ \"client\": \"104.22.24.138\", \"status\": 200, \"request\": \"GET \/ HTTP\/1.1\",\n \"size\": 1978, \"agent\": \"curl\/8.5.0\", \"log_type\": \"nginx_access\" }<\/code><\/pre>\nNow status >= 500<\/code> is a query, not a grep.<\/p>\nAnd the payoff was immediate. Within minutes of structured logs flowing, I spotted this in the stream:<\/p>\n
GET \/.git\/refs\/heads\/main \u2192 404\nGET \/.env.orig \u2192 404\nPROPFIND \/ \u2192 405<\/code><\/pre>\nBots, constantly probing for an exposed git repo or a leaked secrets file. All 404’d \u2014 nothing leaked \u2014 but I’d never have caught the pattern in a wall of raw text. The observability I built to save money immediately paid off as a security signal.<\/p>\n
<\/span>A service that dies when you close the terminal isn’t a service<\/span><\/h3>\nVector was running only because I’d typed vector --config ...<\/code> into an SSH session. The moment that session closed \u2014 or the Linode rebooted \u2014 logging would stop, silently. The fix is a systemd unit:<\/p>\n[Service]\nType=exec\nUser=cyberaka\nExecStart=\/home\/cyberaka\/.vector\/bin\/vector --config \/home\/cyberaka\/.vector\/config\/vector.yaml\nRestart=always\nRestartSec=10<\/code><\/pre>\nsystemctl enable --now vector<\/code> and it now starts on boot, restarts on crash, and survives me disconnecting.<\/p>\nBut there was a trap I nearly walked into. My setup notes said to clear the old process with pkill -f vector<\/code>. Before running it I checked what was actually running \u2014 and found two other<\/em> vector<\/code> processes owned by root, with a binary path that didn’t even exist on disk. For a second I thought the box was compromised. They turned out to be Vector instances running inside other Docker containers<\/em> (a staging and prod telemetry stack I’d forgotten about) \u2014 the binary “didn’t exist” because it lived inside the container’s filesystem namespace. A blanket pkill -f vector<\/code> would have killed those too.<\/p>\nLesson: never pattern-kill on a name as generic as “vector.” I scoped the kill to the exact config path \u2014 pkill -f 'vector --config \/home\/cyberaka\/...'<\/code> \u2014 so it could only ever match the one process I meant.<\/p>\n<\/span>Surviving a reboot, hands-off<\/span><\/h3>\nThis was the real test, and the first reboot failed it \u2014 usefully. After restarting the laptop the tunnel was up (the WireGuard service started fine) but logs stopped. The culprit: Docker Desktop is a user application, not a boot service.<\/strong> It doesn’t start until someone logs into Windows, and the OpenObserve container can’t restart if Docker itself isn’t running.<\/p>\nThe full hands-off chain needed three independent things to auto-start:<\/p>\n
\n- WireGuard tunnel<\/strong> \u2014 installed as a Windows service so it comes up before<\/em> login:\n
wireguard \/installtunnelservice \"C:\\wireguard\\linode-hub.conf\"<\/code><\/pre>\n(Start type Automatic<\/code>, confirmed with Get-Service<\/code>.)<\/li>\n- Docker Desktop<\/strong> \u2014 Settings \u2192 General \u2192 Start Docker Desktop when you sign in<\/em>. The container’s
restart: always<\/code> then brings OpenObserve back on its own.<\/li>\n- Windows auto-login<\/strong> \u2014 the piece that closes the loop. Because Docker needs a login, an unattended box has to log itself<\/em> in.
netplwiz<\/code> \u2192 uncheck Users must enter a user name and password<\/em>. Now a power-cut at 3am recovers without me.<\/li>\n<\/ol>\nThe chain after any reboot:<\/p>\n
\npower on \u2192 Windows auto-logs-in \u2192 Docker Desktop starts \u2192 OpenObserve container restarts \u2192 WireGuard already up \u2192 Vector ships \u2192 logs flow<\/p>\n<\/blockquote>\n
I tested it the dumb, honest way: rebooted and walked away. Two minutes later, querying from the Linode, fresh logs were landing. I even shut the lid (lid action set to Do nothing<\/em>) to confirm it keeps serving with the screen closed \u2014 it does.<\/p>\nIn practice, though, I run it lid-open<\/em>. A laptop running 24\/7 sheds heat far better with the deck exposed than clamshelled with the screen trapping it on top. On a 15W i5 under light load the difference is small, but it’s free: lid open, on a hard flat surface (never carpet or a bed \u2014 that blocks the bottom air intake, the number-one cause of laptop overheating), slightly elevated for airflow, and the display set to sleep on idle so the panel isn’t burning power for no one. It’s sitting on a shelf now, and it just works.<\/p>\nOne quiet hero in all this: Vector’s disk buffer<\/strong>. While OpenObserve was down during that failed first reboot, Vector didn’t drop anything \u2014 it spooled logs to a 256 MB on-disk buffer (when_full: block<\/code>) and flushed the backlog the instant the tunnel came back. The outage cost me zero log lines.<\/p>\nAnd one last knob so the SSD never fills: I capped retention at 45 days on the stream. Old data gets compacted away automatically; disk usage stays bounded forever.<\/p>\n
<\/span>The rotation I chose not<\/em> to do<\/span><\/h3>\nA couple of secrets \u2014 the OpenObserve password, a WireGuard key \u2014 passed through notes and terminals during setup. The reflexive security advice is “rotate everything.” I didn’t, and I think that’s the right call: OpenObserve is never exposed to the internet (only reachable over the tunnel and my LAN), and this is a single-user home lab. The threat model doesn’t justify the churn. What does<\/em> matter \u2014 and what I did verify \u2014 is that the OpenObserve password isn’t reused on anything internet-facing. Security is a math problem too; spend the effort where the threat is real.<\/p>\n
\n<\/span>The Philosophy: Spare Compute Is a Private Cloud<\/span><\/h2>\nI have five old laptops at home. Until today they were liabilities \u2014 things to dust, to not throw away, to feel vaguely guilty about not using.<\/p>\n
The mental model shift is this: treat spare home compute as tier-2 infrastructure, not as failed hardware.<\/strong><\/p>\nYour Linode (or any VPS) is tier-1: always-on, public-facing, static IP, runs your websites and anything customer-facing. The home laptops are tier-2: always-on internally, reachable via tunnel, run internal services that don’t need public access.<\/p>\n
The tier-2 laptops win on cost for anything that would otherwise require upsizing your VPS or adding cloud services. A \u20b92000\/month managed log ingestion service, replaced by a laptop that was already paid for and electricity that’s already being consumed. A \u20b9800\/month additional VPS for running n8n automations, replaced by laptop number two. Cloud GPU credits for LLM experiments, replaced by laptop number four running inference locally.<\/p>\n
The pattern that makes this work:<\/p>\n
\n- WireGuard on every machine, Linode as hub<\/li>\n
- Docker + Docker Compose on each laptop<\/li>\n
- Everything defined in a
docker-compose.yml<\/code> in git<\/li>\n- State backed up to Linode or object storage<\/li>\n
- If a laptop dies,
docker compose up<\/code> on another one<\/li>\n<\/ol>\nThe laptops become disposable. The services become portable. The cost stays zero.<\/p>\n
This is what I’ve started calling Vibe Driven Infrastructure<\/strong> \u2014 building your stack iteratively by feel, shipping incrementally, letting real constraints (cost, hardware availability, actual traffic) drive architectural decisions rather than imagined future scale. The same philosophy I apply to product development, applied to the infrastructure underneath it.<\/p>\n
\n<\/span>What I’d Do Differently<\/span><\/h2>\nStart with the tunnel.<\/strong> I spent time evaluating Cloudflare Tunnel and Tailscale before landing on plain WireGuard. For a solopreneur with a VPS that has a public IP, WireGuard hub-and-spoke is the simplest, cheapest, and most private option. No third party in the data path. No commercial-use licensing questions. Just keys and configs.<\/p>\nShip OpenObserve natively first, Docker second.<\/strong> OpenObserve provides a single .exe<\/code> for Windows that runs without Docker at all. For a dedicated single-purpose machine, the native binary + NSSM service wrapper is simpler than the Docker path. I went Docker because I wanted the flexibility for future services on this machine \u2014 which turned out to be the right call \u2014 but if you just want OpenObserve running in ten minutes, skip Docker entirely.<\/p>\nFix the Vector config before starting it.<\/strong> Vector ships with a demo config that generates fake syslog data. The first time I started it, I watched beautiful fake logs scroll by for thirty seconds before realising none of it was from my nginx. Always cat<\/code> the config before starting a service.<\/p>\nBudget for the last 10%.<\/strong> Getting logs to arrive<\/em> took an afternoon. Making the pipeline survive reboots, disconnects, and a closed lid \u2014 structured parsing, a systemd service, three separate layers of Windows auto-start \u2014 took longer than the entire happy path before it. The demo is the easy part. Plan for the hardening, because that’s the part that decides whether you have a server or a science project.<\/p>\n
\n<\/span>The Current State and What’s Next<\/span><\/h2>\nThe pipeline is live and, more to the point, durable. nginx logs are parsed into structured fields, shipped over the tunnel, stored in OpenObserve, capped at 45 days so the SSD never fills, and queryable from a browser. Vector runs as a systemd service on the Linode; the laptop recovers from a full reboot with nobody in the loop. I’ve stopped thinking about it \u2014 which is the only honest measure of “done” for infrastructure.<\/p>\n
Beyond that, the roadmap for the home lab:<\/p>\n
\n- Laptop 2:<\/strong> n8n for workflow automation (Quizwrap notifications, Sage platform webhooks)<\/li>\n
- Laptop 3:<\/strong> Staging environment for Quizwrap and Sage<\/li>\n
- Laptop 4:<\/strong> LLM\/RAG experiments and the BigQuery dashboard backend<\/li>\n
- Laptop 5:<\/strong> Cold spare<\/li>\n<\/ul>\n