Project Ops

Local Hosting — Historical Track Audit

Project operations source: Local Hosting — Historical Track Audit.

This is historical evidence, preserved on 2026-09-09 from source checkpoint 21bff93. The matching Astro checkpoint is 669cb78. The original outline below preserves planning inputs, not a second curriculum inventory or a commitment to build every idea. Its body and existing link are preserved.

The current Track Guide and shared Track Map carry the composition: choosing fit and operating responsibility as the center; What Local Hosting Means as the proposed signature; placement, access/commitments, and maintenance/recovery as developing routes; installation as later work; organizational resilience and hosted-provider tool-building as optional depth.

Next Artifact Pass — Evidence and Unresolved Questions

  • What Local Hosting Means has no module source. The intended first practice compares hosted, local, and hybrid options for one small use case, recording data flow, access, ownership, costs, failure/recovery, evidence, and the learner’s decision. The complete module, Activity, standalone Notebook, reviewed comparison packet, and facilitator guide are missing. The Notebook must support the whole activity without the module page.
  • “Compare hosted, local, and hybrid options for a simple use case” is a proposed activity direction, not a settled Lab title. The decision record belongs within this first practice. Staying hosted, using a hybrid option, postponing a change, or adding no tool are valid outcomes; installation is not the entry’s success condition.
  • Local Models vs Hosted Models, Accounts, Keys, and Secrets, Backups and Restores, Spend Limits and Vendor Changes, Service Availability, Updating Safely, and When Not to Self-Host have no canonical module sources. The three remaining historical Lab ideas have no canonical packages or Notebooks.
  • Distinguish where an app runs from where its model, storage, and connected services operate. Self-hosting describes operating responsibility, not necessarily a device in the learner’s home. Locality does not prove offline operation, privacy, security, or low total cost. Comparisons need evidence rather than reassuring labels.
  • No platform or live installation environment is selected. Later technical practice needs prerequisites, disposable materials, reviewed install/update/uninstall and reset/restore procedures, account and secret boundaries, network-exposure safeguards, accessible alternatives, and support. Do not use the Track rewrite to authorize installations, public exposure, or changes to personal accounts and files.
  • A backup checklist or outage role-play can examine a plan but does not prove restoration or service availability. The learner record must distinguish supplied evidence, assumptions, proposed tests, and observed results. Recovery needs its own reviewed environment and evidence before delivery claims.
  • Becoming an Informed Technology Consumer remains Sketch / Planned, owned by Renaissance Solutions, primary to AI Readiness, related to Creative AI Makerspace, with no dependencies. Consumer Reports for Emerging Technology remains Alpha, owned by Mike, primary to that module, related to AI Readiness. It has fictional product cards, a learner decision worksheet, discussion scenarios, an answer guide, and a facilitator guide. Its Notebook is Coming Soon, not an existing page. Timing and format remain To be determined; its review status still calls for a worked example, gallery entry, and accessibility review.
  • Conversational Privacy remains Sketch / Planned, owned by Renaissance Solutions, primary to AI Literacy, with AI Readiness, Creative AI Makerspace, Family, and Study Time as related Tracks. Its metadata names AI Without the Hype and What AI Is and Is Not as dependencies, while its learner copy says Preparation: none. Preserve these sources and resolve that existing discrepancy in the artifact pass.
  • What Does the Tool Need? remains Beta, owned by Mike, with Conversational Privacy as its primary module and AI Literacy as its related Track. Its fictional packet, standalone Notebook, learner guide, companion article, and facilitator guide exist. It provides minimum-necessary disclosure practice, not a complete hosting security or recovery exercise.
  • The Conversational Privacy module page does not currently link What Does the Tool Need? from Practice, though its source package and activities section do, and the Lab’s primary_module field identifies Conversational Privacy. Keep the canonical parent relationship and record this direct-navigation gap for the subsequent artifact pass; do not rewrite the module here.
  • The two Shared Support pairings are Local Hosting composition selections. Their current primary relationships and reciprocal related_tracks metadata remain unchanged. Confirm those reciprocal selections during the artifact pass rather than silently adding Track membership everywhere.
  • Resilience and Outage Planning remains Seed / Planned, Business level, owner Unassigned, Not reviewed, primary to AI Readiness, with no related Tracks. Its Safe AI Use for Small Business or equivalent dependency needs confirmation according to its own status notes. Its “what if the tool is down?” plan remains a Lab concept without a canonical package or Notebook. It is optional organizational depth, not a resolved beginner prerequisite.
  • Build a Safe Text-to-Speech Skill remains Draft / Drafting, Builder level, owned by Mike, primary to Agentic Coding, with Prompting Is the Door, Not the Destination and Context Engineering or equivalent safe-file practice as dependencies. Its Alpha Lab remains primary to that module and related to Agentic Coding, Podcaster / Influencer, and Local Hosting; its standalone Notebook exists. The Lab still needs learning-design, secrets-handling, accessibility, provider-current, and pilot review.
  • The text-to-speech package is a hosted-provider example with a local secret-handling boundary, optional encrypted team-secret workflow, budget guardrail, and revocation response. It is not a self-hosted service or a substitute for a Local Hosting Lab. Preserve the original relationship as optional technical depth; do not make provider setup part of the account-free comparison entry.
  • Basic AI literacy, privacy/data boundaries, continuity concepts, and familiarity with accounts/files/devices remain preparation topics. More exact technical prerequisites are still a gap. Avoid turning historical topic names into invented source links or a compulsory module sequence.
  • Intended participation includes account-free supplied examples on paper or screen, discussion, partner direction, and observation. AI use is not required to compare hosting options; any AI-generated suggestions need checking against the evidence. Live technical practice is a later, separately reviewed extension. These are design commitments; the signature packet and Notebook do not yet exist.
  • First pilot after package review: choose the use case, map data and responsibilities, compare options, and explain a decision. Gather actual timing, terms learners misunderstand, access needs, and support friction. Include a case for staying hosted or making no change. Facilitator demonstrations remain Coming Soon.
  • Preserve the Additional Reading section, Track Draft / Drafting status, and Unassigned ownership. This pass creates or rewrites no module, Lab, Notebook, comparison packet, demonstration, environment, dependency, primary relationship, or curriculum status.

