Download the PHP package aksoom-hussain/kaveh without Composer
On this page you can find all versions of the php package aksoom-hussain/kaveh. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download aksoom-hussain/kaveh
More information about aksoom-hussain/kaveh
Files in aksoom-hussain/kaveh
Package kaveh
Short Description Kaveh — Telescope/Pulse-inspired Laravel monitoring (client + self-hosted server in one package)
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package kaveh
Kaveh
Self-hosted Laravel monitoring — one Composer package that can run as a client, a server, or both.
Inspired by Laravel Telescope and Laravel Pulse, with a key difference: production apps can ship telemetry off the app disk to a separate Kaveh host instead of storing everything locally.
| Packagist | https://packagist.org/packages/aksoom-hussain/kaveh |
| Source | https://github.com/Aksoom-Hussain/kaveh |
| License | MIT |
Why Kaveh?
| Problem | What Kaveh does |
|---|---|
| Telescope fills production disks | Remote mode batches events to a central server |
| You need request / exception / job visibility | Built-in watchers (Telescope-style) |
| You want Pulse-like graphs | Dashboard charts + optional laravel/pulse metrics API |
| Multiple apps, one ops dashboard | Projects + API keys (multi-tenant ingest) |
| “What failed for checkout today?” | Custom Kaveh::track() events, searchable by name and tag |
Use cases (pick one)
1) Production app → central Kaveh server (recommended)
Who: teams with one or more Laravel apps who want a shared monitoring host.
Server (once):
Client (each app):
Then open the server dashboard → select the project → time range 1h / 6h / 24h / 7d → browse requests, exceptions, jobs, slow queries.
2) Local / staging only (Telescope replacement on one box)
Who: developers who want Telescope-like insight without a second host.
Events stay in the same app database. Good for staging; for production prefer use case 1.
3) Same app as client + server
Who: small installs that want watchers and dashboard on one Laravel app.
Always run php artisan queue:work. Prefer role=server on the monitor host and role=client on production apps if traffic is high (avoids the monitor watching itself).
4) Custom business events (beyond HTTP / jobs)
Track domain failures that watchers will not see automatically:
These show up in Events like Telescope entries, with type custom, searchable name/tags, and full JSON context on the detail page.
Quick start
Requirements
- PHP 8.2+
- Laravel 11 / 12 / 13
- A queue worker when
KAVEH_USE_QUEUE=true(recommended)
Install
| Role | You get |
|---|---|
client |
Watchers + Kaveh::track() + local/remote ship |
server |
Ingest API + dashboard + alerts + metrics API |
both |
Everything on one app |
Publishes:
config/kaveh.phpApp\Providers\KavehServiceProvider(gateviewKaveh, same idea as Telescope/Pulse).envkeys (KAVEH_*)
What gets collected automatically?
| Watcher | Captures | Toggle |
|---|---|---|
| Exceptions | Error/critical exceptions + stack | KAVEH_WATCH_EXCEPTIONS |
| Requests | Method, URI, status, duration, IP | KAVEH_WATCH_REQUESTS |
| Queries | Slow SQL over threshold | KAVEH_WATCH_QUERIES + KAVEH_SLOW_QUERY_MS |
| Jobs | Processed / failed queue jobs | KAVEH_WATCH_JOBS |
| Logs | Error logs (noisy; off by default) | KAVEH_WATCH_LOGS |
Request watcher ignores /kaveh/*, /pulse/*, /telescope/*, /api/v1/ingest, Livewire, etc. Add more with KAVEH_IGNORE_PATHS.
Kaveh’s own jobs (FlushEventsJob, anything under Kaveh\) are ignored so the monitor does not flood itself.
Server dashboard
After server install:
| Surface | URL |
|---|---|
| Login | /kaveh/login |
| Overview | Graphs + recent events (project + 1h/6h/24h/7d) |
| Events | Telescope-style list (verb, path, status, duration) |
| Alerts | Threshold rules → webhook / email |
| Projects | Multi-tenant projects + API keys |
Authorization — edit the published provider:
Defaults are permissive — tighten them before going public. The published app/Providers/KavehServiceProvider.php stub returns true for any authenticated user. If that provider is not registered, the package's built-in default allows access in the local environment or to any authenticated user.
Optional Pulse graphs
If laravel/pulse is installed on the server host, Overview charts read pulse_aggregates (CPU, memory, traffic, queue, cache):
Ingest API (for custom shippers / debugging)
202accepted ·207partial (per-event; the valid ones are still stored) ·401bad key ·413gzip body overKAVEH_MAX_DECOMPRESSED_BYTES(16 MB) ·422invalid ·429rate limited- Duplicate event ids per project are ignored (idempotent)
cURL check:
Configuration cheatsheet
Schedule on the server:
Example: wire a production app in 5 minutes
- On Kaveh server: Projects → create a project (e.g. Shop) → Issue API key → copy
kv_… -
On the application you want to monitor:
- Hit any HTTP route or fail a job → refresh Kaveh Events (select that project).
- Optionally track checkout / webhook failures with
Kaveh::track()(see use case 4).
Security notes
- Treat API keys like passwords; rotate from Projects.
- Context is redacted (passwords, tokens, auth headers) before ship.
- Lock down
viewKavehbefore exposing/kavehon the public internet. - Prefer HTTPS for
KAVEH_SERVER_URL.
More: docs/security.md
Documentation
| Doc | Description |
|---|---|
| docs/use-cases.md | Deeper scenarios & architecture diagrams |
| docs/client.md | Client install, watchers, queue, track() |
| docs/server.md | Server install, dashboard, alerts, keys |
| docs/ingest-api.md | Ingest payload reference |
| docs/custom-events.md | Snippets for billing, queues, webhooks |
| CHANGELOG.md | What changed, per release |
| UPGRADE.md | 0.1.4 → 0.2.0 upgrade guide |
Upgrading from 0.1.4
The server tables are now prefixed (kaveh_organizations, kaveh_organization_user, kaveh_projects, kaveh_api_keys, kaveh_events, kaveh_alert_rules, kaveh_alert_firings) so they cannot collide with a host app's tables under role=both. The client buffer table is kaveh_client_events.
php artisan migrate renames 0.1.4's unprefixed tables in place and keeps the data. It only renames a table whose column set matches 0.1.4 exactly and whose kaveh_* target is free; anything ambiguous aborts the batch with a warning rather than touching a host table.
There is more to it than the tables — RAG/chat and its openai_* config keys are gone, redact.keys is now additive, and kaveh:install no longer overwrites a published config. Follow UPGRADE.md, which has the ordered procedure and a verification step.
Development
Package layout: src/, config/, routes/, resources/views/, database/migrations/, stubs/, docs/.
License
MIT
All versions of kaveh with dependencies
illuminate/support Version ^11.0|^12.0|^13.0
illuminate/http Version ^11.0|^12.0|^13.0
illuminate/database Version ^11.0|^12.0|^13.0
illuminate/queue Version ^11.0|^12.0|^13.0
illuminate/console Version ^11.0|^12.0|^13.0
illuminate/routing Version ^11.0|^12.0|^13.0
illuminate/view Version ^11.0|^12.0|^13.0
illuminate/auth Version ^11.0|^12.0|^13.0
illuminate/foundation Version ^11.0|^12.0|^13.0
illuminate/events Version ^11.0|^12.0|^13.0
illuminate/cache Version ^11.0|^12.0|^13.0
illuminate/mail Version ^11.0|^12.0|^13.0
guzzlehttp/guzzle Version ^7.8