# deedyn status — functional prototype v0.9.2 (production readiness + tuning) This is a **working PHP monitoring prototype** with the shared CI plus a multi-database setup wizard for PostgreSQL, MariaDB, MySQL and SQLite. ## It really checks - HTTP / HTTPS with redirects, TLS verification, HTTP status and optional keyword - REST/API endpoints using the HTTP checker - TCP port reachability - ICMP ping where PHP `exec()` is allowed and the OS has `ping` - DNS records: A, AAAA, MX, TXT, CNAME, NS, SOA - TLS/SSL certificate validity and expiry - Public service probes - Official Atlassian Statuspage-compatible JSON status - Server-side crowd outage reports with coarse location fields - Per-monitor intervals - Result history in SQLite ## SaaS foundation included - Organizations schema - Users/memberships schema - Dynamic plans - Dynamic feature JSON - Subscriptions schema - Stripe provider interface/stub - Admin panel - Dark/light switch - German/English UI - JSON API endpoint - Public service directory - Public service status pages ## Fast install on Plesk Requirements: - PHP 8.2+ - PDO SQLite - cURL - OpenSSL - writable `storage/` - `exec()` + system `ping` only if ICMP checks are wanted Upload the **contents of this ZIP** to the document root, then open: `https://YOUR-DOMAIN/install.php` The installer creates `storage/app.sqlite` and `storage/config.php`. After installation, click **"Run checks now"** in the dashboard once. ## Cron For automatic checks, add a Plesk scheduled task every minute: ```bash /opt/plesk/php/8.2/bin/php /var/www/vhosts/YOUR-SUBSCRIPTION/YOUR-DOMAIN/cron.php ``` Use your real path. The cron job only runs monitors that are due according to each monitor's `interval_seconds`. ### Note about sub-minute intervals Plesk cron normally runs at 1-minute granularity. The data model already accepts shorter values (minimum 20s), but real 20/30-second checks need a persistent worker/service. That is planned for the distributed-probe version. ## Admin `/admin/` Admin can currently: - add/edit plans - change prices, monitor limits, minimum intervals, retention and region limits - add/edit public services - configure generic Atlassian Statuspage JSON adapters - add/edit HTTP/API/keyword/TCP/ping/DNS/TLS monitors ## Seeded public services - Cloudflare — real HTTPS probe + official Statuspage JSON adapter - GitHub — real HTTPS probe + official Statuspage JSON adapter - Google — real HTTPS probe, official link prepared - OpenAI — real HTTPS probe, official status link prepared Only sources with an explicit machine-readable adapter should be automatically ingested. Logos/trademarks are deliberately not bundled. ## Security / production note This is a **prototype**. Before commercial production add: - PostgreSQL instead of SQLite - Redis queues / distributed workers - real customer registration and email verification - password reset / MFA - organization isolation tests - rate limiting at reverse proxy and application level - captcha/bot scoring for crowd reports - encrypted connector credentials - incident/notification engine - audit log - backups - legal/privacy flows - real Stripe webhook verification - distributed EU probes on independent providers ## Recommended next architecture Frontend / own control plane → PostgreSQL + Redis → provider adapters → OneUptime / Blackbox Exporter / custom probes → external EU probe nodes → official provider status adapters → crowd outage engine → notifications → billing The central customer/product model should remain independent of any one monitoring engine. ## v0.4 database selection Open `/install.php` and select: - PostgreSQL — recommended long-term production choice - MariaDB — excellent direct Plesk production choice - MySQL — supported production choice - SQLite — development / prototype / small single-node choice For server databases, create an empty database and user first. The installer validates the live connection and creates the application schema. After installation, `/admin/system.php` shows the active database engine, PDO driver, server version, available PDO drivers and table counters. See `DATABASES.md`. ## v0.5 control-plane upgrade v0.5 automatically creates the new control-plane tables when an installed v0.4 application is opened. New areas: - `/admin/customers.php` - `/admin/subscriptions.php` - `/admin/integrations.php` - `/admin/api-keys.php` - `/admin/settings.php` - `/admin/audit.php` - `/account.php` - `/notifications.php` - `/api-keys.php` - `/api/v1/` See `CONTROL-PLANE.md`. ### Upgrade from approved v0.4 Back up `storage/config.php` and the current database first. Then replace application files with v0.5 while keeping: - `storage/config.php` - `storage/install.lock` - `storage/app.sqlite` if SQLite is used On the first request, the new schema is added idempotently. ## v0.6 environment installer New setup profiles: - Standard Hosting: Plesk/cPanel/DirectAdmin/shared webhost, no root or Redis required - Pro Server: VPS/Dedicated/Proxmox VM/LXC, Redis/persistent workers recommended PHP 8.3 is the minimum supported runtime; PHP 8.5 is the target/recommended runtime. The installer now runs live rewrite, Authorization-header, storage-exposure, HTTPS, security-header, OPcache, filesystem and PHP tuning checks. Critical security/routing issues can block installation. See `SERVER-TUNING.md` and `deploy/`. ## v0.8 admin UX The admin area now uses a dedicated control-plane shell with a persistent sidebar and an operational overview instead of a feature-card directory. See `ADMIN-UX.md`. ## v0.8 cache hotfix The v0.6.1 admin HTML could be served together with a browser/proxy-cached older `app.css`, which makes the new sidebar/dashboard appear as largely unstyled raw HTML. All first-party CSS/JS assets now use automatic cache-busting query versions derived from the deployed file metadata. After upgrading, a normal reload should request a new asset URL automatically; a manual hard refresh should no longer be required for future UI updates. ## v0.8 Laravel transition The live runtime remains fully usable. The new `laravel/` source tree introduces the Laravel 13 core side-by-side and can be validated under Admin → System → Framework migration. See `LARAVEL-MIGRATION.md`. ## v0.8 Fixes the Plesk Web-PHP vs CLI-PHP mismatch during Composer installation and adds safer framework migration diagnostics. ## v0.8 Composer requirements are aligned with the current Laravel 13 skeleton (`laravel/tinker ^3.0`) and the Blade layout component path is corrected. ## v0.8 Adds all required Laravel writable runtime directories to the ZIP and a Plesk permission repair script. ## v0.8 Adds a safe legacy-config → Laravel `.env` importer and CLI preflight so Plesk installs no longer depend on copying environment snippets manually. ## v0.8 The database migration is now followed by dedicated CLI, queue, account-adoption and HTTP staging smoke tests. See `STAGING-TEST.md`. ## v0.8 Adds Plesk-safe Artisan execution, hostname-only APP_URL updates and Composer lock resolution against the supported PHP 8.3 minimum. ## v0.8 Fixes the PHP-platform checker false positive and makes Plesk-safe Artisan execution the default through `laravel/bin/deedyn`. ## v0.8 Hardens overlapping scheduler runs, adds unique monitor jobs and introduces scheduler/worker runtime health for the standard hosting profile. ## v0.8 The Laravel staging runtime now contains the actual control plane and customer workspace rather than a framework transition placeholder. See `UPGRADE-v0.8.md`. ## v0.8.1 Hotfixes the first Laravel Control Plane runtime: customer portal authorization and missing inverse Eloquent relationships. ## v0.9.0 Adds the queued mail/notification pipeline, monitor transition alerts, customer-owned connectors and delivery diagnostics. See `NOTIFICATIONS.md` and `UPGRADE-v0.9.md`. ## v0.9.1 Notification-page diagnostics, cache-busted assets, clearer portal navigation and a larger UI type scale. ## v0.9.2 Fixes CLI-safe Blade rendering for notification diagnostics by guarding the Laravel error bag in shared layouts.