Dashy is a self-hosted dashboard application that serves as a customizable startpage and service monitor for homelabs and server infrastructure. In production, it aggregates links to internal and external services, displays live widgets (weather, system metrics, crypto prices, news, etc.), and performs HTTP/ICMP status checks to indicate service health. The application is configured entirely via a YAML file (conf.yml) that defines pages, sections, items, widgets, authentication providers, themes, and layout options. Users can interact through multiple views: a default grid, a workspace with sidebar and iframe content, and a minimal tabbed view. The system also includes an interactive configuration editor, cloud backup/restore with AES encryption, and full REST API for programmatic management. Architecturally, Dashy is a full-stack web application with a Vue 3 frontend (built with Vite) and a Node.js Express backend. The frontend handles rendering, theming, localization (30+ languages), and client-side authentication flows (OIDC, Keycloak, header auth, built-in users). The backend provides endpoints for config saving, CORS proxying (with SSRF protection), status/ping checks, and optional REST API. Deployment is Docker-first, but bare-metal, cloud (Netlify, Render), and static hosting are also supported. The codebase is organized into reusable mixins (WidgetMixin, ThemingMixin, HomeMixin), custom Vue directives (DragSort, Tooltip, LongPress), and a schema-driven configuration system that powers both validation and the CodeMirror-based YAML editor. Key data flows include: (1) configuration loading from file and localStorage, merged by the ConfigAccumulator; (2) widget data fetching via the CORS proxy or direct API calls, with standardized error handling and update intervals; (3) authentication token exchange and session management across client and server; (4) status checks that update item indicators in real-time. External dependencies are limited to Node.js, Vue 3, Express, and a handful of widget-specific APIs (OpenWeatherMap, CoinGecko, etc.), all of which are optional and configurable. The project is purely an application with no data research or analytics components.
This repository hosts a curated collection of over 1800 dashboard icons for self-hosted services and applications, accompanied by a full-stack web application for browsing, searching, downloading, and submitting icons. The frontend is built with Next.js 16, React 19, Tailwind CSS 4, and shadcn/ui components, and it uses PocketBase as the backend for authentication, icon submissions, and external icon source management. The application provides an MCP (Model Context Protocol) server endpoint that allows AI assistants to search icons and resolve CDN URLs. It also includes an SVG color customizer for inline theme adjustments, a community submission workflow with admin approval, and automated syncs from third-party sources (Simple Icons, selfh.st, LobeHub). The codebase is well-structured with modern tooling, CI/CD pipelines, and both unit and end-to-end tests. While the repository is primarily an icon asset collection, the accompanying web application delivers significant value through its search, customization, and community features.
This repository hosts Homepage, a self-hosted dashboard application for homelab and server enthusiasts. Built with Next.js and React, it aggregates data from over 100 external services (media servers, download clients, network tools, system monitors) via a centralized proxy architecture. The system is configuration-driven: users define services, bookmarks, widgets, and settings in YAML files, optionally extended via Docker labels or Kubernetes ingress annotations. A key architectural pattern is the widget system, where each integration consists of a React component, a proxy handler (handling authentication, session management, and data transformation), and a widget metadata file. The backend API routes handle proxying, caching, authentication (NextAuth with OIDC/password), Docker/Proxmox stats, weather, stocks, and an MCP endpoint for AI-assisted configuration. The frontend uses SWR for client-side data fetching, Tailwind CSS for theming, and i18next for internationalization (20+ languages). The codebase exhibits solid engineering practices: comprehensive test coverage (Vitest), CI/CD pipelines (GitHub Actions), Docker multi-arch builds, and extensive documentation. However, the large widget surface introduces duplication in authentication and proxy logic, and some patterns (in-memory caching, version-specific endpoints) represent maintenance risks. Overall, this is a well-crafted application for its domain, offering high customizability and a clean plugin-style architecture.
tsbridge is a production-grade reverse proxy that exposes multiple backend services on a Tailscale tailnet using isolated tsnet nodes per service. It supports static TOML configuration and dynamic Docker label discovery, with hot-reload, graceful shutdown, Prometheus metrics, and a composable middleware chain (access log, whois identity lookup, request ID, body size limits, header sanitization). The architecture is a single Go binary that manages per-service tsnet.Server instances, each with its own state directory and listener. External dependencies are Tailscale (tsnet), Docker (optional), and Prometheus. The codebase demonstrates strong engineering practices: interface-based abstractions (TSNetServer, config.Provider), typed error hierarchy, secret resolution with redaction, debounced event handling with exponential backoff, and comprehensive unit and integration tests. It is actively maintained with CI/CD, dependabot, and regular dependency updates.
Dawarich is a production Ruby on Rails 8 monolith for personal location history tracking, positioning itself as a self-hostable Google Timeline replacement. It ingests timestamped geospatial points from a broad range of trackers (OwnTracks, Overland, Traccar) and file formats (GPX, GeoJSON, KML/KMZ, TCX, FIT, CSV, Google Takeout), then drives them through heavy background processing: reverse geocoding, anomaly filtering, visit detection, track generation, transportation-mode classification, trip building, and monthly/yearly statistics with digest emails. The web frontend is a MapLibre GL JavaScript application using vector-tile rendering, WebSocket real-time updates, and novel in-browser encoding studios for route videos (WebCodecs MP4) and printable posters (hand-rolled PNG encoder). The system also integrates photo libraries (Immich, PhotoPrism), flight logs (AirTrail), TeslaMate, and TREK trip planning, plus family location sharing, achievements, and an MCP API endpoint. Architecturally it is a conventional but well-executed Rails service-object monolith: controllers are thin, domain logic lives in app/services (command pattern with call methods), heavy processing is delegated to a large Sidekiq job surface with named queues, and cross-process coordination uses Redis-based debouncers, per-user advisory locks, and tile epochs for cache invalidation. PostGIS powers spatial queries (ST_DWithin, lonlat geography, H3 hexagons, vector tiles). The codebase ships dual-mode: self-hosted Docker deployments and a cloud SaaS with subscription/entitlement gating, with many env-conditional branches. Test coverage is extensive (RSpec with regression specs for timezone/race/geospatial edge cases, Playwright e2e, locale-parity and schedule-consistency specs), CI includes RuboCop, Trivy, and Dependabot. The strongest engineering is in the data-ingestion and processing layer: streaming SAX-style JSON parsers for huge Google Takeout files, batched upsert with deduplication and Null Island filtering, deterministic nearest-centroid transportation-mode classification with explicit explainability, and Redis coordination patterns for geocoding claims and per-user job locks. Weaknesses include a sprawling surface area (35+ service subdomains in one repo), significant schema churn via migration-enqueued backfill jobs, and dual self-hosted/cloud branches that add cognitive load. Overall this is a well-maintained, feature-complete application with genuinely reusable geospatial and streaming-data patterns.
This repository is a personal Nix configuration (dotfiles) for managing a heterogeneous fleet of machines: NixOS desktops and servers, macOS laptops (via nix-darwin), and Kubernetes clusters (k3s, KubeVirt). It is structured as a Nix flake with modular components for system configuration, home-manager profiles, package overlays, secrets management (agenix), and infrastructure monitoring (Grafana, Prometheus, VictoriaMetrics, Loki). The codebase demonstrates advanced Nix patterns: parameterized module generators for K3s and KubeVirt, automatic file scanning for module imports, declarative disk partitioning (disko), ephemeral root filesystems with persistent state (preservation), and sandboxed GUI applications (nixpak, bwrap). It also includes a custom desktop shell (noctalia) and extensive input method customization (Rime/Fcitx5). While highly personalized and not intended for direct reuse, the architectural patterns and modular design serve as a reference for building complex Nix-based infrastructure. The repository is actively maintained with eval tests and CI, but lacks integration tests for runtime services.
Jotty (formerly rwMarkable) is a full-stack, self-hosted productivity application for managing notes, checklists, and Kanban boards. It uses Next.js 16 (App Router), React 19, and TypeScript with a file-based storage system (Markdown files with YAML frontmatter). Key features include rich text editing (TipTap with custom extensions for diagrams, callouts, mentions), drag-and-drop (custom DnD engine for Kanban, @dnd-kit for checklists), user management with multiple authentication methods (local, LDAP, OIDC), MFA (TOTP), encryption (PGP, XChaCha20), granular sharing with permission inheritance, version history via Git, full-text search using grep, audit logging, and a PWA with offline support. The architecture is server-first with Next.js server actions for all mutations and a WebSocket broadcast for real-time updates. The codebase is well-organized with a clear separation of concerns: global UI components, feature-specific components, server actions, types, utilities, and hooks. It has extensive test coverage (Vitest) across server actions, API routes, utilities, and security. While file-based storage imposes scalability limitations, the application demonstrates high craftsmanship in its modular design, custom drag-and-drop implementation, encryption handling, and sharing system. It is actively maintained with regular releases and community contributions.
Khue's Homelab is a GitOps-driven infrastructure-as-code framework that automates a complete self-hosted Kubernetes platform from bare metal to user-facing applications. The codebase is organized into five layers: metal (Ansible roles that PXE-boot Fedora Server, bootstrap a k3s cluster with kube-vip HA, and install Cilium for networking/load balancing), system (bootstrap Helm charts for ArgoCD, cert-manager, ingress-nginx, Rook Ceph, and monitoring), platform (Gitea, Woodpecker CI, Grafana, Kanidm identity, Dex SSO, zot container registry), apps (Jellyfin + the *arr stack, Matrix, Paperless, Ollama, and more), and external (Terraform-managed Cloudflare DNS, tunnel, and ntfy alerting). ArgoCD ApplicationSets watch the git repository and deploy every Helm chart, making the repo itself the source of truth; a single top-level `make` drives the entire pipeline. The project demonstrates strong IaC craftsmanship: idempotent Ansible roles with checksum-verified downloads and run_once state handling (k3s token genesis, kubeconfig extraction), an ephemeral PXE server with per-MAC kickstart files and DHCP-proxy mode, declarative random secret generation via a small Go tool combined with the External Secrets Operator for cross-namespace secret sync, and a Terraform module that creates least-privilege Cloudflare API tokens injected directly into the cluster. It also includes a Nix dev shell for reproducible tooling, pre-commit hooks, Woodpecker CI that renders Helm diffs on pull requests, and Terratest-based smoke/integration/version tests. The author explicitly labels the project ALPHA and recommends forking for personal use. It is best treated as a reference architecture and a collection of reusable provisioning patterns rather than a turnkey product; some portions (scripts/hacks, take-screenshots, the gitea config job) are acknowledged work-in-progress, and a few pinned versions lag the ecosystem (Go 1.19 in-cluster compile jobs, k3s 1.30, several stale container image tags).
Runtipi is a self-hosted homeserver orchestrator: a web-based control plane for installing, updating, backing up, and managing Docker Compose applications on a single server. In production it runs as a NestJS backend, a React frontend, and a shared TypeScript schema package, with PostgreSQL as the primary datastore, RabbitMQ for asynchronous job queues, Dockerode for container control, and Traefik as the reverse proxy and TLS/forward-auth gateway. The app-store model clones external git repositories containing app manifests and compose definitions, then validates and renders them through a dynamic form system. The architecture is a monolithic backend organized around modules for app lifecycle, marketplace, app stores, backups, auth, links, settings, and i18n; long-running operations are executed through a command/handler pattern with per-app async mutexes and schema-validated RabbitMQ event queues.
This repository is a large collection of Bash scripts that automate the deployment, configuration, and update of self-hosted services on Proxmox VE, primarily through LXC containers and VMs. It is a provisioning and automation framework rather than a runtime application: each ct/*.sh script declares resource variables (CPU, RAM, disk, OS template) and an optional update_script(), while install/*.sh scripts run inside an existing container to install a specific application. Usage is typically a one-line curl command executed as root on the Proxmox host, after which the script creates a container/VM, installs dependencies, generates credentials, writes systemd units or OpenRC init scripts, and configures databases and reverse proxies. The architecture is layered: hundreds of app-specific scripts wrap a smaller set of shared Bash function libraries in the misc/ directory (build.func, install.func, vm-core.func, core.func, error_handler.func). These shared functions handle common operations such as fetching GitHub releases, setting up language runtimes, creating databases, backing up configs before updates, and standardizing error handling. Update flows generally stop the service, back up configuration/data, fetch the latest release, restore the backup, run migrations, and restart the service. This consistency is the project's main strength and makes adding a new container recipe relatively straightforward. Weaknesses are typical of a large community-driven shell-script collection: no unit tests, heavy reliance on third-party installers fetched via curl|bash, some hardcoded versions, and external dependencies on GitHub release asset names and remote core-library URLs. Many scripts assume Debian/Ubuntu or Alpine bases and run as root with no signature verification. Despite these risks, the codebase is actively maintained, consistently formatted, and the shared function libraries are practical examples of reusable Bash abstractions for Proxmox automation.
HomeTube is a Streamlit-based web application for downloading and managing media from YouTube and 1800+ other platforms via yt-dlp. It provides a rich UI for URL analysis, quality profile selection (AV1/VP9/H.264), subtitle embedding, video cutting (keyframe/precise), SponsorBlock ad removal, and playlist synchronization with full diff-based state management. The architecture is a monolithic Streamlit app with heavy subprocess orchestration of yt-dlp and ffmpeg, backed by a typed configuration system, JSON-based workspace state files, and a comprehensive test suite with mocked Streamlit dependencies. Designed for homelab deployment, it includes Docker multi-arch builds, Nginx reverse proxy config, and daily automated rebuilds to stay current with yt-dlp updates. Core data flows: URLs are analyzed via yt-dlp (with client fallback chain default → ios → web), metadata is cached in url_info.json, download strategies are computed using format profile matching (codec priorities, audio language detection), and final files are moved to a configurable destination with optional hardlinking. Playlists are handled via a dedicated sync module that computes rename/archive/delete plans and applies them with dry-run support. The system emphasizes resilience through generic file naming, temporary workspace preservation, and intelligent caching that refuses to overwrite premium AV1/VP9 metadata with lower-quality data. The application is not a data research project; it is a production-ready media downloader and manager with no ML or analytical components. Its complexity lies in data integrity patterns (metadata caching, state machines, filesystem mutations) rather than data science.
This repository is a comprehensive, declarative NixOS homelab configuration managed with the Clan framework. It defines the entire infrastructure for a multi-machine homelab including servers, desktops, and network devices, all version-controlled and reproducible. The system provisions self-hosted services (Caddy, Grafana, VictoriaMetrics, Vector, Blocky, Miniflux, Linkding, etc.), identity management (Authentik, Zitadel), monitoring and alerting, backup (Borgbackup), and desktop environments (KDE, i3). The architecture is modular: reusable NixOS feature modules under `modules/nixos/features/` follow a consistent pattern using `mkFeatureOptions` for enabling services with standardized options (domain, firewall, monitoring integration). Secrets are managed via SOPS with age encryption, and disk partitioning is handled by Disko templates. The repository is not a software application but an infrastructure-as-code project that demonstrates high craftsmanship in Nix module design, with clear separation of concerns, helper functions, and integration patterns. It is actively maintained but shows some technical drift due to deprecated identity providers and hardcoded IPs.
ScaleTail is a curated collection of Docker Compose configurations for self-hosting 80+ services with a consistent Tailscale sidecar pattern. Each service directory contains a `compose.yaml` that defines a `tailscale` container (using `tailscale/tailscale:latest`) and an application container using `network_mode: service:tailscale`, enabling secure HTTPS access via Tailscale Serve or MagicDNS. The repository provides environment-driven configuration (`.env` files), health checks, and per-service READMEs. It is not a standalone application or library but a deployment template repository. The dominant character is 'application' as it facilitates deploying applications, though it is purely configuration and documentation. The pattern is highly reusable for any Docker-based self-hosted service wanting Tailscale integration.
Glance is a self-hostable web application designed as a customizable dashboard (startpage) that aggregates information from various sources into widgets. Built in Go, it features a modular widget architecture where each widget type (e.g., RSS, weather, clock) implements a common interface, allowing users to create personalized pages with multiple columns and widgets. The application serves HTML pages with embedded static assets (CSS, JS, images) and uses Go templates for server-side rendering, enhanced by a comprehensive set of template functions. Client-side JavaScript adds interactivity for dynamic updates, masonry layouts, and popovers. The system relies on a YAML-driven configuration (`glance.yml`) that supports variable substitution, file includes, and defines pages, columns, and widget settings. Data fetching is handled by centralized HTTP utilities with caching and user-agent rotation to avoid blocking external services. A theming system generates CSS variables from HSL-based configuration, enabling light/dark modes and custom themes. Optional authentication secures the dashboard, and the application includes diagnostic and CLI tools for maintenance. While the project demonstrates strong engineering in areas like request deduplication (singleflight), flexible configuration, and reusable template functions, it faces challenges due to its extensive widget proliferation (30+ types), coupling between frontend and backend logic, and reliance on an outdated Go version (1.26.6) which is no longer supported, indicating moderate technical drift. Despite these issues, Glance remains a popular and functional solution for personal dashboards.
This repository is a comprehensive collection of infrastructure-as-code configurations for self-hosting a wide variety of services, primarily aimed at homelab enthusiasts and followers of the Jim's Garage YouTube channel. It contains Docker Compose files, Kubernetes manifests, Ansible playbooks, and shell scripts that deploy services such as Traefik, PiHole, Plex, Jellyfin, Immich, Vaultwarden, Gitea, and many more. The central architectural pattern is a reverse proxy (Traefik or Caddy) with Cloudflare DNS-01 certificate challenges, with all services attached to a shared Docker network. The repository is not a single application but a set of modular, copy-paste-friendly deployment blueprints that can be adapted to different environments by changing IP addresses, domain names, and secrets. The codebase demonstrates strong organizational patterns—consistent Traefik labels, Kubernetes IngressRoutes with security middleware, and Ansible roles for cluster provisioning. However, the repository displays technical drift: some scripts pin outdated versions (e.g., kube-vip v0.6.3, MetalLB v0.12.1), and many files use `:latest` image tags, reducing reproducibility. Hardcoded IPs and dummy secrets (annotated with `# gitleaks:allow`) are present throughout, which is acceptable for a tutorial but requires careful sanitization before production use. The inclusion of multiple orchestration options (Docker Compose, Swarm, K3S, RKE2, Ansible) provides flexibility but can confuse users about which path to follow. As a learning resource, the repository is well-structured and actively maintained, with pre-commit hooks, GitHub Actions linting, and gitleaks integration. It is not a reusable library or service but a collection of reference configurations that can be extracted and adapted. The most reusable components are the Ansible roles for RKE2 deployment, the Traefik reverse proxy configuration, and the Kubernetes defaults-headers middleware pattern. Overall, the repository serves its educational purpose effectively while offering practical templates for homelab automation.
This repository provides documentation and automation scripts for setting up a Kubernetes cluster from scratch using VirtualBox. It includes shell scripts for creating and configuring VM images with cloud-init, configuration files for various Kubernetes components (etcd, control plane, worker nodes, HAProxy load balancers), and detailed documentation explaining the setup process. The repository serves as an educational guide for understanding Kubernetes infrastructure components and how they interact, rather than a deployable application itself. The main value lies in the well-structured automation scripts and comprehensive documentation that walk users through building a complete Kubernetes cluster with high availability features.