Diagnostics stay with you.
The extension, collector and dashboard operate locally. No Cloud account or vendor telemetry is required. You control the configuration, file access and data on the server.
PHPRAY / PRIVACY & SECURITY
Your application.
Clear data boundaries.
PHPRay starts locally: on your server, with SQLite history and your own dashboard. Cloud is a separate connection that you explicitly enable.
Review what diagnostic data is captured, what leaves the server and how to limit observation. Concrete rules, configuration parameters and links to the documentation.
Apache-2.0 No Cloud account for local use Cloud · available
01
What you collect. What you send.
Local diagnostics and Cloud export have different boundaries. The rules below describe agent-side processing before data is sent to the console.
Aggregates and selected traces.
Once configured, the agent sends per-site aggregates and selected detailed traces. Trace selection and plan quotas are separate from function-profile sampling.
Scroll the table to see all columns.
| Data | Scope and processing | Rule |
|---|---|---|
| SQL | Query fingerprint Numbers and string literals are replaced with “?” (query fingerprint). Query structure remains available for analysis. | FINGERPRINT |
| URI | Path and parameter names Query parameter values are replaced with “?”. The path remains visible; excluded ignore_uris are not sent. | VALUES MASKED |
| Host / domain | Site identity Host identifies the site. The privacy.mask_host option replaces it with a site identifier; the collector configuration defaults to false. | CONFIGURABLE |
| Errors and stack traces | Abbreviated diagnostic context Error messages are truncated. File paths are abbreviated from wp-content/ or vendor/. Truncation does not remove every potential secret. | REVIEW CONTENT |
| Bodies and visitor data | Excluded from documented export No request or response bodies, cookies, visitor IPs or user identifiers. Headers are omitted except for the Host identity exception. | NOT SENT |
Data minimisation has a defined scope.
Masking query values does not remove data from the URL path. Truncating error messages is not full anonymisation. Review URL naming, error content and exclusions before enabling export.
Inspect an example export fragment
Illustrative data shows an SQL fingerprint and masked query values. This switch changes only the example; it does not configure a server.
{
"host": "store.example.com",
"uri": "/checkout/?order=?&source=?",
"queries": [
{
"sql": "SELECT meta_value FROM wp_postmeta WHERE post_id = ? AND meta_key = ?"
}
]
}Host remains visible in this example.
02
Access starts at the network boundary.
The local dashboard, Cloud connection and server configuration have separate mechanisms. The local console does not need to be publicly accessible.
Local dashboard and API
The default bind is 127.0.0.1:9191, with JWT authorisation. The CLI uses the same authentication configuration. Local access is separate from Cloud sign-in.
-addr / --listen · [auth]Dashboard accessA key for a specific server
The Cloud protocol uses a server key in the Bearer header. A key belongs to one account and one server; the specification describes rotation with a 24-hour grace period.
[cloud].server_keyIdentity and protocolOutbound connection
The collector initiates HTTPS connections to Cloud. It retrieves profiling commands through long polling. Cloud does not open an SSH session or an inbound connection to your server.
HTTPS · /v1/controlCloud connectionFor the server operator
Set your own JWT secret and restrict access to configuration and trace files. For remote access, provide access control and transport protection; changing the listen address (-addr) alone does not provide those safeguards.
03
History has a time window and a limit.
Local retention and the export buffer are separate settings. Cloud quotas do not replace the storage rules on your server.
LOCAL COLLECTORDEFAULTS
30daystraces and aggregates
4GBSQLite database cap
7–90daysCloud: by plan
Time windows and the size cap are independent. The oldest records are pruned when either limit is reached. These defaults can be changed in the configuration.
PHPRAY CLOUDAVAILABLE
Coverage depends on the plan.
Cloud: 7 days (Free), 30 days (Solo, Studio), 60 days (Agency), 90 days (Fleet) — traces and aggregates alike. Locally: 30 days by default with a hard 4 GB cap, both configurable.
Opole, Poland · EUCloud location
Show retention settingscollector.toml
Two limits. One configuration.
The [retention] section sets how long traces and aggregates are kept and the size of the local database. These are the defaults; copying this fragment does not change your server configuration.
[retention] days = 30 max_mb = 4096
The Cloud upload buffer has a separate cap: 32 MB by default. SQLite retention does not define rotation of raw JSONL files or your backups; include these in your host configuration.
04
Measurement overhead — with the full context.
Application impact is part of the deployment decision. We distinguish lightweight event observation from deeper function profiling.
OVERHEAD / THE FULL PICTURE
Two layers.
Two different costs.
Always-on observes request events. Function profiling goes deeper and is sampled by default.
100%summaries of eligible requests
3%default function-profile sample
The remaining 97% collect no function samples. Detailed traces and Cloud export have separate rules and quotas.
What was measured, and what remains unverified
Test conditionsPreliminary measurements used WooCommerce, Storefront, 22 plugins, PHP 8.3 and OPcache. Alternating runs with and without the extension, on a laptop. Always-on fell within measurement noise. Profiling every request cost measurably more, but far below a classic execute_ex hook.
Interpretation limitsThis is not a certified benchmark or an overhead guarantee for your server. Full methodology and raw data from a dedicated host are planned before 1.0. Profiling a single URL or time window limits the diagnostic scope.
Source and measurement limitations →For a focused investigation, limit profiling to a URL or a short time window. Then compare results under the same load and application configuration.
Sampling and profiling rules05
This site and the demo
The product site runs in the browser without an account. The public demo is the real Cloud console with test-store data, opened with a read-only token.
Preferences in the browser
The site stores only your language and theme choice locally. No account, no cookies and no password forms. The contact form opens your own mail client — you send the message yourself.
Read-only demo
The demo at app.phpray.dev/demo is the real Cloud console opened with a read-only token. You see test-store data; nothing can be changed and no server of yours gets connected.
Cookieless statistics, on our server
The site’s code loads no third-party scripts, external fonts or CDN libraries. Visits are counted by our own Umami instance (stats.phpray.dev): no cookies, no user identifier, no cross-site tracking, the IP address is not stored. The web server keeps standard access logs, described in the privacy policy.
You can remove website data stored by the browser in its settings. The privacy policy covers the site, the software and Cloud in full.
Privacy policyWHO IS BEHIND IT
IQgroup PHPRay
PHPRay is built by IQgroup Adam Buhl from Opole, Poland — the company behind the IQhost hosting brand, which runs 5,000 PHP sites. We roll it out on our own servers first, and the technical description and documentation are public so the assumptions can be reviewed. That is not a substitute for an independent audit or a security certification.
Basis: the PHPRay 0.14 documentation on this site. The ingest v1 protocol is marked as a draft.Open documentation
Know the boundaries. Explore the tool.
Inspect sample data without an account, or set up PHPRay on your own server.