Uses
++ This page is a window into the workshop behind Hidden Den Cafe. + It is less about a perfect spec sheet and more about the tools I + actually reach for to write code, run infrastructure, and keep + exploring how much of the internet I can build on my own terms. + Some of it lives on my desk, some of it lives in the homelab, + and some of it lives in carefully chosen external systems. +
+Personal Computing Environment
+Windows + Ubuntu on WSL2
++ My day-to-day machine is a Windows workstation with an Ubuntu + environment inside WSL2. It gives me a practical desktop setup + while keeping most of my actual work in a Linux shell where I + can script, build, and debug with less friction. +
+Terminal + Bash
++ Bash is still where a lot of real work happens for me. If a task + can be expressed as a clean command, script, or container build, + that is usually the route I prefer because it stays close to the + system instead of hiding it behind layers of UI. +
+Zed
++ Zed + is my primary editor. I like it because it is extremely fast, + modern without feeling bloated, and built for the kind of + collaborative and AI-assisted development workflow I spend a lot + of time experimenting with. +
+Fast tools, low friction
++ I am happiest when tools respond immediately and get out of the + way. Markdown, plain text configs, and lightweight utilities + matter to me because they keep the system inspectable and make it + easier to move from idea to experiment without losing momentum. +
+Development Tools
+Python first, Astro on purpose
++ A lot of my background is in Python and Flask-style thinking: + simple services, clear behavior, and tooling I can reason about. + Cozy Den is also where I am learning Astro because it fits the + small-web, static-first approach I want for personal sites. +
+Git + self-hosted Gitea
++ Version control lives on my own Gitea instance at + git.hiddenden.cafe. + I use it both as a code forge and as part of the deployment path. +
+Docker
++ Containers are the default way I package and move projects. I + like being able to build something once, understand its runtime, + and ship the same artifact to the machines that need it. +
+TypeScript, Markdown, and plain files
++ I use typed configs where they help, Markdown where writing + should stay lightweight, and plain files wherever possible so the + project remains durable without a huge stack around it. +
+Editor-driven exploration
++ A lot of experimentation starts in the editor: quick prototypes, + note fragments, config drafts, and partial implementations. I + prefer tools that make it easy to move between writing, coding, + terminal work, and AI-assisted iteration in one place. +
+AI Tools
+Model mix, not model worship
++ I actively experiment with multiple AI systems, including OpenAI, + OpenAI Business, Claude, Mistral, Ollama, OpenRouter, and + Microsoft Foundry. Different tools are better at different kinds + of work, so I treat them as instruments rather than as a single + source of truth. +
+Development and drafting support
++ AI is useful for implementation support, debugging odd edge cases, + brainstorming approaches, writing rough drafts, and pressure-testing + architectural ideas. It helps me move faster, but it does not get + to replace judgment, taste, or authorship. +
+Local and hosted experimentation
++ Some experiments belong in cloud APIs, some belong in local model + runtimes. I am interested in both, especially where privacy, + controllability, and cost start to matter. +
+Human ideas stay human
++ The point is not to automate away authorship. The point is to + extend what I can build, test, and think through while keeping + the taste, priorities, and final decisions my own. +
+Infrastructure & Homelab
+Proxmox cluster
++ A lot of the lab side of my work is built around a Proxmox-based + cluster. It acts as a workshop environment where services and + ideas get built, tested, broken, rebuilt, and slowly turned into + something stable enough to keep. +
+Multiple nodes, mixed workloads
++ The homelab is not a single-box setup. It spans multiple nodes + running both experimental and production services, which makes it + useful for trying things out without forcing every idea directly + into the same environment. +
+Self-hosted services
++ Gitea is part of that stack already, and more services tend to + follow the same philosophy: if I can run it myself without making + life worse, I would rather understand the system than outsource + it by default. +
+Persistent storage
++ Persistent data matters, so storage gets treated as infrastructure, + not an afterthought. That includes self-hosted storage with tools + like OpenMediaVault and the kind of planning that keeps the lab + useful as it grows rather than turning into a graveyard of disks. +
+Networking foundation
++ The network is built around a UniFi UDM Pro Max, which acts as the + core router and network controller for the environment. I want the + network to be stable first, then segmented where useful, with + secure remote access and reliable routing between local services + and the systems that need to be reachable from the outside. +
+Tailscale for remote reachability
++ Tailscale is part of the connective tissue that makes the lab feel + usable from anywhere. I like tools that make remote access simple + without turning the whole setup into a networking puzzle. +
+Identity & Cloud Services
+Microsoft Entra
++ Entra is part of how I think about identity and access in the + broader environment. It is useful where centralized identity, + policy, and account management make sense. +
+Microsoft Intune
++ Intune fits into the device and policy side of the stack. I do not + see that as a replacement for understanding systems directly, but + it is practical where managed devices and consistent policy matter. +
+Microsoft Azure
++ Azure is part of the cloud experimentation side of the workshop: + useful for testing ideas, running services that do not belong at + home, and understanding how managed infrastructure behaves in the + real world. +
+Homelab first, cloud where it helps
++ These Microsoft services complement the homelab rather than + replacing it. I still prefer running and understanding systems + directly whenever possible, but I am not interested in pretending + cloud tooling has no value when it clearly does. +
+External Hosting
+OVH
++ OVH is part of the external VPS layer I use when a service needs + public accessibility, geographic separation, or a home outside the + local lab. +
+VPS.play.hosting
++ VPS.play.hosting fills a similar role for additional external + services. I like having more than one place to run things when the + goal is resilience rather than putting every dependency in one box. +
+Hybrid infrastructure
++ Not everything belongs in the homelab, and not everything belongs + in the cloud. The useful middle ground is a hybrid setup where + local infrastructure and external VPS systems complement each other + instead of competing. +
+Security & Identity
+Hardware-backed authentication
++ I prefer security that is boring and strong. Hardware keys such as + YubiKeys make more sense to me than pretending a password alone is + enough for important accounts. +
+GPG and identity hygiene
++ Cryptographic identity is part of the workflow here. I publish my + keys, use GPG where it is useful, and try to keep trust anchored in + things I can verify instead of platforms asking to be trusted. +
+Password managers and compartmentalization
++ Good security is mostly consistency. Unique secrets, sensible + separation between roles and systems, and fewer scattered accounts + beat dramatic security theater every time. +
+Privacy as a design constraint
++ I do not chase privacy because it sounds noble. I care about it + because it changes architecture choices: fewer unnecessary + dependencies, less telemetry, tighter control over where data ends + up, and a better understanding of what the system is doing. +
+Website Stack
+Astro
++ Cozy Den itself is built with Astro because static HTML is still + one of the nicest ways to publish a personal site. +
+Vanilla CSS + TypeScript
++ Styling stays close to the markup, and the TypeScript that exists + is there to make content and structure safer rather than heavier. +
+Docker + nginx
++ The site builds in a container and ships as static files served by + nginx, which keeps deployment small, repeatable, and easy to audit. +
+Gitea-driven deployment path
++ Source, registry, and release flow all stay close to my own + infrastructure instead of depending on a hosted publishing platform. +
+Secondary to the workshop
++ The site stack matters, but it is only one part of the broader + ecosystem. Cozy Den exists because of the surrounding tools, + machines, services, and habits that make building on my own terms + possible. +
++ This page is a living snapshot of the tools and systems behind Cozy Den. + It changes from time to time as experiments evolve and the workshop grows. +
+