This repository provides a Docker Compose-based setup for running WordPress, designed for both local development and production environments. It orchestrates MySQL and WordPress services with optional WP-CLI access, using environment variables for configuration and named volumes for persistent storage. The production configuration includes resource limits, restart policies, and integration with reverse proxy networks (via VIRTUAL_HOST/LETSENCRYPT variables) for HTTPS support. Key components include environment-specific compose files (docker-compose.yml for production, docker-compose-local.yml for local dev), helper scripts for backup/restore/setup, and WP-CLI wrappers. The setup follows Docker best practices: separating concerns via networks, using volumes for data persistence, and leveraging environment-specific configuration. While not innovative, it implements a solid, maintainable pattern for deploying WordPress with Docker. The codebase demonstrates basic but correct usage of Docker Compose features, with clear separation between local and production configurations. Helper scripts automate common tasks like database dumps and file backups/restores using Docker exec and cp commands. There's no evidence of technical debt or outdated practices; the configuration aligns with current Docker and WordPress ecosystem standards.
This repository implements a modern Automatic Number Plate Recognition (ANPR) pipeline as a production-ready application. It ingests images (via HTTP upload or WebSocket stream), runs detection using the `fast-alpr` library (YOLO-based ONNX model), performs OCR with `fast-plate-ocr`, applies post-processing (confusion-pair correction, Turkish plate format parsing, temporal majority voting), optionally tracks vehicles via an IoU-based multi-object tracker, and stores only HMAC-SHA256 hashed plate texts for privacy compliance. The system is exposed through a FastAPI REST API with WebSocket support and a HTMX web UI, plus a Typer CLI for inference and server management. It is containerized with Docker and publishes to PyPI and GHCR. The repository also contains a legacy directory (`legacy/`) with a complete YOLOv5 training pipeline for license plate detection, but that code is explicitly unmaintained and serves as historical reference only. The modern codebase is actively maintained, well-tested, and demonstrates strong software engineering practices including protocol-based abstractions, structured logging, Prometheus metrics, and privacy-by-design persistence.
This repository contains the official Dockerfiles and automation tooling for building and publishing Amazon Corretto Docker images across multiple versions (8, 11, 17, 21, 25, 26, 27) and base operating systems (Amazon Linux 2, Amazon Linux 2023, Alpine, Debian). The codebase does not contain a running application but instead acts as a build configuration and CI/CD orchestration layer. The Dockerfiles are meticulously crafted: they verify package signatures via RPM or APT keys, install dependencies (e.g., fontconfig), clean temporary files, and set environment variables. Notable 'slim' variants use `jlink` to produce smaller runtime images by stripping debug symbols, man pages, and header files—a non-obvious optimization. The repository also includes Python scripts (`bin/apply-template.py`, `bin/tag-generator.py`) and shell scripts (`bin/update-dockerfiles.sh`, `bin/test-image.sh`) that automate Dockerfile generation, version propagation, and image validation via container-structure-test. CI/CD is implemented in GitHub Actions and validates images for every push/PR. The repository is the authoritative source for the official amazoncorretto Docker images on Docker Hub and ECR, and its primary purpose is to produce reproducible, secure JDK containers.
This is a comprehensive e-commerce backend platform built with Spring Boot 3.5+, JDK 17, and a multi-module Maven architecture. In production, it serves two distinct APIs: `mall-admin` (admin management) and `mall-portal` (customer-facing storefront), plus a dedicated `mall-search` module for Elasticsearch-powered product search. The system handles product cataloging, order lifecycle management, user registration/authentication, coupon and promotion calculations, shopping cart operations, payment integration (Alipay), and content management (home page banners, recommendations). It uses MySQL as the primary database via MyBatis (with generated mappers), Redis for caching and session management, MongoDB for user activity data (browsing history, favorites), RabbitMQ for delayed order cancellation, and MinIO/Aliyun OSS for file storage. Security is implemented with Spring Security and JWT, including dynamic path-based authorization. The codebase follows a layered architecture (Controller → Service → Mapper/DAO) with shared modules `mall-common` and `mall-security` providing reusable utilities for API responses, pagination, exception handling, Redis caching, and authentication. While heavily reliant on MyBatis Generator for data access objects and includes some long service methods, the overall structure is well-organized and modular, making it suitable as a reference for similar e-commerce projects. No data research or analytical components are present; this is purely an application codebase.
TrendRadar is a configurable news aggregation and trend analysis system that crawls hot lists from 11+ Chinese platforms (Zhihu, Weibo, Douyin, Bilibili, etc.) and RSS/Atom feeds, filters content via keyword DSL or AI-based interest matching, performs AI-powered analysis (sentiment, controversy, topic trends), generates rich HTML reports, and pushes notifications to 9+ channels (Feishu, DingTalk, Telegram, Email, ntfy, Bark, Slack, WeCom, generic webhook). It is primarily an application (with CLI entry points, scheduling via timeline.yaml, Docker/GitHub Actions deployment) but incorporates data-pipeline patterns such as multi-stage ETL (crawl → store → filter → analyze → report), SQLite storage with optional S3 remote sync, and AI batch processing. The architecture is a modular monolith: the core `trendradar` package handles all orchestration, while a separate `mcp_server` package exposes 20+ tools via Model Context Protocol (MCP) for LLM integration. The system is heavily config-driven (YAML and text files) and includes a standalone web-based config editor. External dependencies include the third-party newsnow API (for hot lists), LiteLLM (for AI model abstraction), and various notification service APIs. The codebase demonstrates good craftsmanship with clean abstractions (storage backends, notification dispatcher, AI client), though some duplication exists between the core and MCP notification logic, and the extensive configuration surface requires careful maintenance.
Firefly III is a self-hosted personal finance management application built on the Laravel PHP framework. It provides comprehensive double-entry bookkeeping with support for multiple currencies, accounts, budgets, categories, bills, piggy banks, recurring transactions, and rules. The system exposes both a full web UI using Blade templates and Alpine.js (with legacy jQuery components) and a RESTful JSON API (v1) for programmatic access. Key features include transaction splitting, budget limits, auto-budgeting, rule-based transaction processing, exchange rate management, webhook integration, multi-user with group administration, and detailed reporting with charts. The codebase follows a repository pattern with interfaces, uses events and listeners for side effects, and includes a substantial set of artisan commands for maintenance, upgrades, and data corrections.
Mythic is a cross-platform, post-exploitation, red teaming command-and-control (C2) framework. It enables operators to manage remote agents (callbacks), generate payloads, issue tasks, exfiltrate files, harvest credentials, and automate workflows through an event-driven system. The architecture is a multi-container Docker deployment: a Go backend (using Gin, RabbitMQ, PostgreSQL, gRPC) handles agent communication, task orchestration, and data persistence; a React frontend (Material-UI, Apollo Client) provides a rich operator interface with real-time updates via GraphQL subscriptions (backed by Hasura); and a CLI tool (Mythic_CLI) manages container lifecycle, configuration, and service installation. Key entry points include the agent message webhook (HTTP POST/GET), web controllers for CRUD operations, and RabbitMQ RPC handlers for internal service communication. External dependencies include RabbitMQ, PostgreSQL, Hasura GraphQL engine, Docker, and gRPC. The system is designed for extensibility through payload type containers, C2 profiles, translation containers, and custom browser scripts.
This repository implements a WeatherStar 4000+ simulator web application that recreates the nostalgic Weather Channel display from the 1990s. It fetches live weather data from NOAA's api.weather.gov, radar.weather.gov, and SPC outlook services, then renders it through a retro-styled single-page application with CRT scanlines, custom fonts, and animated icons. The architecture is a Node.js/Express server (or static nginx deployment) with a built-in caching proxy that reduces API load, plus a client-side module system for weather displays (current conditions, forecasts, radar, alerts, almanac, travel forecast, etc.). Key entry points are index.mjs (server) and server/scripts/index.mjs (client bootstrap). Data flows from NOAA APIs through the proxy to the client, augmented with precomputed city/station JSON files for location lookup. External dependencies include NOAA API endpoints, ArcGIS geocoding, and Mesonet radar tiles. The codebase demonstrates solid engineering with modular utilities, a generic settings system, and a well-structured build pipeline (Gulp, Webpack, SASS). However, it is tightly coupled to specific NOAA APIs and relies on static data files that require manual regeneration, introducing moderate technical drift risk.
This repository is a Yocto/OpenEmbedded meta-layer that builds **balenaOS**, a container-optimized embedded Linux distribution for IoT devices. It is not a runnable application but a build system consuming board support packages (BSPs), kernel patches, systemd services, and configuration recipes to produce a complete OS image with balenaEngine, balena-supervisor, OTA updates (hostapp-update), rollback, secure boot (UEFI, TPM2), disk encryption, and extensive networking (NetworkManager, ModemManager, OpenVPN, redsocks). The architecture separates common recipes (`meta-balena-common`) from Yocto-version-specific overrides (kirkstone, scarthgap, dunfell, etc.), enabling support for a wide hardware matrix (Raspberry Pi, Jetson, Intel NUC, BeagleBone, etc.). Despite being a build system, the code exhibits many software engineering best practices: modular shell libraries (os-helpers), bbclass abstractions for signing, kernel config injection, and container extension runtime. Maintenance is active with frequent version bumps, CVE backports, and CI workflows for 30+ board targets. The primary data flows are from source recipes → bitbake → OS image artifacts, with OTA updates using A/B partitions and health-check rollback. External dependencies include Yocto/Poky, various open-source components (busybox, systemd, NetworkManager, wpa_supplicant, grub, efitools, etc.), and Rust/Go cross-compilation toolchains.
TasmoAdmin is a web-based application for managing Tasmota-flashed IoT devices. It provides a responsive interface for device configuration, monitoring, firmware updates, and batch operations. The application features a modular PHP backend with dependency injection, factory patterns, and reusable helper utilities. It supports MQTT-based device discovery, automatic firmware updates via GitHub, and includes a self-update mechanism. The frontend uses Bootstrap 5 and jQuery for a modern user interface, with JavaScript modules handling dynamic interactions and state management.
This repository is a comprehensive educational course titled '.NET Web API Zero to Hero' by codewithmukesh. It contains over 50 independent ASP.NET Core Web API sample projects organized into modules covering fundamentals (minimal APIs, exception handling, logging), database management with EF Core (CRUD, migrations, interceptors, soft deletes, bulk operations, pagination), advanced API patterns (CQRS with MediatR, custom dispatcher, Result pattern, mapping benchmarks), performance and caching (in-memory, Redis, HybridCache, EF second-level cache), API security (JWT, refresh tokens, role/claims/policy/permission-based authorization, API keys, CORS, rate limiting), file handling (PDF invoice generation), architecture (Clean Architecture vs Vertical Slice), observability (health checks, structured logging), and background processing. Each sample is a self-contained, runnable project with minimal setup (often using in-memory databases) and includes extensive BenchmarkDotNet performance comparisons. The code is well-structured, follows modern .NET 10 patterns, and demonstrates production-quality implementations of cross-cutting concerns like global exception handling, validation pipelines, and caching strategies. While the repo is primarily a teaching resource, many components (custom CQRS dispatcher, Result pattern, EF Core interceptors, permission-based authorization) are genuinely reusable in other projects.
FeedCraft is a self-hosted feed processing service that transforms raw sources (RSS, Atom, HTML, JSON, search results, inbox pushes) into customized RSS feeds through composable processing pipelines called 'crafts'. The system is a monolith Go backend with a Vue 3 admin dashboard, exposing REST APIs for feed ingestion, transformation (AI-powered translation, summarization, full-text extraction, filtering), and aggregation into 'topic feeds'. The architecture follows a clean separation of concerns: source fetching/parsing, craft processing (atomic operations and flows), engine runtime, and administrative controllers. External dependencies include SQLite/PostgreSQL, Redis, an OpenAI-compatible LLM, a browserless service for dynamic content, and optional embedding APIs for semantic filtering. The codebase demonstrates solid engineering with interfaces for sources, parsers, crafts, and caching, though it carries some migration complexity from legacy craft models to newer ones.
PullPreview is a GitHub Action implemented in Go that provisions ephemeral preview environments for pull requests. It manages cloud instances (AWS Lightsail or Hetzner), installs Docker or Kubernetes (k3s), and deploys applications using Docker Compose or Helm. The action integrates deeply with GitHub PR workflows: it reacts to labels, synchronizes SSH keys from repository collaborators, updates PR comments with deployment status and preview URLs, and performs scheduled cleanup of dangling instances. The codebase is organized around a provider abstraction pattern, with concrete implementations for Lightsail and Hetzner that share common orchestration logic for instance lifecycle, SSH access, and deployment. It is a self-contained CLI binary that runs as a composite action step, bundling all dependencies into a single executable.
This repository is a container build system and runtime for NVIDIA Jetson edge AI devices. It provides a modular, composable framework for building Docker images pre-configured with AI/ML libraries (LLMs, VLMs, robotics, speech, computer vision) optimized for Jetson's ARM64 + CUDA architecture. The system includes a CLI (`jetson-containers`), dependency resolution, multi-stage Docker builds, automated testing, and CI/CD workflow generation. While primarily a build tool, it also ships hundreds of ready-to-use container definitions for popular frameworks like PyTorch, TensorFlow, vLLM, ComfyUI, ROS 2, and Home Assistant. The repository has a hybrid character: the core is an application build system, but many package definitions are research-oriented (e.g., attention kernels, diffusion models, physical AI), reflecting its dual role as both a production deployment tool and an experimentation platform for edge AI.
Photonix is a self-hosted, full-stack photo management application with AI-powered classification and search. The backend is a Django monolith exposing a GraphQL API, with background workers for importing, thumbnail generation, raw processing, and ML classification (color, objects, faces, location, style, events). The frontend is a React 19 single-page app built with TanStack Router, Apollo Client, Zustand state management, and a dark-themed shadcn/ui component library. The system supports multi-user libraries, invitations, map view, albums, and fine-grained search with facets. The architecture relies on a PostgreSQL database, Redis for task coordination and locks, and supervisor to manage numerous background processes. While the project shows solid engineering and a modern tech stack, it carries some technical debt from vendored ML models, TensorFlow 1.x compatibility, and hardcoded download URLs, and is explicitly not yet feature-complete.
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.
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.
BatMON is a Home Assistant add-on and standalone Docker application for monitoring battery management systems (BMS) over Bluetooth Low Energy (BLE) and serial connections. It decodes telemetry from ~25 BMS families (Daly, JK, ANT, Renogy, Seplos, etc.) and publishes normalized data to MQTT for Home Assistant, or directly to InfluxDB. The architecture is a Python asyncio application with a BMS abstraction layer (`bmslib`) that defines a common interface (`fetch()`, `fetch_voltages()`) and model-specific decoders. The main entry point is `main.py`, which dispatches to HA add-on or standalone mode via `entrypoint.sh`/`addon_main.sh`. Data flows from BMS hardware through BLE/serial adapters into decoder classes, then to MQTT/InfluxDB via a GUI wire format (`bmslib/wire/model.py`). External dependencies include bleak (BLE), paho-mqtt, influxdb, and Home Assistant add-on infrastructure (bashio, supervisor). The project includes a Helm chart, Docker multi-arch builds, and a test suite with known-answer vectors for CRC/AES and protocol decoders.
This is a Jenkins plugin that dynamically provisions Docker containers as ephemeral build agents. It acts as a cloud provider within Jenkins, managing the full lifecycle of containers: pulling images, creating and starting containers, connecting Jenkins agents via attach (docker exec), JNLP, or SSH, and cleaning up containers after builds. The architecture is a standard Jenkins plugin using core extension points (Cloud, Computer, Launcher, RetentionStrategy, Builder, Publisher) and deeply integrates with Pipeline (DockerNodeStep, DockerAgent). It communicates with the Docker daemon via the docker-java library, supports Unix sockets, TCP, and TLS with Jenkins credentials, and includes a management UI. The codebase is well-structured with clear separation of concerns (cloud, template, connectors, utilities) and several reusable patterns (client caching, multiplexed stream parsing, connection retries, ID generation). However, it carries significant technical debt from long-term backward compatibility, with many deprecated fields, migration code via readResolve(), suppressed SpotBugs warnings, and some thread-safety concerns. Test coverage is reasonable but some integration tests are flaky due to Docker dependency. Overall, it is a solid, actively maintained plugin suitable for production use in Jenkins-based CI/CD environments.