Samarium is a modular, all-in-one business management system (ERP/CMS) built with Laravel 11 and Livewire 3. It provides a comprehensive admin dashboard for small to medium businesses, covering sales invoicing, purchase orders, expense tracking, inventory management, accounting (double-entry ledger, trial balance, income statement), customer/vendor relationship management, and a full content management system (webpages, posts, galleries, navigation menus, themes). It also includes e-commerce capabilities (product catalog, shopping cart, online orders), appointment booking, team management, calendar with Nepali date support, and additional modules like vacancies, testimonials, newsletters, and document/URL link management. The system is configurable via a module toggle in config/app.php and supports both a dashboard interface and a public-facing website. The architecture follows a standard Laravel MVC pattern with Livewire components handling all interactive UI. Each business domain has its own set of Livewire components (e.g., SaleInvoiceEditor, ProductDisplay) that use a shared ModesTrait for state management. A service layer provides pagination and CRUD logic, though many service methods are incomplete. The frontend uses Bootstrap 4, Font Awesome, and Chart.js for reporting. The system is Dockerized for easy deployment and includes seeders for demo data. While the codebase is functional and covers a wide feature set, it exhibits several quality issues: mixed namespaces (some models under App\, others under App\Models\), hardcoded values (VAT 13%, Nepali month arrays), incomplete features (many TODO comments, empty service methods), and code duplication (multiple similar Livewire components for editing fields). The Nepali calendar support is a distinctive feature but requires manual maintenance of hardcoded date ranges. Overall, Samarium is a solid, feature-rich ERP for its target audience but would benefit from refactoring and stricter coding standards.
This repository serves as a comprehensive guide and utility for managing Visual Studio Code extensions. It provides a curated list of extensions categorized by functionality (themes, productivity, data science, etc.) with descriptions and screenshots. The repository includes a PowerShell script for bulk installing extensions and a set of tools (Python and Bash) for comparing extension lists between different environments. Additionally, it contains a standalone decision tree implementation in Python, which, while not directly related to the main purpose, demonstrates solid algorithmic implementation. The main value lies in the extension recommendations and the practical scripts for managing VS Code setups, making it a useful reference for developers seeking to enhance their coding environment.
This repository implements a personal link-in-bio web application (moure.dev) built with Reflex, a Python web framework that compiles to a React frontend with a FastAPI backend. The application serves as a central hub for Brais Moure's social media profiles, programming courses, newsletter subscription, and sponsor showcases. It features two main pages: an index page with social links and a courses page listing educational resources. The architecture follows a modular pattern with separate components for UI elements (buttons, icons, headers, footers), a state management class for asynchronous data fetching, and a FastAPI sub-app that exposes REST endpoints for live Twitch status, featured content from Supabase, and event schedules from ConfigCat feature flags. The frontend is rendered using Radix UI primitives and includes client-side theming, analytics tracking (Google Analytics, Facebook Pixel), and a newsletter integration via Beehiiv. The codebase is primarily educational, accompanying a 13-hour video course on web development with Python. It demonstrates how to build a full-stack application using Reflex, integrate external APIs (Twitch, Supabase, ConfigCat), manage application state, and deploy via Docker or static export. The project includes CI/CD via GitHub Actions for automated static builds. While the application is functional and well-structured for its scope, it lacks automated tests and contains some commented-out code. The generated frontend assets are tightly coupled to specific Reflex and React versions, posing potential maintenance challenges during upgrades. External dependencies on Twitch, Supabase, and ConfigCat require valid credentials via environment variables, limiting out-of-the-box reproducibility.
This repository provides a GitHub Action to run Composer commands within a Docker container. It wraps the Composer CLI, allowing users to specify a command (default `install`), PHP version, Composer version, and various flags like `--no-dev`, `--no-progress`, and `--no-interaction`. The action downloads the appropriate Composer PHAR from getcomposer.org, sets up SSH keys for private repositories if provided, and executes the command inside a Docker container based on the php-actions/php-build image. The workspace is mounted at `/app`. The implementation is a single composite action with a bash script that handles argument parsing, SSH key setup, and Docker execution. It is a straightforward, well-documented action that solves the common problem of running Composer in CI pipelines. No reusable components beyond the action itself exist; the bash script is tightly coupled to GitHub Actions and Docker.
LiteOps is a lightweight, self-hosted CI/CD platform built with Django 4.2 (Python 3.9) and Vue 3 (Ant Design Vue). It provides project management, build task configuration, credential storage (GitLab tokens, SSH keys, kubeconfig), environment management, and notification robots (DingTalk, WeChat, Feishu). Builds are executed inside a Docker-in-Docker container that includes Java, Maven, Node, and kubectl, with real-time log streaming via Server-Sent Events (SSE). The system integrates with GitLab for webhook-triggered builds and branch/commit information, supports LDAP authentication, and enforces role-based permissions (function and data scopes). The frontend dashboard displays build statistics, trends, and recent builds using ECharts. The codebase is functional and actively developed, but exhibits several engineering weaknesses: no automated tests, threading for async build execution (no task queue), hardcoded secrets (admin password, database credentials), SHA256 password hashing (not bcrypt), and plaintext storage of GitLab tokens. The Docker image is large and requires privileged mode. Despite these issues, the system is suitable for small teams needing a simple, integrated CI/CD solution without external dependencies beyond GitLab and MySQL.
Phuzz is a research-oriented web application fuzzing framework that orchestrates multiple fuzzers (Burp Suite, Wapiti, WFuzz, ZAP) alongside its own custom fuzzer to detect vulnerabilities in web applications. The repository includes a custom Python-based fuzzer with mutation and scoring modules, a crawler for discovering endpoints, a HAR generator for request capture, and Docker-based orchestration for running fuzzers against vulnerable test applications (bWAPP, DVWA, WackoPicko, XVWA, WordPress plugins). It also contains extensive experimental data and analysis scripts from studies on known and zero-day vulnerabilities, particularly targeting WordPress plugins. The architecture is modular, with separate components for crawling, fuzzing, and result analysis, all containerized via Docker Compose. While primarily a research tool, the core fuzzer and instrumentation components are well-structured and could be extracted for reuse in other security testing pipelines.
This repository is an educational Docker tutorial centered on a functional Django REST API application. The core implementation uses Docker Compose to orchestrate two services: a Django web container (DRF) and a PostgreSQL container, with explicit health checks, JSON-file logging limitations, named volumes, and user-defined networks. The Django API itself is a basic music CRUD service with endpoints under /api/musics, secured behind authentication, and housed in a straightforward project structure that demonstrates the typical pattern of a containerized Python microservice. Beyond the main tutorial, the repo provides stand-alone Docker Compose examples covering advanced patterns: YAML anchors to reduce configuration repetition, docker-compose override to batch operate multiple databases, environment variable substitution with .env files, profiles for selective service boot, and cAdvisor for container resource monitoring. Each subfolder includes a README and ready-to-run configuration, making the entire repository a one-stop teaching resource for Docker Compose patterns and best practices. The code is not intended as a production tool but rather as a self-contained, reproducible learning blueprint that shows how to build and manage containerized stacks with modern features. While the application layer is deliberately simple, the Docker-compose layer embodies several good practices around health and logging, and the advanced usage of YAML anchors and overrides exemplifies high-quality configuration craftsmanship that is directly reusable in other projects.
This repository provides deployment tooling for frpc, the client component of the frp reverse proxy project (fatedier/frp). It does not contain any original application code; rather, it packages the official frpc binary into installation scripts for Linux servers and Synology NAS, along with a Docker image. The supported deployment methods include a systemd-managed service (Linux), a nohup background process (Synology), and a Docker container with multi-architecture support (amd64, arm64, arm). The core user experience is to download and execute a script, which automatically fetches the frpc binary from GitHub, installs it under /usr/local/frp, generates a default frpc.toml configuration, and sets up automatic startup. The Dockerfile builds a minimal Alpine image containing the frpc binary and expects a mounted configuration file. The repository is a practical convenience wrapper around the upstream frpc project. Its main value is simplifying installation across different environments and providing a CI/CD pipeline to build and publish multi-arch Docker images. The scripts include basic safeguards such as checking for existing installations, killing any running frpc processes, and detecting platform architecture. However, the code quality is average: the scripts are functional but lack robust error handling, use the deprecated md5sum, and pin an outdated Alpine base image (3.8). The repository is maintained but shows some technical drift, particularly in the old base image and reliance on deprecated commands. There are no highly reusable, isolated software components that demonstrate exceptional craftsmanship beyond the straightforward installation pattern. The repository fulfills its purpose for users who need a quick, largely hands-off setup of frpc, but it does not offer novel architectural insights or independently extractable modules for other projects.
Stb (图床) is a full-stack image hosting service built as a pnpm monorepo. The backend is a Node.js/Express application with MongoDB (Mongoose) providing REST APIs for user authentication, image upload, album management, admin operations, and system configuration. The frontend is a Vue 3 single-page application using Pinia for state management, Vue Router with lazy-loaded views, and a mix of Ant Design Vue and Element Plus UI libraries. The system supports multiple storage backends (local filesystem, S3-compatible, Alibaba OSS, Tencent COS, Qiniu, Upyun, SFTP, FTP, WebDAV, Telegram, GitHub) via a pluggable adapter pattern, and integrates AI-based content moderation (Tencent, Aliyun, NSFWJS). Deployment is Docker-based with a multi-stage build and GitHub Actions CI/CD for multi-architecture images. The application includes a comprehensive admin panel for user, image, log, album, role group, invite code, and configuration management, as well as OAuth login (GitHub, Google, Linux DO), email verification, and a slider captcha component. While the codebase is functional and well-structured with clear separation of concerns, it exhibits some technical debt: mixed UI libraries increase bundle size, the configuration view is monolithic and exposes sensitive credentials to the client, there are no automated tests, and some patterns (e.g., IP detection, Docker entrypoint sed) are fragile. Overall, it is a solid, production-ready image hosting solution with reusable utility modules.
This is a large, scaffolded e-commerce backend system built with the go-zero microservice framework. It implements a full suite of admin and frontend APIs for managing products, orders, members, coupons, content, and system settings. The architecture is microservices-based with separate RPC services for each domain (sys, cms, oms, pms, sms, ums) plus search, consumer, and job services. The codebase is heavily generated using goctl and gorm.io/gen, resulting in a high volume of boilerplate CRUD logic files—many of which are still stubs containing only 'todo: add your logic here' comments. While the system demonstrates a consistent pattern for service decomposition and provides reusable utility packages (pkg/errorx, pkg/time_util, pkg/mq), the majority of business logic is incomplete, and there are signs of technical drift such as duplicate JWT library usage, mixed ORM approaches, and hardcoded configuration values. The project is actively maintained but still in a work-in-progress state, with the README warning of significant backend changes and incomplete frontend adaptation.
This repository is a build configuration for the Home Assistant Docker base image. It contains a multi-stage Dockerfile that installs various system dependencies (bluez, ffmpeg, nmap, etc.), builds and integrates third-party libraries (ssocr, libcec, PicoTTS, Telldus) via builder stages, installs Python wheels from a requirements.txt, and copies a root filesystem overlay. The CI/CD pipelines (builder.yml, hadolint, shellcheck, release drafter) automate building multi-arch images for amd64 and aarch64, and publishing on releases. The repository itself does not contain any application code, CLI entry points, or service logic; it purely defines how to assemble the container environment used by Home Assistant Core. Its architecture is a set of build scripts and Dockerfile instructions. Key entry points are the Dockerfile and the builder workflow. External dependencies include Alpine Linux packages, Python packages (Brotli, mysqlclient, psycopg2), and upstream project patches.
This repository provides a Dockerized setup for running a V2ray server with nginx as a reverse proxy, supporting VMess and VLess protocols over WebSocket. The configuration uses environment variables for easy customization of the UUID and WebSocket paths. The system is designed for deployment on platforms like Doprax.com or uffizzi.com, where TLS termination is handled by the platform. The application consists of a Dockerfile that installs nginx, supervisord, and v2ray, an entrypoint script that substitutes environment variables into configuration files, and configuration files for nginx and v2ray. Supervisord is used to manage the nginx and v2ray processes. The repository appears to be stale in terms of updates, with the v2ray core dependency being outdated.
CDK (Container Docker/Kubernetes Exploitation Toolkit) is a Go-based CLI penetration testing tool designed for container and Kubernetes environments. It evaluates security posture by running extensive checks against container runtime configurations, K8s API permissions, cloud metadata, and kernel exploit possibilities. It then executes a plethora of exploits covering container escape (cgroups, mount, eBPF, runc/containerd CVEs), K8s credential access (secrets, configmaps, tokens), persistence (backdoor daemonsets, cronjobs, shadow API server), privilege escalation (service account token theft, CVE-2026-31431), and remote control (reverse shells, kubelet exec). The binary bundles stripped-down versions of common tools (kubectl, netcat, vi, etc.) for post-exploitation use. The architecture follows a plugin pattern where exploits register themselves via init(), and evaluation uses a category-based check system. The codebase shows signs of organic growth with some legacy cruft (deprecated auto-escape task, commented-out code, future-dated CVEs) and moderate technical debt (global mutable state, panics, outdated Go idioms), but remains functional and actively maintained for penetration testers and security researchers.
This repository contains the Debian packaging and installer scripts for Home Assistant Supervised, an advanced installation method that runs the full Home Assistant Supervisor stack on a standard Debian operating system using Docker. The package configures system services (NetworkManager, systemd-resolved, AppArmor, Docker), downloads and runs the Supervisor container, and sets up the necessary systemd units and configuration files. The installer is a set of Debian maintainer scripts (preinst, postinst, postrm) that orchestrate the setup, including network checks, Docker image pulls, and system hardening. The project is explicitly deprecated as of Home Assistant OS 2025.12.0 and is no longer supported, though the code remains functional for legacy installations. It is a straightforward, well-structured installer with no reusable software components beyond its specific deployment purpose.
This repository provides deployment configurations and scripts for self-hosting the UI Bakery low-code platform. It contains Docker Compose files for local, Azure, and external database setups, Kubernetes manifests for orchestration, and shell scripts for installation, setup, and updates. The repository does not include the application source code but rather orchestrates pre-built Docker images of UI Bakery's services (gateway, frontend, backend, etc.). The installation script guides users through environment configuration, secret generation, and service startup via Docker Compose. While functional and demonstrating good practices in input validation and cryptographic secret generation, the update script contains a bug in the external database handling section, and the scripts lack modularity, limiting reusability beyond this specific deployment context.
Estela is an open-source web scraping orchestration platform (analogous to Scrapy Cloud) for deploying, scheduling, and monitoring Scrapy-based spider projects on Kubernetes. It consists of a Django REST API backend with Celery for async task management, a React/TypeScript frontend with Ant Design, and a Kafka-based queue consumer for streaming scraped data into MongoDB. Core workflows include project management, spider deployment (Docker image build via Kaniko), job execution with configurable resource tiers, cron scheduling, data persistence settings, and a metering subsystem for usage tracking. The system relies on external dependencies such as Kubernetes, Kafka, MySQL, MongoDB, Redis, and object storage (MinIO/S3). The frontend provides interactive charts, a tour overlay for onboarding, and notification management. While functional and extensible, the codebase shows signs of age (outdated Django/Celery versions, class-heavy React components, duplicate logic in cron expression handling) and has incomplete test coverage.
Stan's Robot Shop is a polyglot microservice application designed as a sandbox for learning container orchestration and monitoring. The system comprises eight services (user, catalogue, cart, payment, shipping, ratings, dispatch, web) each built with a different technology stack (Node.js, Java, Python, Go, PHP) and communicating via HTTP or RabbitMQ. Data is persisted in MongoDB (catalogue, user), Redis (cart, session), and MySQL (shipping, ratings). The application provides Docker Compose and Kubernetes manifests for deployment, along with Instana integration for automatic tracing and metrics collection. While the application successfully demonstrates microservice patterns and technology diversity, the codebase exhibits significant technical drift due to outdated dependencies (e.g., Express 4.15, Redis 2.8, Spring Boot 2.3) and lacks modern practices such as comprehensive error handling and security measures. The architecture is modular and service boundaries are clear, but the implementation relies on boilerplate for tracing and health checks. A notable reusable component is the Haversine distance calculator in the shipping service, which is isolated and dependency-free.
This is a large, sprawling collection of tutorial and demo projects authored by a single developer (blogger '程序员欣宸'). It covers dozens of technologies including Spring Boot internals, Flink, Kafka, gRPC, JavaCV/OpenCV, Kubernetes controllers, LangChain4j, JUnit 5, and more. Each subdirectory is an independent, self-contained demo typically with a single main class or test. The code is educational: full of Chinese comments, simplified logic, and hardcoded paths. While not a cohesive application, it serves as a rich reference for learning how to use specific frameworks and patterns. The quality is average overall—functional but boilerplate-heavy, with many outdated dependencies and duplicated code across projects.
This repository is a companion to the Korean book '컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커' (Kubernetes/Docker for Container Infrastructure). It provides a collection of Vagrant-based lab environments, shell provisioning scripts, Kubernetes YAML manifests, Helm charts, and CI/CD examples (Jenkins) to help readers build and manage Kubernetes clusters on VirtualBox. The codebase includes single-master and multi-master (via Kubespray) cluster setups, along with demonstrations of core Kubernetes concepts (Pods, Services, Ingress, Storage, Monitoring). While the repository is actively maintained with yearly architecture documents, the actual scripts and configurations rely on outdated software versions (e.g., Kubernetes 1.18, Docker 18.06, CentOS 7) and external URLs that may become stale. The code is functional for educational purposes but is boilerplate-heavy and repetitive across chapters, limiting its reusability in production environments.
This repository is a large collection of ~41 independent DevOps learning projects, each demonstrating a specific technology stack or pipeline (e.g., CI/CD with Jenkins, infrastructure as code with Terraform, containerization with Docker, orchestration with Kubernetes on AWS/Azure). It is not a single application but a portfolio of deployable demo applications (Java Spring PetClinic, Netflix clone, Swiggy clone, Chatbot UI, etc.) coupled with infrastructure code and step-by-step tutorials. The code quality varies widely across projects; many are boilerplate or copied from other tutorials, but a few components exhibit good craftsmanship, such as the OneToManyResultSetExtractor in PetClinic and the import/export utility in Chatbot UI. The repository serves as a learning resource rather than a production system, and its primary value lies in the breadth of DevOps tooling coverage rather than in reusable software components.