thehardwarestore.ai

Appwrite is an open-source backend-as-a-service (BaaS) platform that provides a comprehensive set of APIs for authentication, databases, storage, serverless functions, messaging, realtime, and more. The codebase is a hybrid monolithic-microservice architecture: a central PHP application (using the Swoole coroutine-based HTTP server) handles REST, GraphQL, and WebSocket requests, while background workers (over 20 types) process asynchronous tasks such as email delivery, function execution, database migrations, and usage analytics. The platform supports multiple database backends (MariaDB, MongoDB, PostgreSQL, ClickHouse) and a variety of messaging providers (SMS, email, push). It is designed for multi-tenant deployments with per-project isolation, OAuth2 social login, and extensive API versioning. The repository also contains a large collection of reusable PHP packages (the Utopia framework) that provide caching, queueing, query building, DNS resolution, NATS messaging, HTTP client, PSR-7 implementation, and more. These packages are independently published and can be extracted for use in other projects.

Uptime Kuma is a self-hosted, open-source uptime monitoring application that periodically checks the availability and response time of services (HTTP, TCP, DNS, databases, Docker containers, and many more) and sends alerts via 90+ notification providers. The system is a monolithic Node.js/Express backend with a Vue 3 SPA frontend, using Socket.IO for real-time updates and SQLite or MariaDB for persistence. It provides status pages, maintenance windows, certificate/domain expiry monitoring, and a Prometheus metrics endpoint. The architecture follows a plugin pattern for monitor types and notification providers, both built on base classes, and includes a condition evaluation system for advanced alerting logic. The codebase is well-structured with clear separation of concerns, extensive tests (unit, integration, e2e), and active community contributions.

Dockge is a self-hosted web application for managing Docker Compose stacks. It provides a graphical interface to create, edit, deploy, and manage stacks composed of multiple containers. The application supports managing multiple Docker hosts (agents) from a single interface, enabling centralized control of distributed Docker environments. Key features include a web-based terminal for container access, real-time updates via Socket.io, stack lifecycle management, and extensive customization through settings and environment variables. The architecture consists of a Node.js/Express backend with Socket.io for real-time communication and a Vue.js 3 frontend built with Vite. The backend handles Docker interactions, database operations (using SQLite or MySQL for metadata), and agent management, while the frontend delivers a responsive UI with internationalization support. Data flows involve the frontend sending user actions to the backend via Socket.io, which then interacts with the Docker daemon (local or via agents) and persists stack definitions as compose.yaml files on disk. The system emphasizes a file-based approach for stack definitions, ensuring portability and transparency. Dockge demonstrates strong engineering practices through its modular design, including isolated components for settings caching, terminal management, rate limiting, and an extensible agent system. These components exhibit low coupling and high reusability, adhering to principles of separation of concerns and maintainability. The application also incorporates modern development practices such as multi-stage Docker builds, automated CI/CD, and comprehensive test coverage (though not detailed in the provided summaries, the presence of CI workflows suggests testing efforts).

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.

SparkyFitness is a large, self-hosted fitness and health tracking platform. It is primarily an application: a full-stack monorepo with an Express + PostgreSQL backend, a React web frontend, a React Native/Expo mobile app, and a Python FastAPI Garmin microservice, all coordinated by a shared TypeScript package containing Zod schemas, constants, and domain algorithms. The product covers nutrition, workouts, sleep, fasting, mood, cycle/pregnancy, medications, symptoms, water intake, mindfulness, and health-provider data from Garmin, Fitbit, Withings, Oura, Polar, Strava, Google Health, and others. It also includes an AI chatbot with tool calling, barcode scanning, CSV/FIT imports, and native HealthKit/Health Connect sync. The dominant data flow is client hooks calling typed API service layers, which hit Express routes backed by PostgreSQL with row-level security. External wearable integrations refresh OAuth tokens under row locks and use provider sync claims to avoid duplicate imports. The mobile clients also directly read/write platform health stores, and a large migration set evolves the schema with careful backfills and deduplication. The repository is not a data-research repo; there are no analytical notebooks or dbt-style pipelines. Its character is clearly a production application with an unusually wide feature surface. The codebase shows strong engineering discipline: shared Zod schema triples, consistent TanStack Query key factories, central cache invalidation hubs, provider sync concurrency controls, and extensive Vitest/Jest tests, including regression tests pinned to GitHub issue numbers. The main risks are breadth-driven complexity: many external integrations, native iOS/Android/watch targets, manual patches to generated schemas, and some duplicated logic across web and mobile. Overall it is actively maintained, well-tested, and offers several genuinely reusable patterns.