Original Track Guide Snapshot

Local Hosting — Original Outline

Status: Working track outline, not finished curriculum.

This track helps learners understand what it means to run AI tools, apps, or services closer to home: on a personal computer, a local network, or a small private server. It should be honest about tradeoffs. Local hosting can improve control and privacy in some cases, but it also introduces maintenance, security, backup, cost, and support responsibilities.

The invitation is for careful builders and organizations that want more control. Learners do not need to become infrastructure engineers on day one, but they do need to understand ownership before they bring a service into their home or business.

Audience: Technical learners, small organizations, privacy-minded users, homelab builders, and future support contributors.

Purpose: Teach the practical responsibilities of running local or self-hosted AI-adjacent tools.

Likely Modules

  • What Local Hosting Means
  • Local Models vs Hosted Models
  • Accounts, Keys, and Secrets
  • Backups and Restores
  • Spend Limits and Vendor Changes
  • Service Availability
  • Updating Safely
  • When Not to Self-Host
  • Build a Safe Text-to-Speech Skill is a practical hosted-provider example: it introduces a local .env boundary, encrypted team-secret option, budget guardrail, and revocation response without treating a TTS skill as a self-hosted service.

Starter Lab Ideas

  • Compare hosted, local, and hybrid options for a simple use case.
  • Create a backup and restore checklist.
  • Map who owns accounts, secrets, updates, and support.
  • Role-play what happens when a local service stops working.

Additional Reading

No additional reading is listed yet.

Dependencies

  • Basic AI literacy.
  • Privacy and data boundaries.
  • Business continuity concepts.
  • Comfort with accounts, files, and devices.

MVP Holes

  • Define prerequisite skill level.
  • Decide whether any hands-on local install belongs in V0 or later.
  • Create clear safety rules for secrets, keys, and network exposure.
  • Define when local hosting is a bad fit.

Source: ops/track-audits/local-hosting.md