Hiddenden/Knowledge-Base
2
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

first version of the knowledge base :)

Browse Source
This commit is contained in:
Latte
2026-03-14 11:41:54 +01:00
commit 27965301ad
47 changed files with 4356 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
00 - About/about-den-vault.md Normal file
View File

@@ -0,0 +1,59 @@
---
title: About Den Vault
description: Purpose and scope of Den Vault as a public technical knowledge base within the Hidden Den ecosystem
tags:
- about
- documentation
- knowledge-base
category: about
created: 2026-03-14
updated: 2026-03-14
---
# About Den Vault
## Summary
Den Vault is the public technical knowledge base for Hidden Den. It is designed as an engineering notebook, operations handbook, and reusable documentation archive for self-hosting, homelab engineering, DevOps workflows, Linux systems, and infrastructure design.
## Why it matters
Technical notes are most useful when they outlive the moment that produced them. Den Vault turns ad hoc knowledge into structured documentation that can help both the original operator and other engineers facing similar problems.
## Core concepts
- Public technical writing with reusable examples
- Documentation that favors systems, patterns, and operational guidance over personal notes
- Cross-linkable knowledge organized by domain, system, guide, and tool
- Research-backed articles that prefer official sources and current practices
- A human-scale technical archive that is meant to remain readable and calm rather than over-produced
## Practical usage
Den Vault is intended to document:
- Core infrastructure concepts
- Practical guides for setup and operations
- Tool references and architectural patterns
- Day-two operations such as monitoring, backups, and updates
- Public project context where it helps explain the surrounding ecosystem
## Best practices
- Write for a technically capable stranger, not only for the current operator
- Keep examples generic and safe for public publication
- Update documents when practices or tooling change
- Link claims to upstream documentation or standards when possible
## Pitfalls
- Turning public docs into private scratch notes
- Publishing configuration fragments that include sensitive details
- Writing tool-specific instructions without explaining the underlying concept
- Letting pages drift away from current upstream behavior
## References
- [Diataxis](https://diataxis.fr/)
- [Write the Docs: Docs as Code](https://www.writethedocs.org/guide/docs-as-code/)
- [Markdown Guide](https://www.markdownguide.org/)

64
00 - About/about-hidden-den.md Normal file
View File

@@ -0,0 +1,64 @@
---
title: About Hidden Den
description: Overview of Hidden Den as a self-hosted engineering environment focused on privacy, durability, and human-scale infrastructure
tags:
- about
- homelab
- infrastructure
category: about
created: 2026-03-14
updated: 2026-03-14
---
# About Hidden Den
## Summary
Hidden Den is a self-hosted engineering environment centered on privacy, technical autonomy, durability, and human-scale infrastructure. It combines homelab systems, open source tooling, and practical DevOps workflows into a platform for running services, testing ideas, and documenting repeatable engineering patterns in a way that stays understandable over time.
## Why it matters
Many engineers operate personal infrastructure but leave the reasoning behind their systems undocumented or let it drift into a collection of tools without a clear operating model. Hidden Den exists to make the architecture, tradeoffs, and operating practices explicit while keeping the environment calm, maintainable, and fully owned by its operator.
## Core concepts
- Self-hosting as a way to understand and control critical services
- Privacy as both a philosophy and an implementation requirement
- Durable systems that can be migrated, backed up, repaired, and replaced
- Small, composable systems instead of opaque all-in-one stacks
- Documentation as part of the system, not separate from it
- Human-scale design that keeps technology legible and understandable
## Practical usage
Within the Hidden Den ecosystem, infrastructure topics typically include:
- Private access using VPN or zero-trust networking
- Virtualization and container workloads
- Reverse proxies, DNS, and service discovery
- Monitoring, backups, and update management
- Tooling that can be reproduced on standard Linux-based infrastructure
- Static or low-dependency publishing patterns when they reduce operational drag
## Best practices
- Prefer documented systems over convenient but fragile one-off fixes
- Keep infrastructure services understandable enough to rebuild
- Choose open standards and open source tools where practical
- Treat access control, backup, and observability as core services
- Favor warm, legible, low-friction systems over polished but opaque stacks
## Pitfalls
- Adding too many overlapping tools without a clear ownership model
- Relying on memory instead of written operational notes
- Exposing administrative services publicly when a private access layer is sufficient
- Allowing convenience to override maintainability
- Optimizing for image, novelty, or feature count instead of long-term operability
## References
- [The Twelve-Factor App](https://12factor.net/)
- [Tailscale: What is Tailscale?](https://tailscale.com/kb/1151/what-is-tailscale)
- [Docker: Docker overview](https://docs.docker.com/get-started/docker-overview/)
- [Proxmox VE Administration Guide](https://pve.proxmox.com/pve-docs/)

65
00 - About/design-principles.md Normal file
View File

@@ -0,0 +1,65 @@
---
title: Design Principles
description: Architectural and operational design principles used to shape Den Vault content and the systems it describes
tags:
- about
- design
- architecture
category: about
created: 2026-03-14
updated: 2026-03-14
---
# Design Principles
## Summary
Den Vault favors design principles that make systems easier to understand, operate, and recover. These principles apply to both the infrastructure being documented and the way documentation itself is structured.
## Why it matters
Without stable design principles, infrastructure turns into a collection of local optimizations that are difficult to audit and harder to maintain. Shared principles make it easier to evaluate tools, architecture choices, and documentation quality consistently.
## Core concepts
- Systems should be understandable by inspection
- Keep it durable: back up, migrate, repair, and replace
- Leave room for care in interfaces, naming, and operational ergonomics
- Stay practical when choosing tradeoffs and tooling
- Clear trust boundaries
- Minimal exposed surface area
- Declarative configuration where possible
- Explicit ownership of data, identity, and ingress paths
- Observability and recovery designed in from the start
## Practical usage
These principles usually lead to patterns such as:
- Private administrative access through VPN or dedicated management networks
- Reverse proxies and DNS as shared platform services
- Container and VM workloads with documented persistence boundaries
- Backup and restore strategy treated as a design requirement
- Low-dependency site and service architecture when that improves long-term maintainability
## Best practices
- Prefer one clear pattern over multiple overlapping ones
- Keep the path of a request or dependency easy to trace
- Design around failure domains, not only nominal behavior
- Make operational boundaries visible in diagrams, inventory, and docs
- Treat usability and readability as part of technical quality
## Pitfalls
- Mixing management, storage, and user traffic without a reasoned boundary
- Depending on defaults without documenting them
- Building fragile chains of dependencies for simple services
- Adding security controls that cannot be operated consistently
- Making systems colder, more complex, or more abstract than the problem requires
## References
- [The Twelve-Factor App](https://12factor.net/)
- [NGINX: Reverse Proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/)
- [Prometheus overview](https://prometheus.io/docs/introduction/overview/)

61
00 - About/documentation-philosophy.md Normal file
View File

@@ -0,0 +1,61 @@
---
title: Documentation Philosophy
description: Principles for writing durable, public-facing technical documentation in Den Vault
tags:
- about
- documentation
- writing
category: about
created: 2026-03-14
updated: 2026-03-14
---
# Documentation Philosophy
## Summary
Documentation in Den Vault is written to be durable, public, and technically useful. Each document should explain a concept clearly enough for another engineer to apply it without needing access to private context.
## Why it matters
Unstructured notes decay quickly. Public technical documentation only becomes valuable when it is scoped well, written clearly, and maintained as part of the normal engineering workflow.
## Core concepts
- Write reusable technical documentation, not private memory aids
- Prefer explanation plus implementation guidance over checklist-only pages
- Keep documents scoped so they can be updated without rewriting the entire vault
- Use frontmatter and predictable structure for discoverability
- Keep writing human-scale, legible, and maintainable rather than optimized for feed-style consumption
## Practical usage
In practice, this means:
- Explaining why a technology or pattern matters before diving into commands
- Using placeholders instead of sensitive values
- Linking to upstream docs for authoritative behavior
- Revising pages when tooling or best practices change
- Preserving enough warmth and clarity that the docs feel written for people, not dashboards
## Best practices
- Prefer official documentation and standards as primary sources
- State assumptions clearly when a topic has multiple valid designs
- Keep examples small enough to understand but complete enough to use
- Separate conceptual articles, operational guides, and tool references
- Avoid unnecessary jargon when simpler language communicates the same idea accurately
## Pitfalls
- Mixing personal environment details into public docs
- Copying large blocks from upstream sources instead of summarizing them
- Writing instructions that depend on outdated versions or defaults
- Creating giant pages that cover many unrelated concerns
- Writing in a polished but impersonal style that obscures the actual operational intent
## References
- [Diataxis](https://diataxis.fr/)
- [Write the Docs: Docs as Code](https://www.writethedocs.org/guide/docs-as-code/)
- [Google Developer Documentation Style Guide](https://developers.google.com/style)

64
00 - About/engineering-philosophy.md Normal file
View File

@@ -0,0 +1,64 @@
---
title: Engineering Philosophy
description: Engineering principles that guide system design, operations, and documentation in Den Vault
tags:
- about
- engineering
- philosophy
category: about
created: 2026-03-14
updated: 2026-03-14
---
# Engineering Philosophy
## Summary
The engineering philosophy behind Den Vault favors clarity, repeatability, small composable systems, and operational ownership. The goal is not to collect tools, but to build infrastructure that can be reasoned about, repaired, and evolved with confidence.
## Why it matters
Homelab and self-hosted environments often fail for social reasons rather than technical ones: unclear ownership, undocumented dependencies, and systems that only work while the original operator remembers every detail. A defined philosophy helps prevent that drift.
## Core concepts
- Understand the system before scaling the system
- Durability over short-term convenience
- Explicit dependencies over hidden coupling
- Safe defaults over permissive convenience
- Automation where it reduces toil, not where it removes understanding
- Documentation as part of operational readiness
- Practicality over ideological purity
## Practical usage
This philosophy affects decisions such as:
- Preferring documented deployment code over manual changes on hosts
- Choosing tools that can be inspected and reasoned about directly
- Separating management and user-facing services by trust boundary
- Using monitoring and backup validation as part of system design
- Keeping change scopes small enough to review and roll back
- Favoring systems that are calm and maintainable over systems that look impressive but are fragile
## Best practices
- Start with the smallest architecture that can be operated reliably
- Prefer tools with clear operational models and good documentation
- Review failure domains before adding new dependencies
- Keep recovery steps visible and tested
- Prefer systems that can be migrated and replaced without platform lock-in
## Pitfalls
- Choosing tools for feature count rather than supportability
- Building tightly coupled stacks that cannot be upgraded safely
- Automating critical changes without health checks or rollback thinking
- Treating production-like services as disposable experiments
- Mistaking complexity or aesthetics for engineering quality
## References
- [The Twelve-Factor App](https://12factor.net/)
- [Google SRE Book](https://sre.google/books/)
- [Diataxis](https://diataxis.fr/)

62
00 - About/how-this-knowledge-base-is-organized.md Normal file
View File

@@ -0,0 +1,62 @@
---
title: How This Knowledge Base Is Organized
description: Explanation of the folder structure and content model used by Den Vault
tags:
- about
- documentation
- structure
category: about
created: 2026-03-14
updated: 2026-03-14
---
# How This Knowledge Base Is Organized
## Summary
Den Vault is organized by document purpose rather than by one large mixed topic tree. The top-level structure separates foundational context, reusable knowledge, systems architecture, hands-on guides, reference material, learning notes, and tool documentation.
## Why it matters
A public knowledge base becomes hard to navigate when conceptual explanations, operational guides, and tool notes are mixed together. A consistent structure helps readers find the right kind of document quickly.
## Core concepts
- `00 - About`: project purpose, philosophy, and organizational context
- `10 - Projects`: project-specific documentation and initiatives
- `20 - Knowledge`: reusable concepts and architecture explanations
- `30 - Systems`: system-level patterns and higher-level design views
- `40 - Guides`: step-by-step implementation material
- `50 - Reference`: compact reference material
- `60 - Learning`: study notes and topic overviews
- `70 - Tools`: tool-specific deep dives and operational context
- `90 - Archive`: retired or superseded material
## Practical usage
When adding a document:
- Put conceptual explanations in `20 - Knowledge`
- Put architecture views and system patterns in `30 - Systems`
- Put procedural setup or operations documents in `40 - Guides`
- Put tool deep-dives and platform notes in `70 - Tools`
## Best practices
- Keep filenames specific and searchable
- Use frontmatter consistently for metadata and indexing
- Avoid duplicating the same topic in multiple places unless the purpose differs
- Link related concept, guide, and tool pages when it improves navigation
## Pitfalls
- Putting every page into one category because it is convenient in the moment
- Creating new top-level structures without a strong reason
- Mixing reference snippets with conceptual architecture writing
- Letting archived or outdated pages appear current
## References
- [Diataxis](https://diataxis.fr/)
- [Write the Docs: Docs as Code](https://www.writethedocs.org/guide/docs-as-code/)
- [GitHub Docs: Creating a table of contents for Markdown files](https://docs.github.com/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-collapsed-sections)

63
00 - About/infrastructure-overview.md Normal file
View File

@@ -0,0 +1,63 @@
---
title: Infrastructure Overview
description: High-level overview of the infrastructure domains documented within Hidden Den and Den Vault
tags:
- about
- infrastructure
- overview
category: about
created: 2026-03-14
updated: 2026-03-14
---
# Infrastructure Overview
## Summary
The infrastructure documented in Den Vault is built around a small set of repeatable domains: networking, compute, platform services, observability, security, and data protection. Together, these form a practical blueprint for self-hosted engineering environments.
## Why it matters
Readers need a clear map before diving into individual guides. An infrastructure overview helps explain how virtualization, containers, DNS, reverse proxying, monitoring, identity, and backups fit together as one operating model.
## Core concepts
- Networking and access: segmentation, VPN, DNS, ingress
- Compute: hypervisors, VMs, and container hosts
- Platform services: reverse proxy, service discovery, identity, secrets
- Operations: monitoring, alerting, backups, updates
- Tooling: documented platforms used to implement these layers
## Practical usage
A typical self-hosted environment described by Den Vault includes:
- Proxmox or equivalent compute hosts
- Docker-based application workloads
- Tailscale or another private access layer
- Reverse proxy and TLS termination with tools such as Caddy, Traefik, or NGINX
- Prometheus and Grafana for observability
- Backup tooling with regular validation
- Static or low-dependency site infrastructure where that aligns with privacy and maintainability goals
## Best practices
- Keep core platform services few in number and well understood
- Separate public ingress from administrative access paths
- Maintain inventory of systems, dependencies, and backup coverage
- Prefer architectures that can be rebuilt from documented source material
## Pitfalls
- Treating infrastructure as a pile of tools instead of a coherent system
- Running critical services without monitoring or backup validation
- Allowing naming, routing, and authentication patterns to drift over time
- Adding redundancy without understanding operational complexity
## References
- [Proxmox VE Administration Guide](https://pve.proxmox.com/pve-docs/)
- [Docker: Docker overview](https://docs.docker.com/get-started/docker-overview/)
- [Tailscale: What is Tailscale?](https://tailscale.com/kb/1151/what-is-tailscale)
- [Prometheus overview](https://prometheus.io/docs/introduction/overview/)
- [restic documentation](https://restic.readthedocs.io/en/latest/)