Dokku is a production-grade, self-hosted Platform as a Service (PaaS) that manages the full lifecycle of containerized applications. Its architecture is a plugin-based monolith orchestrated by a core Go binary, where every feature (builders, schedulers, proxies, storage, config) is a self-contained plugin that hooks into lifecycle triggers (plugn system). It supports deployment via git push, archives, or Docker images, and can schedule containers locally via Docker or on Kubernetes clusters via its k3s scheduler. The codebase demonstrates high craftsmanship in its plugin architecture and state management. The `common` plugin provides a robust property store, parallel execution engine, and safe command execution utilities that are used across all plugins. The `scheduler-k3s` plugin is a standout, featuring a custom Helm diff engine for previewing infrastructure changes and complex Helm chart generation for Kubernetes resources. The `storage` and `docker-options` plugins contain well-structured parsers for their respective domain-specific languages. While the core Go code is well-structured and heavily tested (Go unit tests, BATS integration tests), the codebase has medium technical drift. The extensive use of shell scripts for plugin triggers introduces fragility, and the Kubernetes scheduler hardcodes specific versions of external tools (cert-manager, KEDA, Traefik) that require manual updates. Despite this, the project is actively maintained with frequent releases, comprehensive migration guides, and a clear deprecation policy, making it a strong example of a long-lived open-source PaaS.

Tandoor is a self-hosted, multi-tenant recipe management web application. The system is a monolithic Django application (cookbook app) exposing a Django REST Framework API, paired with a Vue 3 + Vuetify single-page frontend that consumes an auto-generated TypeScript OpenAPI client. Core production domains, verified in code, are: structured recipes (steps, ingredients, scaling), a tree-based hierarchical food database with nutritional properties and USDA FDC IDs, meal planning with iCal export, shopping lists with supermarket categories and offline sync queues, inventory/pantry booking, cookbooks, share links, and view/cook logging. Tenancy is enforced through Space/Household/UserSpace models with django-scopes middleware and granular guest/user/admin permission classes rather than through database row-level security. The largest subsystem is recipe import/export: an abstract Integration base class with 20+ adapters for other recipe managers (Paprika, Mealie, Cooklang, Gourmet, ChefTap, etc.), URL scraping via recipe-scrapers/microdata/pytubefix, cloud storage sync providers (Dropbox, Nextcloud, WebDAV, local), a bulk open-data importer for USDA-derived reference foods/units/conversions, and an embedded PDF.js viewer for external recipe files. A connector/event layer dispatches async updates to external services such as Home Assistant, a Telegram bot webhook writes shopping list entries, and recent AI features (litellm-based, per-space credit tracked) handle image/PDF recipe import, step sorting, and nutrition extraction. Background work is done via threads rather than a task queue. Craftsmanship is above average: clean abstract patterns (Integration, Provider, Connector ABCs), chainable queryset managers, mixin-based permission/merge/tree logic, a strong permission-matrix test suite, and genuinely reusable helper algorithms (BFS unit conversion, ingredient parsing, Cooklang parsing). However, the codebase carries notable debt: 240+ migrations with heavy schema churn, a ~3000-line monolithic api.py view file, committed auto-generated OpenAPI client code that can drift, vendored PDF.js binaries, some tests that suppress tenant scoping via scopes_disabled, and copy-paste duplication inside the open-data importer. Overall it is a well-maintained, actively developed application with solid architecture for its scale.

