https://pype.dev/tags/product/archive/atom.xml 2025-09-01T07:09:49Z All posts with the tag "product" Nic Payne markata-go https://pype.dev/homelab-as-a-service/ 2025-09-01T07:09:49Z 2025-09-01T07:09:49Z

I don't know what to call my opinionated homelab distribution yet but I will try to have some goals for today or tomorrow for simple steps - drawing up all...

<h2 id="home"><span class="heading-wear-glyph">$HOME</span> <a href="#home" class="heading-anchor">#</a></h2> <p>I don&rsquo;t know what to call my opinionated homelab distribution yet but I will try to have some goals for today or tomorrow for simple steps</p> <ul> <li>drawing up all the pieces will take a while but is necessary</li> <li>ansible playbook to make zfs datasets for vms or containers is easy first utility to bank somewhere</li> </ul> <h2 id="homelab"><span class="heading-wear-glyph">Homelab</span> <a href="#homelab" class="heading-anchor">#</a></h2> <ul> <li> <p>started chatting with jipity about some automation&hellip; I have so many ideas that circle my head and I have a hard time implementing anything for fear of committing halfway to something&hellip;</p> </li> <li> <p>I think I can take baby steps to mitigate that issue and one way is to automate the first thing that annoys me - zfs dataset creation for new apps. I assume that I want a new zfs dataset if I&rsquo;m going to provision something into my homelab so that means</p> <ul> <li>dataset creation on the appropriate node</li> <li>permissions</li> <li>updates to <code>zfs-ops</code> (eventually dataops in homelab-mono) for the backup to be added explicitly (or removed if I&rsquo;m removing one - for example some old VM datasets I no longer need)</li> </ul> </li> <li> <p>I also mind-dumped after starting the convo with jipity, using speakr to get a short summary of a brain dump is pretty awesome especially considering the purely local self-hosted nature. Here&rsquo;s the summary of a pretty concentrated 6 minute monologue on things I&rsquo;m thinking about:</p> <ul> <li>Summary is imperfect - but again, for self-hosted hardware and getting purely private LLM-assisted brainstorming is really cool. However, I do plan on sinking some thought into the big boys (claude or jippity) as I very slowly begin construction</li> </ul> </li> </ul> <div class="admonition note"> <p class="admonition-title">speakr self-hosted summary</p> <p>Key Issues Discussed</p> <pre><code>Platform and service idea for consulting Product as an opinionated home lab targeting small teams or on-prem setups with Docker Swarm + ZFS Focus on privacy, data ownership, compute ownership while providing cloud options (AWS) Hardware recommendations part of services Use AWS resources when possible but self-hosting is also viable option Tail scale for business networking and network ACLs provided by the vendor </code></pre> <p>Key Decisions Made</p> <pre><code>Deploy servers using Docker Swarm + ZFS with an opinionated approach to data management, backups, application deployment monitoring. Cloud options include Terraform set up in AWS (and possibly Azure later) Use U-Corps as a base for containers on top of Ubuntu distro box; consider KeyCloak or Aphalia for authentication DNS and public services will be handled with NameCheap and Cloudflare using Terraform, not picking each other’s features. CERT management is Let’s Encrypt Observability through Harbor telemetry data gathering </code></pre> </div> <p>I brainstormed a little more witih jipity this morning and got this set of pillars</p> <div class="admonition note"> <p class="admonition-title">pillars</p> <p>Infrastructure (hardware, OS, baseline networking)</p> <p>DataOps (storage, backup, placement)</p> <p>Orchestration (containers, jobs, IaC)</p> <p>Networking &amp; Connectivity (service-to-service, ingress/egress)</p> <p>Security &amp; Identity (auth, secrets, policies, hardening)</p> <p>Observability (metrics, logging, tracing, health)</p> <p>Automation &amp; CI/CD (playbooks, pipelines, GitOps)</p> <p>Resilience &amp; Recovery (HA, redundancy, DR, self-healing)</p> <p>Experience (DX, onboarding, docs, templates)</p> </div> <h2 id="features"><span class="heading-wear-glyph">Features</span> <a href="#features" class="heading-anchor">#</a></h2> <p>I&rsquo;m taking notes in <a href="/affine/" class="glossary-term" title="Mind-mapping webapp at home with native desktop App. Like Notion but with diagram support" data-hover-title="Affine">affine</a> <a href="https://affine.paynepride.com/workspace/068b2d03-00ee-4b4b-9a8d-d7b98e85f1f2/pufV8iRo_XoCpVuPgQ6vA">here</a> to capture requirements grouped by feature or relevant level of the stack (ie. OS package installs vs repository setup vs pipeline recommendations etc.)</p> <h2 id="tools"><span class="heading-wear-glyph">Tools</span> <a href="#tools" class="heading-anchor">#</a></h2> <ul> <li><a href="https://github.com/pypeaday/komodo">komodo</a> for server deployment etc&hellip; it actaully has a ton of things in it for managing compose stacks on multiple nodes right now, with <a href="https://github.com/moghtech/komodo/issues/37">swarm support coming</a> <ul> <li>in the mean time <a href="https://github.com/moghtech/komodo/issues/37#issuecomment-3106074124">this comment</a> gives a short example on using swarm&rsquo;s overlay network and managing the stack from within komodo (<a href="/kind/" class="glossary-term" title="kind - kubernetes in docker" data-hover-title="kind">kind</a> of)</li> </ul> </li> </ul> Nic Payne https://pype.dev