Local Hosting
- Track lifecycle
- Draft
- Learner availability
- Drafting
- Owner
- Unassigned
Choose when local or self-hosted tools fit, and understand who will secure, maintain, and recover them.
Track Promise
Choose when local or self-hosted tools fit, and understand who will secure, maintain, and recover them.
Running a tool closer to home can change who controls it and who has work to do when it stops. This Track starts with that choice: what do you need, where will information go, and who will look after the service?
“Local” describes where something runs. “Self-hosted” describes responsibility for operating it, which can include a server somewhere else. An app on your computer may still send work to a hosted model or service. Local does not by itself mean offline, private, secure, or free to maintain.
This Track is for privacy-minded learners, small organizations, homelab builders, and future support contributors. You can begin by comparing choices without becoming an infrastructure engineer. Staying hosted, choosing a hybrid arrangement, postponing a change, or not adding a tool are valid outcomes.
Start Here
Begin with What Local Hosting Means, this Track’s proposed signature module. No module source exists yet. It will help learners compare where a tool runs with who operates it, where its data travels, and what ongoing care it needs.
The intended first practice compares hosted, local, and hybrid options for one small use case, such as searching a fictional club’s public event notes. Use a supplied comparison packet before considering an installation or a real account.
The take-home result is a short hosting decision record: the need, where processing and data go, who can access them, who owns accounts and upkeep, recurring costs and limits, what could fail, and how you would recover or leave. Mark what is supported by the supplied evidence, what is assumed, and what still needs checking. Explain your choice and what would cause you to revisit it.
Signature package still missing: Compare hosted, local, and hybrid options for a simple use case is a proposed activity direction, not a settled Lab title or existing package. The module, complete Activity, standalone Notebook, reviewed comparison packet, and facilitator guide need to be built. The decision record belongs inside this first practice.
Comparison comes first: this is a proposed decision activity, not an installation tutorial. No platform or live practice environment has been selected. A written recovery plan or checklist is not a tested restore.
If basic AI use is new, start with AI Literacy for the Rest of Us. Privacy and data boundaries, business continuity concepts, and comfort with accounts, files, and devices remain relevant preparation. The precise prerequisites for later technical work still need definition.
The Hosting Loop
Choose a need → Map the data → Name the owners → Compare → Decide → Review
- Choose a need: name one useful job and the limits that matter. Ask whether a new tool is needed.
- Map the data: identify the app, model, storage, and any connected services. Check where information is processed, kept, or sent; a local interface does not settle those questions.
- Name the owners: identify who controls access, pays, updates, provides support, and handles failure. A named owner also needs time and the ability to do the work.
- Compare: weigh capability, access needs, privacy boundaries, costs, maintenance, availability, and recovery. Separate evidence from assumptions and unresolved questions.
- Decide: choose hosted, local, hybrid, or no change. State the conditions your choice depends on and what needs checking before real use.
- Review: revisit the choice when needs, people, costs, or services change. In comparison practice, describe proposed recovery checks; report a restore as successful only after it has been tested.
Explore the Responsibilities
These three developing routes extend the signature. Their named modules and Labs have no source pages yet. They show what needs building, not a ready sequence of workshops.
Developing route
Choose where it runs
Compare the actual placement of an app, its model, its data, and its outside services. Ask when more operating responsibility is worth taking on—and when it is not.
Local Models vs Hosted Models; When Not to Self-Host Proposed · no module sources
Missing: reviewed hosted/local/hybrid examples, a data-flow comparison, and evidence of capability, access, cost, and support tradeoffs. Include a case where staying hosted is the better fit. Do not infer privacy or offline operation from a “local” label.
Facilitator route demonstration: Coming Soon
Developing route
Protect access and commitments
Make account access, secret handling, ongoing costs, and vendor changes part of the decision before setup.
Accounts, Keys, and Secrets; Spend Limits and Vendor Changes Proposed · no module sources
Lab idea: Map who owns accounts, secrets, updates, and support — proposed, no Lab source.
Missing: fictional account and responsibility examples, reviewed secret-handling and spending boundaries, loss-of-access scenarios, and a complete Activity and Notebook. Never use real keys or private account details in a classroom comparison.
Facilitator route demonstration: Coming Soon
Developing route
Maintain and recover
Plan who notices an outage, keeps work moving, applies updates, and proves that important information can be restored.
Backups and Restores; Service Availability; Updating Safely Proposed · no module sources
Lab ideas: Create a backup and restore checklist; Role-play what happens when a local service stops working — proposed, no Lab sources.
Missing: a worked outage case, fallback and ownership decisions, a complete Activity and Notebook, and a reviewed environment for later update and restore tests. A role-play can test a plan; it cannot prove that a service or backup works.
Facilitator route demonstration: Coming Soon
Later hands-on installation: not yet built or scheduled. Before offering it, select an environment and define prerequisites, disposable practice materials, reviewed install/update/uninstall and reset/restore steps, account and secret boundaries, network-exposure safeguards, accessible alternatives, and support. No install, public network exposure, or changes to personal accounts and files are required by the proposed entry.
Strengthen Your Practice
These existing sources offer useful decision and privacy practice while the Local Hosting signature is being built. They do not replace a hosting comparison packet, a security review, or a tested recovery exercise.
- Becoming an Informed Technology Consumer — Sketch / Planned → Consumer Reports for Emerging Technology, Alpha, with fictional product cards and a learner decision worksheet. Its Notebook is Coming Soon. Practice comparing commitments, support, and exit options without buying a product.
- Conversational Privacy — Sketch / Planned → What Does the Tool Need?, Beta, with its standalone Notebook. Practice choosing the minimum necessary information for a task. This is disclosure practice, not a complete account or network security Lab.
Conversational Privacy’s metadata names AI Without the Hype and What AI Is and Is Not as dependencies; those remain unchanged. The featured Lab identifies Conversational Privacy as its primary module, though the module page does not yet link this Lab from Practice. That alignment gap is recorded for the later artifact pass.
Keep real credentials, private documents, client information, and network details out of comparison exercises. If an AI assistant helps suggest questions or summarize a supplied example, check its claims against the evidence. Its answer is not proof that a configuration is safe or that data stayed on a device.
Optional: Go Deeper into Operations or Tool-Building
- Resilience and Outage Planning — Seed / Planned, Business level, owner Unassigned. This is organizational depth from AI Readiness. Its “what if the tool is down?” practice remains a concept without a canonical Lab or Notebook. The stated Safe AI Use for Small Business or equivalent dependency still needs confirmation; it is not a resolved beginner prerequisite.
- Build a Safe Text-to-Speech Skill — Draft / Drafting, Builder level → Build a Safe Text-to-Speech Skill, Alpha, with its standalone Notebook. This hosted-provider example covers local secret-handling boundaries, budget guardrails, and revocation response; it is not a self-hosting Lab. Its Prompting and Context Engineering or equivalent safe-file practice dependencies remain in place. Provider setup and technical work belong to this optional package, not the Track entry.
For broader organizational decisions, explore AI Readiness and Risk Assessment Support. For building tools, explore Agentic Coding. These are optional connections, not required destinations.
Participation and Access
The intended first route uses a reviewed, supplied comparison packet on paper or screen. It requires no learner account, purchase, coding, or installation. Learners may write, discuss, observe, or direct a partner. They can make a full hosting decision from the evidence without setting up a service or using AI live. The packet and signature Notebook are still missing.
A facilitator-operated or learner-operated technical extension is a later option, after its environment and prerequisites receive review. A demonstration does not substitute for access alternatives or support. Participants must be able to decline installation and still complete the comparison route.
Use fictional or permitted low-risk material. Do not bring real credentials or sensitive files to test whether a proposed setup protects them. When the evidence or support is inadequate, postpone the change and record what is missing.
For Facilitators
First build priority: What Local Hosting Means and its complete comparison Activity, standalone Notebook, reviewed hosted/local/hybrid examples, and facilitator guide. The Notebook must contain enough instruction to do the whole activity without the module page. The first walkthrough demonstration remains Coming Soon.
After package review, pilot one short route: choose the small use case, map data and responsibilities, compare the supplied options, and explain a hosting decision. Record actual timing, unfamiliar terms, misleading assumptions, and access needs. Include an example where staying hosted or making no change is sensible.
Keep comparison evidence distinct from live observations. A completed decision record does not show that the learner can install, secure, maintain, or restore a service. Before any technical pilot, review the environment, prerequisites, secret and network boundaries, recovery and cleanup steps, and the support available when something fails.
Additional Reading
No additional reading is listed yet.
Status and Feedback
This Track remains Draft / Drafting, owner Unassigned. Its signature and hosting-specific routes are proposed, not built. Existing support and optional sources retain their statuses, ownership, dependencies, and primary relationships. A source link means there is an artifact to review, not that a workshop or operational setup is ready.
The shared Track Map records this composition and links the historical outline. Use this page’s Track feedback and review links for the promise, starting point, route roles, status clarity, and missing or misplaced modules and Labs. Does the comparison entry make ownership clear? Are data flow and recovery visible enough? Is installation at the right depth? Do the existing support packages belong here?
Teaching details belong in separate Module and Lab reviews. This pass creates no module, Lab, Notebook, comparison packet, demonstration, installation environment, or new curriculum status.
Team review information. You are viewing the team review site. The contributor review tools below are separate from the learner activity and learner feedback.
Review status
- Package lifecycle: Draft
- Learner availability: Drafting
- Review needs: Needs track-level composition, prerequisite, security-boundary, recovery, accessibility, and pilot review.