PHPackages texxasrulez/server-dashboard - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. texxasrulez/server-dashboard ActiveProject[Utility & Helpers](/categories/utility) texxasrulez/server-dashboard ============================ Minimal PHP test scaffolding for Server Dashboard 2.0.0(2w ago)00GPL-3.0-or-laterPHPPHP >=8.0 Since May 26Pushed 2w agoCompare [ Source](https://github.com/texxasrulez/server-dashboard)[ Packagist](https://packagist.org/packages/texxasrulez/server-dashboard)[ RSS](/packages/texxasrulez-server-dashboard/feed)WikiDiscussions main Synced 1w ago READMEChangelog (1)Dependencies (2)Versions (2)Used By (0) Server Dashboard ================ [](#server-dashboard) [![Downloads](https://camo.githubusercontent.com/cae895fa7e22d8c696a810b8841a573420fcebea626eb2add3c6a276d5a75c5b/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f646f776e6c6f6164732f74657878617372756c657a2f7365727665722d64617368626f6172642f746f74616c3f7374796c653d706c6173746963266c6f676f3d676974687562266c6f676f436f6c6f723d7768697465266c6162656c3d446f776e6c6f616473266c6162656c436f6c6f723d6171756126636f6c6f723d626c7565)](https://camo.githubusercontent.com/cae895fa7e22d8c696a810b8841a573420fcebea626eb2add3c6a276d5a75c5b/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f646f776e6c6f6164732f74657878617372756c657a2f7365727665722d64617368626f6172642f746f74616c3f7374796c653d706c6173746963266c6f676f3d676974687562266c6f676f436f6c6f723d7768697465266c6162656c3d446f776e6c6f616473266c6162656c436f6c6f723d6171756126636f6c6f723d626c7565)[![Packagist Downloads](https://camo.githubusercontent.com/3ddff3ed7c1e432ab065b8f35233e3e079260480a74a736a4b5d9a324b5759a8/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f64742f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d7061636b6167697374266c6f676f436f6c6f723d7768697465266c6162656c3d446f776e6c6f616473266c6162656c436f6c6f723d626c756526636f6c6f723d676f6c64)](https://packagist.org/packages/texxasrulez/server-dashboard)[![Packagist Version](https://camo.githubusercontent.com/2eb9a93c9bffff53589d04169b2f985e9d679634bca71fae7166241fe36e7271/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f762f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d7061636b6167697374266c6f676f436f6c6f723d7768697465266c6162656c3d56657273696f6e266c6162656c436f6c6f723d626c756526636f6c6f723d6c696d65677265656e)](https://packagist.org/packages/texxasrulez/server-dashboard)[![Github License](https://camo.githubusercontent.com/bf28a89ba0bf8ca036d48ccb324b4d92e1d4aa96419c8b170e9721db0561c42d/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f6c6963656e73652f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d676974687562266c6162656c3d4c6963656e7365266c6162656c436f6c6f723d626c756526636f6c6f723d636f72616c)](https://github.com/texxasrulez/server-dashboard/LICENSE)[![GitHub Stars](https://camo.githubusercontent.com/c7f0054a23db492ff55f3bdb3356c6a4a5259fac065df6b77ba0293be96fe5e1/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f73746172732f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d676974687562266c6162656c3d5374617273266c6162656c436f6c6f723d626c756526636f6c6f723d64656570736b79626c7565)](https://github.com/texxasrulez/server-dashboard/stargazers)[![GitHub Issues](https://camo.githubusercontent.com/5aa0fc762295ff5dc3a25b6c6d38926a7632d3002946dcb01c52b6a0345a2968/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f6973737565732f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d676974687562266c6162656c3d497373756573266c6162656c436f6c6f723d626c756526636f6c6f723d61717561)](https://github.com/texxasrulez/server-dashboard/issues)[![GitHub Contributors](https://camo.githubusercontent.com/14b8bd2da0311fada64499aba2306cc1dcd2d63043e6b6c58616f983715adc43/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f636f6e7472696275746f72732f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d676974687562266c6f676f436f6c6f723d7768697465266c6162656c3d436f6e7472696275746f7273266c6162656c436f6c6f723d626c756526636f6c6f723d6f7263686964)](https://github.com/texxasrulez/server-dashboard/graphs/contributors)[![GitHub Forks](https://camo.githubusercontent.com/4641538699806eaa54056051a22d15c56c5c86b471da6c56620f2c2457f6f721/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f666f726b732f74657878617372756c657a2f7365727665722d64617368626f6172643f7374796c653d706c6173746963266c6f676f3d676974687562266c6f676f436f6c6f723d7768697465266c6162656c3d466f726b73266c6162656c436f6c6f723d626c756526636f6c6f723d6461726b6f72616e6765)](https://github.com/texxasrulez/server-dashboard/forks)[![Donate Paypal](https://camo.githubusercontent.com/02124075ee7ea4c192ef867cb30577b0b43ba74ea42b8dbe20b56ef518d94cdb/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f50617970616c2d4d6f6e65795f506c65617365212d626c75652e7376673f7374796c653d706c6173746963266c6162656c436f6c6f723d626c756526636f6c6f723d666f72657374677265656e266c6f676f3d70617970616c)](https://www.paypal.me/texxasrulez) Server Dashboard is a lightweight PHP admin console for operators who want one place to watch server health, services, probes, alerts, logs, cron health, and related maintenance tasks without introducing a framework-heavy stack. It is aimed at small VPS, homelab, agency, and single-host production environments where a pragmatic dashboard is more useful than a large observability platform. The project already has broad surface area; the current focus is making that surface safer to operate and easier to maintain. What It Includes ---------------- [](#what-it-includes) - Service and process dashboards - Local Attack Monitor page backed by cached security events - Visitors Map for public request IPs collected from dashboard-known logs - History and probe exports - Alerts administration and alert event history - Alerts rule backups stored alongside config backups under `config/backups/` - Lightweight Other Servers UP/DOWN page for LAN/WAN host attention checks - Config UI backed by `config/local.json` - Config UI includes an `About` tab backed by `data/about.json` - Config About tab can check GitHub releases from `SERVER_DASHBOARD_GITHUB_REPO=owner/repo` or the `package.json` repository - Cron health helpers and headless endpoints - User management and session auth - Log viewer, bookmarks, diagnostics, and server tests - Server tests include a read-only security-update check that uses local package-manager status without changing host state - Adapter-based environment detection for generic Linux and Hestia-style installs Production-Readiness Baseline ----------------------------- [](#production-readiness-baseline) Recent foundation work adds: - An actionable admin doctor at [`diag.php`](./diag.php) - Cron token management with reveal authorization, rotation, and audit logging - Monthly uptime/SLA reporting with JSON, CSV, and HTML export - A minimal PHP lint + PHPUnit baseline - A GitHub Actions CI workflow for lint, formatting, and test smoke checks - Admin-facing audit and asset audit tools in the diagnostics area - A left-sidebar navigation layout option without adding more header tabs - Live privileged log reads inside the existing Logs page - Correlated incidents, incident timelines, and per-service drill-down pages - Backup restore verification plus redacted troubleshooting bundle export - Micro-backup purge action that keeps a configurable newest set while deleting older micro directories on the backup host - Expanded browser smoke coverage for core operator flows Project Layout -------------- [](#project-layout) ``` api/ JSON endpoints and export/report actions assets/ CSS, JS, images, install scripts Adapters/ Environment adapter detection bin/ Admin and maintenance CLI tools config/ Defaults, schema, local overrides, backups data/ Writable JSON state and secrets-compatible data files docs/ Operator notes, migration notes, and hardening docs includes/ Bootstrap, auth, logging, mailer, page chrome lib/ Shared application logic state/ Runtime state, caches, generated artifacts tests/ PHPUnit unit and smoke tests ``` Install / Update ---------------- [](#install--update) 1. Place the project under your web root or subdirectory. 2. Create the first admin from CLI: `php bin/bootstrap-admin.php` 3. Sign in and immediately rotate the temporary password in [`users.php`](./users.php). 4. Verify the PHP user can write to: - `data/` - `state/` - `config/` when using config backups/UI saves 5. Generate script environment helpers if you plan to run bundled cron/systemd helpers: `php bin/install-scripts.php` For updates, replace the code, keep your writable `data/`, `state/`, and `config/local.json`, then rerun the validation steps in the Testing section below. Configuration Model ------------------- [](#configuration-model) The project keeps the current compatibility model intact: - Primary editable config: `config/local.json` - Schema/defaults: `config/schema.php` and `config/defaults.php` - Compatibility sync: `data/security_config.json` - Runtime fallbacks: environment variables and token files - Alerts rule snapshots from [`alerts_admin.php`](./alerts_admin.php): `config/backups/alerts-YYYYmmdd-HHMMSS.json` - Alerts admin can restore the latest alerts snapshot back into `data/alerts.json` after confirmation Important configuration paths: - Cron token: `alerts.cron_token`, `DASH_CRON_TOKEN`, `data/cron_token.txt` - Mail transport: `mail.*` - Security controls: `security.*` - History and cron expectations: `history.*`, `alerts.*`, `cron.*` Admin configuration is done primarily through [`config.php`](./config.php). CLI/headless changes can use [`bin/config-cli.php`](./bin/config-cli.php). Cron / Headless Usage --------------------- [](#cron--headless-usage) The cron helper flow no longer adds tokens to generated cron jobs. Use plain `curl` lines for the built-in cron endpoints: ``` curl -fsS "https://example.test/api/cron_mark.php?what=alerts" curl -fsS "https://example.test/api/alerts_eval.php?probe=1" curl -fsS "https://example.test/api/cron_heartbeat.php?id=custom_job" ``` Some other automation endpoints may still support header-based auth for compatibility, but the cron jobs generated from `cron.php` no longer require cron tokens. If you use the bundled scripts: - Generate script env: `php bin/install-scripts.php` - Review: [`scripts/lib/dashboard_env.sh`](./scripts/lib/dashboard_env.sh) - Generated env file: [`state/generated/dashboard-scripts.env`](./state/generated/dashboard-scripts.env) ### NVMe Collector [](#nvme-collector) Install `smartmontools` on the host so `smartctl` is available, then run: ``` php scripts/nvme_collect.php ``` The collector reads `/dev/nvme0n1` and `/dev/nvme1n1`, writes the latest snapshot to [`state/nvme_status.json`](./state/nvme_status.json), and appends one JSON object per run to [`data/nvme_history.jsonl`](./data/nvme_history.jsonl). The admin UI now includes a top-level [`drive_health.php`](./drive_health.php) page backed by [`api/drive_health_status.php`](./api/drive_health_status.php) for the latest snapshot, [`api/drive_health_history.php`](./api/drive_health_history.php) for filtered JSONL history and chart data, and [`api/drive_health_export.php`](./api/drive_health_export.php) for JSON/CSV export. The raw history table is paginated in the browser with a persisted rows-per-page control. See [`docs/pages/drive-health.md`](./docs/pages/drive-health.md) for page behavior and data sources. ### Attack Monitor Collector [](#attack-monitor-collector) Run the local collector from cron: ``` */1 * * * * php /path/to/server-dashboard/scripts/attack_monitor_collect.php >/dev/null 2>&1 ``` The collector reads only allowlisted local security sources, writes sanitized cache to [`state/security/attack_monitor_latest.json`](./state/security/attack_monitor_latest.json) and [`state/security/attack_events.jsonl`](./state/security/attack_events.jsonl), and powers the admin-only [`security_monitor.php`](./security_monitor.php) page plus [`api/watch_data.php`](./api/watch_data.php). The live event stream is paginated in the browser with a persisted rows-per-page control. CrowdSec decisions are read through `cscli decisions list -o json`. If CrowdSec uses a non-default Local API endpoint or port, set `attack_monitor.crowdsec_config_path` in the Config page's Attack Monitor section to the CrowdSec config file that contains that endpoint, such as `/etc/crowdsec/config.yaml`. See [`docs/pages/attack-monitor.md`](./docs/pages/attack-monitor.md) and [`docs/config-tabs/attack-monitor.md`](./docs/config-tabs/attack-monitor.md) for page behavior and settings. ### Other Servers [](#other-servers) The [`other_servers.php`](./other_servers.php) page provides simple UP/DOWN checks for configured LAN or WAN hosts. It does not require agents, port scans, or remote resource collection. Optional SSH details can collect a small read-only summary when configured. Results are cached in [`state/other_servers_latest.json`](./state/other_servers_latest.json), and admins can refresh checks from the page or run `php scripts/other_servers_collect.php` from cron. Example config: ``` { "other_servers": { "enabled": true, "check_timeout": 2, "servers": [ { "enabled": true, "name": "LAMP Server", "link": "https://lamp.domain.com", "host": "192.168.1.20", "icon": "server", "check_type": "ping" }, { "enabled": true, "name": "Plex Server", "host": "192.168.1.30", "icon": "tv", "check_type": "tcp", "port": 32400 } ] } } ``` Supported checks are `ping`, `tcp`, `http`, and `https`. TCP, HTTP, and HTTPS require `port`. Ping can report DOWN when ICMP is blocked, so TCP or HTTP checks are often more reliable. The optional `link` field turns the server name on the Other Servers page into an HTTP/HTTPS link. Optional SSH details can be enabled per server in Config -> Other Servers. When `detail_method` is `ssh`, the dashboard uses the configured password or key login to run a fixed read-only command set for hostname, OS release, kernel, uptime, and load. Key auth supports `auto`, `openssh`, and `libssh2` backends; use `openssh` when the same key works with `ssh -i` but libssh2 rejects it. SSH passwords, key paths, and optional key passphrases are stored in `config/local.json`. ### Visitors Collector [](#visitors-collector) Run the local visitor collector from cron: ``` */5 * * * * php /path/to/server-dashboard/scripts/visitors_collect.php >/dev/null 2>&1 ``` The collector reads configured logical sources only, writes latest status to [`state/visitors/latest.json`](./state/visitors/latest.json), caches GeoIP results under [`state/visitors/geo_cache.json`](./state/visitors/geo_cache.json), and appends events to [`data/visitor_events.jsonl`](./data/visitor_events.jsonl). The Visitors config tab can store MaxMind credentials and download/update the configured MMDB path. See [`docs/visitors.md`](./docs/visitors.md) for GeoIP setup, privacy notes, and troubleshooting. Navigation Order ---------------- [](#navigation-order) Top-level admin navigation order is defined by the feature registry in [`lib/Config.php`](./lib/Config.php), but it can now be reordered from the `Features` tab in [`config.php`](./config.php) by dragging items in the `Navigation Order` block and saving. If you prefer to edit it manually, the saved override is stored under `ui.nav_feature_order` in `config/local.json`. Logs: Copied And Live Privileged -------------------------------- [](#logs-copied-and-live-privileged) The existing Logs page still keeps the copied-log mirror under [`state/logs_mirror`](./state/logs_mirror). That workflow is unchanged and remains the default view. The same page now also includes an in-page switcher for `Copied Logs` and `Live Privileged Logs`. No new header tab was added. The live mode is for admin users only and reads selected protected logs on demand without making `/var/log` world-readable and without running PHP or the web server as root. For the copied-log workflow, the separate log-watcher mirror should run as `root` and then write mirrored files back with the configured destination owner. That preserves the quick copied-log view for current root-owned service and vhost logs without changing permissions on the source files. ### Security Model [](#security-model) - Browser input is limited to an allowlisted logical key such as `syslog` or `nginx_error`. - [`logs.php`](./logs.php) validates the admin session, applies CSRF checks, clamps line counts, and calls one exact sudo target. - [`scripts/log_bridge.sh`](./scripts/log_bridge.sh) is the only root-executed entrypoint. It accepts only `--key`, `--mode`, `--lines`, and `--search`. - The bridge resolves keys from [`config/privileged_logs.json`](./config/privileged_logs.json), allows only configured file or journal sources, treats search as a literal string, and never accepts raw paths or arbitrary commands from the web app. - Sudo is scoped to the exact bridge script through a sudoers drop-in. There is no general shell execution path from the dashboard. ### Allowed Sources [](#allowed-sources) The default allowlist currently includes: - `exim_main` - `exim_reject` - `nginx_error` - `nginx_access` - `syslog` - `auth` - `fail2ban` Each entry defines its label, internal key, source, whether literal search is allowed, and default/max line counts in [`config/privileged_logs.json`](./config/privileged_logs.json). ### Sudoers Setup [](#sudoers-setup) The live privileged-log mode only works after an admin explicitly allows the web user to run the exact bridge script through `sudo`. Do not place the helper script itself in `/etc/sudoers.d/`. The helper only prints the sudoers rule. The file in `/etc/sudoers.d/` must contain sudoers syntax, not shell code. 1. Confirm the actual PHP/web user on the host. On Hestia-style single-user installs this may be your hosting account name, for example `user:user`. On more typical setups it may be `www-data`, `apache`, or similar. 2. Generate an example drop-in for that exact web user: ``` bash scripts/render_log_bridge_sudoers.sh www-data ``` 3. Copy the printed rule into `/etc/sudoers.d/server-dashboard-log-bridge`. Example content: ``` www-data ALL=(root) NOPASSWD: /path/to/server-dashboard/scripts/log_bridge.sh ``` 4. Set the correct permissions and validate it before enabling it: ``` chmod +x scripts/log_bridge.sh sudo chmod 440 /etc/sudoers.d/server-dashboard-log-bridge sudo visudo -cf /etc/sudoers.d/server-dashboard-log-bridge ``` 5. Test the bridge directly from shell before trying the UI: ``` sudo -n /path/to/server-dashboard/scripts/log_bridge.sh --key syslog --mode tail --lines 50 sudo -n /path/to/server-dashboard/scripts/log_bridge.sh --key auth --mode tail --lines 50 sudo -n /path/to/server-dashboard/scripts/log_bridge.sh --key syslog --mode tail --lines 50 --search "CRON" ``` 6. Open the existing Logs page, switch to `Live Privileged Logs`, pick an allowlisted source, and refresh. The expected rule should allow only the exact bridge script path. It should not allow arbitrary shell commands, arbitrary arguments, or a directory wildcard. Example: ``` www-data ALL=(root) NOPASSWD: /path/to/server-dashboard/scripts/log_bridge.sh ``` For a Hestia-style install where the PHP user is a hosting account such as `user`, the practical commands still follow the same pattern: ``` bash /path/to/server-dashboard/scripts/render_log_bridge_sudoers.sh user sudo tee /etc/sudoers.d/server-dashboard-log-bridge >/dev/null Features`. Unchecking a feature removes its header tab and returns a disabled response for direct page requests until it is re-enabled. Testing ------- [](#testing) Recommended local verification sequence: ``` bash bin/php-lint.sh vendor/bin/phpunit --configuration phpunit.xml.dist php bin/smoke-admin.php npm run format:check:baseline ``` Add browser smoke after JS or page-behavior changes: ``` bash bin/browser-smoke.sh ``` Current browser smoke covers: - dashboard load - config UI load - history load - logs page mode switching - incident list/detail flow - service detail drill-down - backups verification/support panel render - speedtest page render PHP lint: ``` bash bin/php-lint.sh ``` Install test dependencies: ``` composer install --no-interaction --prefer-dist ``` Run PHPUnit: ``` vendor/bin/phpunit --configuration phpunit.xml.dist ``` Run the lightweight admin smoke probe: ``` php bin/smoke-admin.php ``` Expected result: - one `[OK]` line for each maintained endpoint/page check - exit code `0` on success - any `[FAIL]` line or invalid JSON causes a non-zero exit Run the browser smoke checks for the key admin pages: ``` bash bin/browser-smoke.sh ``` Expected result: - `browser smoke passed: diag` - `browser smoke passed: config` - `browser smoke passed: history` - `browser smoke passed: speedtest` Expected skip result in restricted environments: - `browser smoke skipped: no Chrome/Chromium binary found` - `browser smoke skipped: local TCP listener unavailable in this environment` Those skip cases are environment limitations, not app failures. Format check: ``` npm ci npm run format:check:baseline ``` The PHPUnit baseline is intentionally small. It covers: - shared helper behavior - config bootstrap assumptions - config mutation and compatibility sync - uptime report interval math - smoke checks for critical JSON endpoints - page rendering for maintained admin tools The browser smoke script loads the real pages through a local `php -S` server and verifies: - `diag.php` renders the doctor UI - `config.php` renders the Security tab token controls - `history.php` opens the HTML report modal - `speedtest.php` changes visible rows when the page-size selector changes There is also an admin-facing audit viewer at [`tools/admin_audit.php`](./tools/admin_audit.php) for recent security and diagnostic actions already written to: - [`data/logs/security.log`](./data/logs/security.log) - [`state/logs/diag_audit.log`](./state/logs/diag_audit.log) Security log entries are created by token-management actions such as reveal authorization and token rotation. Diagnostic log entries are created by server-test actions and related manual diagnostics. There is still a legacy full-repo formatting backlog. CI enforces a maintained-file formatting baseline introduced in this hardening pass instead of gating on untouched historical files. CI -- [](#ci) The repository now includes [`.github/workflows/ci.yml`](./.github/workflows/ci.yml) with: - `composer install --no-interaction --prefer-dist` - `npm ci` - PHP lint - maintained-file Prettier baseline - PHPUnit smoke/unit tests - browser smoke checks for key admin pages This is a floor, not a full release pipeline. Screenshots ----------- [](#screenshots) Existing screenshots live under: - [`assets/images/screenshots/main.png`](./assets/images/screenshots/main.png) - [`assets/images/screenshots/config.png`](./assets/images/screenshots/config.png) - [`assets/images/screenshots/history.png`](./assets/images/screenshots/history.png) - [`assets/images/screenshots/services.png`](./assets/images/screenshots/services.png) - [`assets/images/screenshots/logs.png`](./assets/images/screenshots/logs.png) Roadmap Summary --------------- [](#roadmap-summary) Near-term work that still makes sense: - broader token and secret inventory management - more probe/alert reporting views - additional PHPUnit coverage around config mutation and auth flows - smoke probes for more admin APIs - stronger release/update docs - follow-up hardening on writable state and backup flows ### Health Score 37 — LowBetter than 81% of packages Maintenance97 Actively maintained with recent releases Popularity0 Limited adoption so far Community6 Small or concentrated contributor base Maturity38 Early-stage or recently created project Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Unknown Total 1 Last Release 15d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/95c3af6e41a9786e8be2edb48176e43a7d1ddef429793a312168450ff4269deb?d=identicon)[texxasrulez](/maintainers/texxasrulez) --- Top Contributors [![texxasrulez](https://avatars.githubusercontent.com/u/10519182?v=4)](https://github.com/texxasrulez "texxasrulez (2 commits)") ### Code Quality TestsPHPUnit ### Embed Badge ![Health badge](/badges/texxasrulez-server-dashboard/health.svg) ``` [![Health](https://phpackages.com/badges/texxasrulez-server-dashboard/health.svg)](https://phpackages.com/packages/texxasrulez-server-dashboard) ``` ### Alternatives [moodle/moodle Moodle - the world's open source learning platform 7.1k86.6k28](/packages/moodle-moodle)[aknife/ip 获取ip信息，支持ipv4和 ipv6 263.4k1](/packages/aknife-ip) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)