Systems & Projects

Overview

Open‑source LLMs run locally through Ollama, oMLX, LocalAI, LM Studio, and llama.cpp. This stack is the foundation of the knowledge reasoning engine and the SME platform.

The work also explores low‑cost AI development on limited hardware, including GPU‑accelerated inference on a repurposed Nvidia GPU.

Build

1. Local LLM runtimes

   Deployed Ollama, oMLX, LocalAI, LM Studio, and llama.cpp to run open‑source models locally.

2. GPU AI server

   Built and configured an Ubuntu‑based AI server using an older Nvidia GPU for local LLM deployment with Ollama, enabling GPU‑accelerated inference on repurposed hardware.

3. Docker MCP integration

   Integrated open‑source LLMs with Docker MCP tools and runners through Ollama and LM Studio.

4. AI‑assisted workflows

   Used AI Code to collaborate with AI on DevOps tasks, and explored prompt engineering, context engineering, and knowledge workflows.

Key Outcomes

• GPU‑accelerated local inference on repurposed hardware
• Prototype knowledge reasoning AI engine built as a full pipeline
• Foundation for the SME Training Program Engine (ongoing development)

Overview

A deterministic, token‑driven workflow for developing structured SME applications. It moves through four stages, from Visual Development Architecture to Spec‑Driven Development.

DESIGN.md is the contract throughout: fonts, palettes, spacing, and radii are locked, and outputs stay deterministic across runs.

Stages

1. VDA · Visual Development Architecture

   Reads DESIGN.md and locks fonts, palettes, spacing, and radii. Visual consistency is enforced, with no ad‑hoc values.

2. IDD · Interface‑Driven Development

   Starts from the interface and decomposes it into layout, components, and tokens, keeping UI thinking structured.

3. CDD · Component‑Driven Development

   Everything is reusable, token‑based, and deterministic, with parity between light and dark modes.

4. SDD · Spec‑Driven Development

   Outputs specs in YAML, JSON, HTML, and CSS that reference tokens only.

Key Outcomes

• Deterministic outputs across runs
• Visual consistency with no ad‑hoc values
• Light and dark mode parity by design
• DESIGN.md as the single contract for every stage

Overview

Ansible was learned and implemented for declarative infrastructure management. Six to seven modular playbooks cover container deployment, service configuration, and system hardening.

Every workflow is validated for idempotence and reproducibility across nodes, and documented for future automation.

Process

1. Playbook authoring

   Authored 6–7 modular playbooks for container deployment, service configuration, and system hardening.

2. SSH & inventory integration

   Integrated Ansible with SSH and inventory files for inventory‑based orchestration.

3. Validation

   Validated idempotence and reproducibility across nodes.

4. Documentation

   Documented each workflow for future automation.

Key Outcomes

• Declarative infrastructure
• Idempotent workflows
• Reproducible results across nodes
• Inventory‑based orchestration

Overview

The reverse proxy layer handles HTTPS for internal services and for the public‑facing blog on a custom domain. Nginx Proxy Manager uses DNS‑01 for internal services and HTTP‑01 for the blog.

Caddy was added to the local personal cloud on a MacBook, giving localhost services secure access without manual certificate handling.

Architecture

1. Nginx Proxy Manager

   Configured with DNS‑01 for internal services and HTTP‑01 for the public‑facing blog with a custom domain.

2. Caddy on the local cloud

   Provides reverse proxy, load balancing, automatic HTTPS, and local wildcard TLS for localhost services.

3. Web hosting

   The self‑hosted WordPress blog runs with its own domain and HTTPS configuration, with SSL certificates managed through DNS‑01 and HTTP‑01.

4. Network layer

   Proxmox bridges, VLANs, routing, and segmentation are managed alongside the proxy layer.

Key Outcomes

• Secure access to local services without manual certificate handling
• Automatic HTTPS and local wildcard TLS
• Public blog served on a custom domain over HTTPS

Overview

These clusters were built during the compute layer expansion, alongside the 3‑node Proxmox cluster that powers the custom VPC.

MicroCloud forms the OS layer across physical nodes, while k3s and MicroK8s handle lightweight Kubernetes orchestration at the app layer.

Architecture

1. MicroCloud · OS layer

   Deployed MicroCloud clusters across physical nodes for secure, scalable micro‑cloud infrastructure.

2. k3s & MicroK8s · App layer

   Built k3s clusters for lightweight Kubernetes orchestration, with MicroK8s also running at the app layer.

3. LXD containers

   Deployed LXD containers inside Proxmox VMs for lightweight virtualization.

4. Edge & bare‑metal nodes

   Integrated bare‑metal nodes and Raspberry Pi edge nodes into the compute fabric.

Key Outcomes

• Secure, scalable micro‑cloud infrastructure
• Lightweight Kubernetes orchestration at the app layer
• Bare‑metal and Raspberry Pi nodes unified in one compute fabric

Overview

Credentials are stored in a self‑hosted Vaultwarden, SSH access is hardened through a custom configuration, and secrets follow documented rotation schedules.

The approach applies least privilege, secure defaults, and access control, with STRIDE threat modeling across key services.

Process

1. SSH hardening

   A custom sshd_config enforces key‑based authentication, disabled root login, a custom port, session limits, and modern crypto. Agent forwarding, TCP/X11 forwarding, and tunnels are disabled.

2. Secrets registry

   Created a modular registry of secrets with rotation schedules, tracked in a future‑proof YAML/Markdown schema.

3. Rotation workflows

   Rotated SSH keys, API tokens, and TLS certificates, logged each rotation event, and updated dependent services.

4. Threat modeling & checklists

   Applied STRIDE to Vaultwarden, Proxmox, and WordPress, identifying assets, entry points, and data flows. Vault‑ready checklists cover secure configuration, patching, and monitoring.

Key Outcomes

• Scheduled, logged rotation across SSH, API, and TLS secrets
• Hardened SSH access with key‑based authentication only
• Fail2ban and UFW deployed with advanced configuration
• Security practices documented for future audits