ProjectSend is a self-hosted secure file sharing platform built as a modular Laravel application with an Inertia.js + React frontend. The codebase is organized into domain modules — Files, Clients, Groups, Identity, Comments, Notifications, Audit, Platform, and Api — each containing controllers, services, policies, models, and event hooks. Staff members upload and share files with clients or groups, manage roles and permissions, enforce download limits, expire or version files, and monitor activity through a detailed audit log. Clients access their own portal with four switchable themes (default, compact, drive, gallery), and public share links support additional presentation themes with pagination, previews, and controlled downloads. The application is a monolith with strong modular boundaries rather than microservices. Authentication supports local accounts, LDAP, social login/SSO via OIDC, two-factor authentication, CAPTCHA, and password policies. A REST API protected by Sanctum tokens offers scoped abilities, RFC 7807 problem details, polling-based pagination, and an OpenAPI contract that is drift-tested against the live route surface. Background jobs handle zip downloads, email digests, thumbnails, file cleanup, and scheduled maintenance. The system persists settings, activity logs, notification preferences, and upload metadata in a relational database, while file payloads can be stored on local disks, S3-compatible storage, or Google Cloud Storage. The code is notably security-conscious: secrets are encrypted at rest, old input flashing excludes credentials, CSRF cookie naming is customized to avoid collisions, download paths are never exposed in API responses, and regression tests cover disclosure boundaries, permission scoping, token revocation, and account erasure. The test suite is extensive, using Pest feature tests to exercise permissions, file lifecycle edge cases, version chains, comment visibility, API contracts, and authentication flows. The architecture favors event-based extension points and registry patterns, making modules independently testable and partially reusable, though the project remains an application rather than a framework or library. Overall this is a well-crafted, actively maintained application with clean engineering practices, clear separation of concerns, and unusually thorough security regression coverage. Its main complexity is the large surface area of interchangeable themes, editions, authentication backends, and storage drivers, which creates some ongoing drift risk, but current CI, recent commits, and dependency management show the project is keeping pace with its ecosystem.

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.

Pelican Wings is a production-grade game server management daemon (agent) built in Go. It serves as the control plane for the Pelican Panel, managing Docker containers that run game servers. The daemon exposes a comprehensive HTTP API for server lifecycle operations (start, stop, install, backup, transfer), real-time WebSocket streams for console output and server stats, and a built-in SFTP server for file management. It communicates with a remote Panel API to synchronize server configurations, validate user credentials, and report activity logs. The codebase demonstrates strong systems engineering with a focus on security (sandboxed filesystem using openat2 syscalls, token authentication, download IP filtering), performance (disk-space caching, atomic generics), and reliability (crash detection, state persistence, cron-based backups). It supports multiple backup backends (local disk, S3), parallel server bootstrapping, and self-update via GitHub releases. The architecture follows a modular pattern with clear separation between API routing, server management, filesystem operations, and integration adapters. While the code is a fork of Pterodactyl Wings with some incomplete rebranding, it remains actively developed and production-ready.

Ganymede is a media management system focused on archiving and managing Twitch content (VODs, live streams, clips) with a Go backend using Ent ORM, Echo framework, and River job queue, and a Next.js frontend with Mantine UI. It provides video archiving, playlist management, user authentication, API keys, and administrative interfaces. The system processes media through a pipeline involving yt-dlp, FFmpeg, and TwitchDownloaderCLI, storing metadata in PostgreSQL and files on disk. It includes features like chat archiving, chapter detection, muted segment detection, and rule-based playlist automation.

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 provides Docker Compose and Kubernetes configuration files for deploying a variety of self-hosted applications and system services. It serves as a template repository for deploying services like AdGuard Home, Bitwarden, MinIO, Traefik, and others, as well as system tools like Fail2ban and acme.sh for certificate management. The architecture is modular, with each application having its own directory containing deployment configurations (docker-compose.yml, Helm charts, Kubernetes manifests). There is no single unified application; instead, it offers reusable deployment patterns for individual services. Key entry points are the docker-compose.yml or Helm chart files within each application's directory. The repository relies on external dependencies like Docker, Kubernetes, and Helm for deployment, and the applications themselves depend on their respective upstream container images.

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 is a curated list of free software network services and web applications that can be self-hosted. It is maintained by the community and contains hundreds of entries organized by category, along with links, licenses, and deployment methods. It does not contain any executable code; it is purely a documentation and reference resource. The list is actively maintained and used as a directory for discovering self-hosted alternatives to various SaaS services.