This is a Node.js CLI application (Docker containerized) that automatically logs into the Epic Games Store using device code authentication (OAuth2 device grant), discovers currently free games (weekly promotions and general store discounts), validates ownership via Epic's GraphQL APIs, and sends actionable checkout links to the user through a variety of notification channels (email, Discord, Telegram, Pushover, Gotify, Slack, Home Assistant, Bark, Ntfy, Apprise, webhook, and local browser open). The application uses Puppeteer with a stealth plugin to simulate a browser session for cookie management and authenticated API calls. It runs on a configurable cron schedule, with optional run-on-startup and one-shot modes. It includes a lightweight Express web server to handle device code login redirects and optionally exposes itself via localtunnel for remote accessibility. Configuration is JSON/JSON5 with full class-validator based schema validation and environment variable fallbacks.
Convox Rack is a self-hosted platform-as-a-service that runs in an AWS account and manages the full lifecycle of containerized applications. The repository is a Go monolith with three coordinated surfaces: a CLI (cmd/convox), an HTTP/WebSocket API server (cmd/rack + pkg/api), and a generated Go SDK (sdk). All operations funnel through the Provider interface defined in pkg/structs/provider.go, and the main production implementation in provider/aws drives CloudFormation, ECS, ECR, DynamoDB, S3, KMS, SSM, CloudWatch Logs, SNS/SQS, and Lambda. In production, the rack creates per-app CloudFormation stacks, builds Docker images through ECS tasks, persists builds and releases in DynamoDB/S3, and promotes releases by updating stacks. Primary entry points are cmd/convox for the CLI, cmd/rack for the API server, cmd/monitor for background workers, and the Lambda functions under provider/aws/lambda for custom CloudFormation resources, autoscaling, instance lifecycle draining, and syslog forwarding. The CLI also supports local development mode via pkg/start and pkg/sync, which builds manifests in Docker and incrementally syncs files into running containers. The manifest layer has two generations: pkg/manifest1 handles legacy docker-compose-style definitions, while pkg/manifest implements the newer convox.yml format with flexible YAML parsing, NLB validation, timers, and internal/external port handling. The codebase contains substantial test infrastructure, including golden-output CLI tests, SDK contract tests, generated mock providers, and the awsutil request/response replay harness. However, it also has accumulated drift: two parallel manifest implementations, version-gated compatibility branches in the CLI/SDK, an embedded CA trust store from 2017, AWS SDK v1 dependencies, and some provider methods that remain unimplemented. Some tests are skipped or commented out. These factors keep the code from being exemplary, but the overall architecture is coherent, professional, and actively maintained. This is purely an application repository; there is no data-science or research component. The only data involved is operational state such as builds, releases, environment variables, and logs, stored in AWS services. Reusable pieces include generic TTL caching, order-preserving YAML unmarshalling, CloudFormation stack helpers, KMS envelope encryption, and a replay-based AWS test harness.
This repository is a full-stack self-hosted media download manager and library preparation layer centered on yt-dlp. The backend is implemented in Python using aiohttp, SQLite (via SQLAlchemy), and includes a structured feature-based architecture (auth, presets, tasks, conditions, downloads, streaming, notifications, ytdlp integration). The frontend is a Nuxt 3 / Vue 3 single-page application with comprehensive i18n support. Core capabilities include automated download scheduling with cron-like task definitions, conditional filtering, Cloudflare challenge solving, real-time WebSocket updates, streaming via on-the-fly HLS transcoding with hardware acceleration fallback, and a browser extension for quick URL submission. The codebase demonstrates good engineering practices: event bus for decoupled communication, singleton-based service containers, repository pattern for data access, custom migration framework, and extensive async test coverage. Notable external dependencies are yt-dlp (core downloader), ffmpeg (transcoding), curl_cffi (impersonation), and apprise (notifications). While the architecture is modular and well-organized, there is some code duplication across CRUD repositories and migration files, and tight coupling to yt-dlp internals via custom patches. The project is actively maintained with frequent commits, a large test suite, and clear containerization support.
Nanocl is a distributed container orchestration system designed as a Kubernetes alternative, focusing on simplicity and declarative state management. The system manages workloads termed 'Cargoes' (containers), 'VMs', and 'Jobs' using Docker as the underlying runtime. It features a client-server architecture with a CLI (`nanocl`), a central daemon (`nanocld`), and auxiliary sidecar services for proxying (`ncproxy`) and DNS (`ncdns`). The architecture relies on Rust for performance and safety, utilizing `ntex` for async HTTP handling and `diesel` for database persistence. The core operational model is driven by declarative Statefiles (YAML/TOML/JSON) processed with Liquid templating. These files define the desired infrastructure state, which the daemon reconciles against the actual runtime state. The system integrates directly with the Docker daemon via the `bollard` library to manage container lifecycles, networking, and images. It features a robust event-driven architecture where state changes trigger sidecar updates, such as Nginx configuration regeneration for routing. The codebase demonstrates a modular design with shared crates for error handling, stubs, and utilities. It implements a generic repository pattern for database access and abstract lifecycle traits for resource management. The API is versioned and documented via OpenAPI/Swagger, supporting RESTful CRUD operations and real-time event streaming. While the project shows strong architectural patterns, it carries medium technical drift due to API versioning fragmentation and heavy dependency on Docker API behavior.
VoucherVault is a self-hosted Django web application for digitally managing vouchers, gift cards, coupons, and loyalty cards. It provides a full CRUD interface with features like barcode/QR code scanning, expiry notifications via Apprise, multi-currency support via Fixer.io, offline-first capabilities (service worker + IndexedDB sync), OIDC authentication, item sharing between users, and a PWA manifest for mobile installation. The architecture is a monolithic Django app with Celery for background tasks (expiry checks), Redis as a message broker, and optional PostgreSQL or SQLite databases. The frontend uses the NiceAdmin Bootstrap template with custom dark mode and charting via ECharts. The codebase is well-organized with clear separation of concerns (models, views, forms, templates, static assets) and includes internationalization for English, German, French, and Italian. While the application is feature-rich and actively maintained, it lacks automated tests and has some code duplication in templates, which limits its quality score.
This repository is a Bash-based server provisioning tool that converts a bare Debian 13 (Trixie) VPS into a dedicated Nextcloud High-Performance Backend (HPB) server. It installs and wires together the full Talk/HPB stack: nextcloud-spreed-signaling (built from source or from Debian packages), NATS message bus, coturn TURN/STUN server, Janus WebRTC gateway, and Collabora Online (CODE) for document editing, all fronted by an Nginx reverse proxy with Let's Encrypt certificates (separate RSA and ECDSA chains), UFW firewall, unattended-upgrades, and msmtp for email notifications. The output is a secrets file containing the Talk app credentials, TURN credentials, and per-Nextcloud-domain shared secrets that an administrator pastes into the Nextcloud Talk/Office settings. It supports multiple Nextcloud domains and can run fully unattended via a settings.sh file or interactively through whiptail dialogs. Architecturally it is a monolithic orchestrator (setup-nextcloud-hpb.sh) that loads settings, renders placeholder-based config templates from data/ into a temporary directory, then sources modular install_* functions from src/setup-{ufw,collabora,signaling,nginx,certbot,unattendedupgrades,msmtp}.sh. The configuration files under data/ are upstream service configs (Janus, coturn, signaling-server, nginx, coolwsd) with <PLACEHOLDER> tokens substituted via sed/perl. The design shows real operational craftsmanship: a dry-run mode is threaded through every step, deploy_file() uses SHA-256 checksums to make deployments idempotent, external IP detection has fallback endpoints, and secrets are written to a 0640 file while being masked in logs. The most reusable components are isolated shell patterns rather than whole modules: the checksum-based deploy_file() and perl-based replace_placeholder_in_files() functions in the main script (placeholder substitution that survives arbitrary password characters), the Certbot rate-limit/staging-certificate handling in src/setup-certbot.sh, and the version-marker + .deb cache build system for Janus in src/setup-signaling.sh. These patterns can be lifted into other provisioning projects. Caveats: the code has no tests, relies heavily on global variables shared across sourced modules, and contains a few real defects — the dry-run dialog always sets DRY_RUN=true when the setting is left empty, and the SSH-disable check compares the literal string 'DISABLE_SSH_SERVER' instead of the variable, so that feature never activates. Several commented-out legacy blocks remain. Despite this, the project is actively maintained (release 1.3.6, July 2026) and targets the current Debian release.
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.
Bark is a native iOS application that turns APNs push notifications into a self-hostable, customizable notification delivery system. It is not a data or research project; it is a polished consumer iOS app with a companion widget, notification service extension, and App Intents. In production, the app maintains a device registration key per user, listens for remote notifications via Apple Push Notification service, and enriches incoming payloads through a chain of processors in the Notification Service Extension: decrypting AES-encrypted bodies (CBC/ECB/GCM with CryptoSwift), rendering Markdown, setting badges, auto-copying text, archiving to Realm, muting groups, triggering call interruptions, and attaching images/icons. The main app provides a history list with group/section rendering, server management (defaults to api.day.app but supports custom self-hosted servers), QR-code server import, encryption settings, archive retention controls, sound selection, and a modern home screen demonstrating usage via curl-like examples. A WidgetKit timeline widget shows recent messages from a shared JSON snapshot, and Siri/Shortcuts intents can trigger pushes to the current or another device. The architecture follows a reactive MVVM pattern using RxSwift/RxCocoa throughout, with Realm as the local persistence layer shared across app and extensions via an App Group container. The project targets iOS 15+ with five Xcode targets (main app, notification service extension, notification content extension, widget, tests) and is distributed via the App Store and TestFlight through fastlane and GitHub Actions.
Colanode is a local-first collaboration workspace platform designed for self-hosting. It provides real-time editing of rich-text documents, customizable databases (table, board, calendar views), threaded chats, file management, and user roles. The architecture is a monorepo with separate packages for core types, client-side local persistence and sync, CRDT conflict resolution, and a shared UI library. The server runs on Fastify with PostgreSQL and Redis, exposing REST APIs and WebSocket connections for real-time synchronization. All data mutations are first applied locally in SQLite (via Kysely) and then synced to the server, enabling offline-first operation. Clients include a web application (React, Vite, service worker), a desktop app (Electron), and an experimental mobile app (Expo). The editor is built on TipTap/ProseMirror with custom extensions for blocks, mentions, files, and database nodes. External dependencies include PostgreSQL (with pgvector extension for optional vector search), Redis (for rate limiting and job queues), object storage (local filesystem, S3, GCS, or Azure), and optional AI/LLM providers for semantic search and assistant features. Many AI features are commented out or in development, indicating an incomplete experimental layer. The codebase is actively maintained with CI/CD pipelines, Docker images, Helm charts, and automated tests for critical server and web components.
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.
Memospot is a desktop application that bundles the Memos note-taking service as a self-contained Tauri v2 wrapper. It manages the Memos server as a sidecar process, provides a SvelteKit frontend for settings and interaction, and handles configuration persistence, database migrations, window state, keyboard shortcuts, and auto-updates. The architecture is a Rust backend with a web frontend, using a Rust workspace with multiple crates for config, dialogs, sidecar management, port picking, and homedir resolution. The frontend is built with SvelteKit, Tailwind CSS, and uses Paraglide for i18n. The build system includes GitHub Actions CI/CD, Docker-based builds, and installers for Windows (NSIS/WiX), Linux (deb, AppImage, Flatpak), and macOS. The codebase demonstrates solid engineering practices with clean abstractions and reusable utility crates, though it has some pinned dependencies and complex CI workflows.
This repository is a Home Assistant add-on distribution point for Music Assistant, not a standalone application. It packages the Music Assistant server and a companion local audio output add-on as installable Home Assistant add-ons. The repository contains multiple variants—stable, beta, dev, and nightly—each with its own Dockerfile, run script, configuration schema, translations, and changelog. The local_audio add-on provides low-latency playback to local sound cards and is hardened with a custom AppArmor profile. In production, the add-ons run inside Home Assistant OS or a supervised installation. The main entry points are the add-on config.yaml files and the shell scripts that start the Music Assistant server or local audio player. The server exposes a web UI and integrates with Home Assistant; audio flows from music providers to players, with local_audio acting as an output sink. External dependencies include Home Assistant, Docker, the Music Assistant Python server, and system audio libraries. The codebase is primarily operational glue: shell scripts, Dockerfiles, YAML configuration, and security profiles. The most reusable artifacts are the AppArmor profile for sandboxing a network-exposed audio player and the git-ref-based source installer used by the development add-on. The repository is actively maintained, with frequent releases and detailed changelogs, and shows low technical drift relative to current Home Assistant add-on practices.
Apollo is a self-hosted game streaming server, forked from Sunshine and rebranded for compatibility with Artemis (formerly Moonlight Noir) clients. In production, it captures the host's display (via DXGI, KMS, Wayland, or NvFBC), encodes video using hardware encoders (NVENC, AMD AMF, Intel QSV, VAAPI, VideoToolbox) and audio (Opus), then streams over the network using a combination of RTSP for session control and ENet for real-time transport. It also forwards keyboard, mouse, gamepad, and pen input back to the host, enabling low-latency remote gaming or desktop control. The architecture is a single-process C++ application with a multi-threaded design: separate threads for video capture, encoding, audio capture, network I/O, and control. It exposes a web-based configuration UI (Vue.js frontend served by an embedded HTTPS server) and implements the NVIDIA GameStream HTTPS API for client pairing and session management. Platform-specific code is isolated behind abstraction interfaces (e.g., platf::display_t, platf::input_t), with dedicated implementations for Windows, Linux, and macOS. External dependencies include Boost, FFmpeg, OpenSSL, ENet, and vendor-specific SDKs (NVENC, AMF, VAAPI, etc.). The codebase demonstrates solid engineering with a clear separation of concerns, a comprehensive build system (CMake with platform macros), and a growing test suite (Google Test). However, it carries technical debt from its forked nature—some code still references 'Sunshine' while branding leans toward 'Apollo'—and there are incomplete features on macOS (e.g., placeholder functions for clipboard) and fragile workarounds for driver bugs. Overall, it is a functional, well-maintained application with reusable patterns for inter-thread communication, resource management, and platform abstraction.
PaoPao-ce is a full-stack micro-community social media platform written in Go (backend) and Vue 3 (frontend). It provides a feature-rich experience similar to Twitter/Weibo, including posts (tweets) with multimedia attachments, comments, likes, collections, private messaging, user profiles, topic/tag support, and a wallet system with Alipay integration. The architecture is modular and configurable, supporting multiple databases (MySQL, PostgreSQL, SQLite), search engines (Meilisearch, Zinc), object storage backends (LocalOSS, MinIO, AliOSS, COS, Huawei OBS, S3), caching layers (Redis, BigCache), and observability tools (OpenTelemetry, Sentry, Pyroscope, pprof). The backend uses Gin for HTTP, GORM for ORM, go-mir for API code generation, and protobuf for gRPC services. The frontend is built with Vue 3, Naive UI, Vite, and Pinia. Key features include feature toggles for different deployment suites, a runtime settings override via admin UI, and background job processing for search indexing and metrics. The platform emphasizes self-hosting and customization, with comprehensive SQL migration scripts and support for desktop clients via Tauri. The codebase demonstrates solid engineering practices with interface-based dependency injection, layered architecture, and code generation, though it carries some technical debt from deprecated backends and WIP features.
This repository provides a comprehensive Docker Compose configuration for building a self-hosted NAS (Network Attached Storage) system. It orchestrates over 20 services including media management (Sonarr, Radarr, Lidarr, Bazarr, Prowlarr, qBittorrent, Jellyfin, Jellyseer), a WireGuard VPN (PIA), reverse proxy (Traefik with Let's Encrypt), a homepage dashboard (Homepage), automatic updates (Watchtower), and optional services like AdGuard Home, Home Assistant, Immich, Vaultwarden, Paperless, and more. The architecture is a multi-container Docker stack with a shared network, designed to run on any Docker-capable Linux box. The primary data flow involves downloading media via qBittorrent through a VPN, managing it with *arr applications, and serving it via Jellyfin. The repository includes automation scripts for initial configuration (update-config.sh) and port forwarding updates (pia-shared/portupdate-qbittorrent.sh). It is not a software application with custom code but rather a well-documented, opinionated deployment template. The codebase is primarily configuration files (docker-compose.yml, environment files, nginx configs) with a few bash and JavaScript scripts. The quality is good for its purpose: it is organized, documented, and widely used, but it lacks reusable software components that could be extracted into a new project with minimal modification.
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.
This repository is the deployment system for Internet-in-a-Box (IIAB): an offline-first learning server for schools and communities without reliable Internet. It is an Ansible configuration-management application that installs and configures a complete local network stack — nginx reverse proxy, PHP-FPM, MySQL/PostgreSQL, hostapd WiFi access point, dnsmasq DNS/DHCP, Squid proxy, captive portal, Samba, CUPS — alongside a catalog of educational services such as Kiwix (offline Wikipedia/ZIM), Kolibri, WordPress, MediaWiki, Nextcloud, Gitea, JupyterHub, Moodle, Calibre-Web, and an offline OpenStreetMap/vector-tile mapping system with geocoding. Python, PHP, and Jinja2 templates generate systemd units, nginx virtual hosts, and app configs for every deployed service. Architecture is a staged Ansible pipeline: eleven role groups (0-init through 9-local-addons, then network) are driven from top-level playbooks (iiab-stages.yml, iiab-from-cmdline.yml) invoked by shell entry points (iiab-install, iiab-configure, iiab-network). Every role follows consistent conventions: defaults in defaults/main.yml, an install.yml and enable-or-disable.yml, boolean *_install/*_enabled flags validated up front with Ansible assert tasks, install state recorded in /etc/iiab/iiab_state.yml, and disk usage audited into iiab.ini. A custom Ansible module (get_curl) performs resumable/atomic downloads used across roles. Content provisioning is data-driven: maps and ZIM catalogs are generated (roles/maps/generate-catalog.py) and fetched at install time; offline search and geometry utilities (FQR, static_search.js) are bundled into the served front end. The project is actively developed (Ubuntu 24.04 and Raspberry Pi OS CI matrices, expected-state integration tests) but carries heavy legacy baggage: a large 0-DEPRECATED-ROLES tree, numerous .unused files, Python 2 support scripts, hardcoded versions/vendor URLs, plaintext default secrets, and fragile per-distro workarounds. The reusable gems — the custom download module, the tested geographic FQR geometry utility, the client-side static geocoder, the Ansible facts script, and the pdsm proot service manager — are isolated enough to extract into new projects. Overall it is a solid, professional infrastructure-as-code project with a few genuinely reusable components, tempered by significant accumulated technical debt.
This is a self-hosted social timeline application (moments/朋友圈) that allows users to post short updates (memos) with rich media: images, videos, music, links, and Douban (Chinese media database) book/movie references. The architecture is a single Go binary that embeds a Nuxt.js static frontend and connects to a SQLite database. The backend provides a REST API with JWT authentication, supports file upload (local or S3), comment system with email notifications, RSS feed generation, and database backup on version changes. Noteworthy features include automatic database backup with cleanup, image thumbnail generation, Google reCAPTCHA integration, and a calendar-based search for memos. The codebase is well-organized with dependency injection (samber/do), proper route grouping, and data migration scripts. The frontend is a Nuxt 3 SPA with Tailwind CSS and component-based UI. The project is actively maintained with frequent commits and a responsive issue tracker.
This repository provides a fully automated, one-command deployment of a self-hosted Supabase stack. The setup script (`setup.sh`) orchestrates the entire process: it installs dependencies, clones the repository, generates cryptographic secrets and JWT tokens, configures environment variables, and layers optional docker-compose overrides for Authelia 2FA, Nginx or Caddy reverse proxy, and SSL via Let's Encrypt. The architecture is a Docker Compose multi-service deployment including Supabase Studio, Kong API gateway, GoTrue auth, PostgREST, Realtime, Storage, Edge Functions, and a custom Postgres image. The code is production-grade with robust error handling, CI/CD pipelines (GitHub Actions) that test every configuration matrix (caddy/nginx, basic auth/authelia/redis), and comprehensive integration tests covering CRUD operations, storage, realtime subscriptions, and edge functions. The repository also includes advanced utilities for key management (asymmetric JWTs, opaque API keys) and a sophisticated Postgres 15-to-17 upgrade script (`upgrade-pg17.sh`) that handles binary extraction, pg_upgrade, and post-migration patches. While primarily a deployment tool, the scripts demonstrate high craftsmanship and are safely reusable as templates for similar self-hosting scenarios.
This repository provides the official Helm charts for deploying Mattermost, an open-source messaging platform, and its associated services (Focalboard, RTCD, Push Proxy, Calls Offloader) onto Kubernetes. The primary deployment method is the `mattermost-operator` chart, which uses Kubernetes Custom Resource Definitions (CRDs) to declaratively manage the full lifecycle of Mattermost installations, including databases, file stores, ingresses, and scaling. Legacy charts (`mattermost-enterprise-edition`, `mattermost-team-edition`) are included but deprecated in favor of the operator. The architecture is a collection of Helm charts, with the operator chart acting as the core. It relies on external dependencies like PostgreSQL, S3-compatible storage, and optionally Elasticsearch and Grafana. The repository demonstrates strong DevOps practices, including automated CI/CD for chart releases, end-to-end testing with kind, and embedded monitoring configuration. Key reusable patterns include a Helm-embedded Grafana dashboard template for application KPIs, an ExternalSecrets integration for secure credential management, a deprecation handling template for managing breaking changes, and advanced Kubernetes storage patterns (EFS, NFS). The codebase is actively maintained but carries some technical drift from legacy components and outdated Kubernetes API versions.