Investigate backend problems from your AI chat, using read-only facts from Loki, Prometheus, PostgreSQL, Redis, BullMQ, Docker and GitHub observations. No SDK or middleware in your application.

Ask your client:

Check my backend logs for repeated errors. If there are database-related failures, inspect current PostgreSQL sessions and blocking locks. Separate observations from hypotheses.

The MCP server supplies tools; your AI client supplies the conversation and model. No AI subscription or reasoning provider is included.

What's new in 1.7.0

Prometheus historical metrics through inspect_metrics, setup and CLI: scoped availability, HTTP latency/error/throughput, process resources and bounded before/after window comparison.
Opt-in PostgreSQL performance statistics for statements, tables, indexes, VACUUM and I/O; existing health/activity/locks remain the default.
Safe local MCP lifecycle diagnostics on stderr, without credentials, arguments or tool results.
Workspace setup prints a Linux Node/npx @latest launch configuration. Package resolution happens on new starts, not while an MCP process is running.

There are 14 MCP tools. Diagnostics remain read-only; no arbitrary SQL/PromQL or maintenance commands are exposed. Usage statistics retain their separate, explicit opt-in consent.

Before you install

Node.js 24+ and npm on Linux or WSL. This release does not support native Windows or macOS. In WSL, use Linux Node/npm, not Windows npm on a UNC path.
A compatible MCP client, such as VS Code with Copilot Agent.
For your own system: access to at least one supported source. Use restricted diagnostic credentials and source scopes for your application.
Optional demo: Docker Engine available in the same environment.

This is proprietary software, not an open-source release. Read Backend Investigator Free Use License before installation. Internal use, including in commercial projects, is free; redistribution, republication and offering it as a hosted service are not permitted. Third-party dependencies retain their own licenses.

1. Install

The following public command is for use after the package is published:

npm install --global @mr.zedov/backend-investigator@1.7.0
backend-investigator --help

For an unpublished local release, install the supplied archive instead:

npm install --global /absolute/path/mr.zedov-backend-investigator-1.7.0.tgz
backend-investigator --help

Do not use sudo npm install; use a user-owned Node installation.

2. Try without production access

backend-investigator demo

This creates one isolated Loki container on a random loopback port, inserts synthetic error logs, registers a local demo project, and prints a diagnostic report. It requires an image download and leaves the container available for your AI client. Investigator does not write to production sources.

When finished:

backend-investigator demo stop

Only the owned demo container is removed. Demo configuration and history remain; the stopped source will be unavailable. Do not use this demo container as a production logging service. If an earlier demo exists, stop it before starting another; the command never replaces an existing container.

3. Connect your own project

backend-investigator setup

Run setup from the root of the intended application repository. The first choice defaults to Only this workspace; shared multi-project storage is an explicit alternative. The wizard asks for a project, environment and source. Run it again with the same scope to add a second source to the same project. It offers an explicit, bounded read-only connection test and returns errors rather than pretending registration proves access.

Loki: enter a URL reachable from the MCP process and at least one exact label, such as service=your-api and environment=production. Docker service names usually resolve only inside their Docker network. Bearer tokens require HTTPS. Multi-tenant IDs are not accepted; use the single tenant authorized for your token.

Prometheus: enter the base URL and at least one exact target scope label, such as job=application and environment=production. Labels must exist on stored series; external_labels alone do not scope local Prometheus queries. An optional bearer token requires HTTPS and is stored privately like other credentials. Scope labels cannot be __*, le or the HTTP status label. Only bearer authentication is supported; Basic Auth/Grafana Cloud Basic Auth and tenant headers are not implemented. The wizard uses common metric names; custom names are available through CLI source settings. It does not install exporters or change scraping.

PostgreSQL: enter host, port, database and a dedicated read-only role. Existing SSH tunnels can be used (for example 127.0.0.1:15432). The program does not create SSH tunnels. TLS certificate verification is enabled when you select TLS; it is never bypassed. Disable PostgreSQL TLS only if your deployment permits it, for example a verified local SSH tunnel. Grant pg_read_all_stats separately for full cross-session visibility; lack of visibility is not proof of database health. The adapter sends fixed SELECTs in read-only sessions; the role itself must still be restricted by your administrator.

Redis: enter the reachable host, port, database number, TLS setting and optional ACL username/password. Use a restricted diagnostic account. Disabling TLS requires a deployment where an unencrypted Redis connection is acceptable. Read-only slow-operation observations may be denied by your ACL; missing permissions are reported rather than treated as a healthy cache.

BullMQ: uses the same Redis connection settings plus a key prefix and an explicit list of exact queue names. The prefix must match your application's BullMQ prefix option, for example mainn-online-staging:bull; confirm how any REDIS_PREFIX variable is passed by your application. Enter queue names without that prefix (email, not mainn-online-staging:bull:email). Prefixes accept 1–100 letters, digits, underscores, periods, hyphens, colons and braces (for Redis hash tags), but not spaces or wildcards. Existing sources without a prefix still use bull. There are no job retry/removal or queue mutation tools. For CLI registration, settings are shaped as:

{
  "redis": { "host": "127.0.0.1", "port": 6379, "database": 0, "tls": false },
  "prefix": "mainn-online-staging:bull",
  "queues": ["email"]
}

Docker: enter the absolute Unix socket path and comma-separated Docker label filters, for example com.docker.compose.project=my-app,environment=staging. Filters are combined by Docker and must match actual container labels. Empty filters require explicit confirmation because they expose observations of all containers on that daemon. Socket access itself can grant host control outside this read-only adapter; workspace isolation is not an OS security boundary.

GitHub: enter the owner, repository name, exact deployment environment and optional ref filter. For private repositories, provide a token with the minimum read permissions needed for repository metadata and deployments. Public sources can omit the token. This reads deployment/release markers, not GitHub Actions logs or arbitrary repository code. No matching marker is not proof of a rollout.

Passwords are masked during entry and saved outside the package in ~/.config/backend-investigator/workspaces/<workspace-hash>/secrets.json for workspace mode, or ~/.config/backend-investigator/secrets.json for shared mode (private directory/file). They are plaintext on disk, not an encrypted vault. Protect local access and backups. Never paste passwords into chat or commit the file.

4. Connect VS Code / Copilot

In a Linux or Remote WSL VS Code window, create or open the application's .vscode/mcp.json. Workspace setup prints a configuration that launches the published npm package with @latest; it does not write this file. Merge the printed server into the existing servers object. It uses the absolute Linux Node and sibling npx paths and prepends that Node directory to the inherited PATH, so both npm and the package use Linux Node even if the client normally finds Windows tools.

The equivalent configuration is:

{
  "servers": {
    "backend-investigator": {
      "type": "stdio",
      "command": "/absolute/path/to/node-bin/node",
      "args": [
        "/absolute/path/to/node-bin/npx",
        "--yes",
        "@mr.zedov/backend-investigator@latest"
      ],
      "env": {
        "BACKEND_INVESTIGATOR_WORKSPACE": "/absolute/path/to/your/application",
        "PATH": "/absolute/path/to/node-bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Find the Linux Node directory with dirname "$(command -v node)" in the terminal where Node/npm work. npm must provide npx beside that Node executable. The example PATH includes standard Linux tools; retain other required Linux PATH entries if needed.

Each new start resolves latest through npm, subject to npm cache/network behavior, and may download and execute a newer published release. It does not update an already running MCP process, a global installation or a local checkout. Restart MCP to load a new version; refresh the agent's tools if its catalog is cached. Registry access is required for uncached downloads and fresh version checks. These npm requests are package management, not PostHog telemetry; telemetry still requires its separate consent.

For reproducible launches, replace @latest with an exact version such as @1.7.0; @^1 allows updates within major version 1 but is not a compatibility guarantee. A locally installed archive may include changes not yet published; @latest launches the public package instead of those local changes.

To keep using a global installation or local archive without package resolution, use the absolute executable path printed by command -v backend-investigator:

{
  "servers": {
    "backend-investigator": {
      "type": "stdio",
      "command": "/absolute/path/to/backend-investigator",
      "env": {
        "BACKEND_INVESTIGATOR_WORKSPACE": "/absolute/path/to/your/application"
      }
    }
  }
}

This installed-executable variant does not automatically download updates.

For a Windows extension host launching a WSL installation, use wsl.exe with absolute Linux executable paths. Discover your Node path using command -v node, and the package executable using readlink -f "$(command -v backend-investigator)" inside WSL:

{
  "servers": {
    "backend-investigator": {
      "type": "stdio",
      "command": "wsl.exe",
      "args": [
        "-d",
        "Ubuntu",
        "--exec",
        "/usr/bin/env",
        "BACKEND_INVESTIGATOR_WORKSPACE=/absolute/linux/path/to/your/application",
        "/absolute/linux/path/to/node",
        "/absolute/linux/path/to/backend-investigator.mjs"
      ]
    }
  }
}

Replace both paths with your results. No ${input:...}, password in JSON, or WSLENV password forwarding is needed. The launcher resolves the same private state from your Linux home directory regardless of working directory.

Use MCP: List Servers → backend-investigator → Start, confirm trust, then enable its tools in Copilot Agent. Other clients can use the same stdio command. If multiple clients launch separate processes, restart each after secret changes.

First ask:

List my projects and their available capabilities. Do not fetch logs yet.

Then ask:

Inspect PostgreSQL health, long queries, transactions and blocking locks for my project. Explain any missing visibility and distinguish facts from guesses.

For a specific endpoint or request ID, give the actual identifier and time range. Operation windows are at most 24 hours. General log investigations currently use the last hour and bounded samples, not aggregate counts of the entire archive.

What it can and cannot do

Source	Read-only observations
Loki	Scoped log samples, recognized errors, operation correlation
Prometheus	Scoped historical scrape availability, HTTP metrics, process resources and window comparison
PostgreSQL	Current health/sessions/locks; opt-in performance and maintenance stats
Docker	Container state, resource observations and logs
Redis / BullMQ	Cache health, slow operations, queue state and failed-job samples
GitHub	Deployment markers for comparisons with available observations

The wizard covers all seven sources above. Run it again in the same workspace to add another source without replacing existing ones. Internal demo deployment fixtures are not offered as real sources. There is no arbitrary SQL, shell execution, automatic repair, dashboard, or local log-file import. No built-in AI model is connected. Deployment comparisons require compatible actual baseline observations; missing data is never replaced with a fabricated zero baseline.

PostgreSQL activity/lock checks observe current state; they cannot prove a lock did not exist during an earlier log error. Empty samples or findings do not establish that a system is healthy. Sampling limits, unavailable sources and correlation limitations must be read with every report.

Prometheus performance review

Use inspect_metrics for a configured Prometheus source. It accepts fixed checks: availability, http, resources (all three by default), optional ISO from/to and stepSeconds. The default window is the last hour, shortened to fit stricter source/shared resource limits; explicit windows must respect those limits too. Each window is at most 24 hours with at most 21 evaluation points per metric. A smaller explicit step that exceeds this point limit is rejected, not silently truncated.

Profiles return scrape targets up/total, request rate, 5xx percentage, p95/p99 latency from a classic histogram in seconds, process CPU cores and resident memory bytes. Every selector includes the source's exact labels. current and optional baseline contain bounded points, summaries, availability, warning/info counts and limitations. Their shared scope is returned once.

Optional compareFrom and compareTo must specify an earlier, non-overlapping window of equal duration. Deltas compare sample means, not whole-window percentiles; zero baselines have no relative change and incomplete data prevents comparable deltas. An observed change is not proof of deployment causality.

Default source settings (the entire metrics object is optional):

{
  "url": "http://127.0.0.1:9090",
  "labels": { "job": "application", "environment": "production" },
  "metrics": {
    "requestsTotal": "http_requests_total",
    "durationBucket": "http_request_duration_seconds_bucket",
    "statusLabel": "code",
    "cpuSecondsTotal": "process_cpu_seconds_total",
    "residentMemoryBytes": "process_resident_memory_bytes"
  }
}

Use CLI source registration/settings files to override names for your exporter. Only names are accepted, not arbitrary PromQL. Request/CPU metrics must be counters; duration must be a classic histogram in seconds. Native histograms and summaries are not supported. CPU/memory describe the scraped process, which can be an exporter rather than the monitored database or host.

Missing metrics, labels, scrape gaps and insufficient rate/histogram samples are reported explicitly, not interpreted as zero or health. NaN/infinities become explicit unavailable/null samples. Rates use five-minute lookbacks, possibly before the requested window; bounded sparse sampling can miss short spikes. Rate estimates also depend on scrape history/cadence; complete evaluation points do not prove the underlying five-minute counter history is complete. No alerts, scrape changes, instrumentation installation or arbitrary queries are exposed.

Health/source checks collect only scrape availability. For detailed CLI review in a bound workspace, select the returned source ID:

backend-investigator cli metrics --source "$SOURCE_ID" \
  --checks availability,http,resources \
  --from 2026-10-08T10:00:00Z --to 2026-10-08T11:00:00Z \
  --compare-from 2026-10-08T09:00:00Z --compare-to 2026-10-08T10:00:00Z

Shared mode also requires --project. CLI exits 2 for partial coverage and 1 for failed inspections; registration alone is not proof of access.

PostgreSQL performance review

Ask your agent to use inspect_database with all five performanceChecks:

{
  "projectId": "<project UUID>",
  "sourceId": "<PostgreSQL source UUID>",
  "performanceChecks": [
    "query_statistics",
    "tables",
    "indexes",
    "vacuum",
    "io"
  ],
  "performanceLimit": 5
}

Without performanceChecks, the tool retains its lightweight health/activity/ locks behavior. Explicit performance checks add fixed SELECTs only:

query_statistics: optional pg_stat_statements, ordered by total execution time, with calls, execution-time summaries and block/temp-file counters. The extension must already be installed/preloaded; Investigator never installs it. Restricted roles may see hidden query text/IDs.
tables: estimated live/dead tuples, scans, changes since ANALYZE, maintenance timestamps and relation sizes, prioritizing dead tuples and modifications. Physical user tables/materialized views are sampled, not partition parents or foreign tables.
indexes: least-scanned indexes (invalid first), validity/readiness, primary/unique flags, size and bounded definitions. Zero scans do not prove an index is unnecessary. No missing-index or definitive duplicate-index detection, execution plans or EXPLAIN ANALYZE are provided.
vacuum: global autovacuum thresholds/freeze settings, database XID age, per-table overrides/counters/timestamps and oldest table XID ages, plus current pg_stat_progress_vacuum when supported. This is not a VACUUM command or a complete autovacuum scheduling prediction; progress excludes VACUUM FULL and ANALYZE.
io: database cache/block/temp/deadlock counters, size and statistics-reset time; PostgreSQL 16+ pg_stat_io samples are cluster-wide, not scoped to this database. I/O timings are meaningful only with track_io_timing. Cache-hit percentage describes shared buffers, not OS cache or disk latency.

Each optional observation reports availability and a reason for failures/ unsupported views. Advertised capabilities describe supported checks, not a guarantee that an extension or privilege is available. pg_read_all_stats is needed for full cross-session visibility, including VACUUM progress. Successful collection with track_counts=false does not make counters reliable.

Samples default to 5 rows per section, maximum 20 (or a stricter source limit). SQL/definition text is capped at 500 UTF-8 bytes or a stricter configured limit. Read sampling.truncated and sqlTruncation; request sections separately or lower performanceLimit if the MCP response-size limit is reached. Counters are cumulative, may be reset independently or evicted, and are not a recent time window. Tuple counts are estimates, not measured bloat. Queries are separate snapshots, not an atomic view of the database.

The lightweight health check skips database-size calculation by default: databaseSizeBytes: null with databaseSizeStatus: "not_requested" is not an access failure. The opt-in io.database observation calculates size or returns an explicit failure. Read-only diagnostics can still consume resources; existing connection, statement/lock and overall inspection timeouts remain enforced.

Storage, privacy and troubleshooting

CLI in the current application

After setup, run these commands from the application root or any subdirectory:

backend-investigator cli project list
backend-investigator cli source list
backend-investigator cli source test --source SOURCE_ID
backend-investigator cli investigate --strategy health

The installed package requires the cli subcommand; backend-investigator without arguments starts the stdio MCP server and waits for protocol requests. Use backend-investigator cli --help for command syntax.

CLI and secret commands discover the nearest .investigator directory by walking from the current directory toward the filesystem root. An explicit BACKEND_INVESTIGATOR_WORKSPACE takes priority. CLI uses that workspace's bound project when --project is omitted; a different project ID and storage overrides are denied. A malformed, inaccessible, symlinked or unbound nearest workspace fails closed, without trying an ancestor's state or shared storage. The secret command uses the discovered workspace's private secret file as well.

If no workspace is found, existing shared behavior remains: the installed package defaults to ~/.config/backend-investigator/, and source/investigation commands require --project ID. To work with shared storage, run from a location outside initialized workspaces and unset any explicit workspace variable.

MCP stdio launches still require explicit BACKEND_INVESTIGATOR_WORKSPACE for workspace mode; they do not auto-discover based on a client's working directory. The source checkout executable (npm run cli -- ...) keeps its historical syntax without the extra cli subcommand and its .data/ shared defaults, but also discovers workspace bindings.

Workspace configuration and history live in <workspace>/.investigator/; setup adds /.investigator/ to that workspace's .gitignore. The private binding file pins exactly one project. All MCP tools reject other project IDs, project lists are filtered, and history lists/retrieval obey the same restriction even if mixed data is present. Missing/invalid bindings or a missing bound project fail startup; no shared fallback is used. Secrets stay outside the repository.

Save the MCP connection in the application workspace .vscode/mcp.json, not the global user configuration. Remove the global connection if it has broader access. Setup prints an absolute-path launch configuration for the workspace; for a Windows host use the WSL form above. Multi-root VS Code workspaces should use separate explicitly rooted server entries, not a shared store.

Without BACKEND_INVESTIGATOR_WORKSPACE, existing shared launches keep their previous behavior and use ~/.config/backend-investigator. Do not confuse that shared mode with project isolation. For demo, leave the workspace setting unset and use its shared local store.

Advanced overrides: BACKEND_INVESTIGATOR_CONFIG, BACKEND_INVESTIGATOR_HISTORY, BACKEND_INVESTIGATOR_SECRETS_FILE. The release launcher honors existing paths; it does not migrate older .data configuration automatically. Workspace mode overrides config/history/secret paths and ignores global environment secret values. For workspace CLI or secret commands, export BACKEND_INVESTIGATOR_WORKSPACE to the same absolute root first. Workspace CLI rejects another project or storage-path overrides.

Existing projects are not automatically migrated. For the simplest migration, run setup in each application workspace and register its sources again. Do not copy a multi-project configuration or shared secret file wholesale. The old store remains unchanged until you deliberately remove it. Filesystem isolation is not enforced between processes of the same OS user; use separate users/environments for a stronger trust boundary.

Usage statistics and privacy

Usage statistics are off until explicit consent. Setup asks you to type allow or decline, with no default answer. Refusal does not limit any feature. If you skip setup, no statistics are sent; opt in later using backend-investigator telemetry enable.

Only a random installation UUID, product version and fixed events for MCP starts, connections, tool names and diagnostic outcomes are sent to PostHog EU Cloud. The UUID is pseudonymous, not a person/account identity. No tool arguments, prompts, results, source code, logs, SQL, project names or secrets are sent. OS, Node version and client metadata are not collected. There are no person profiles, final opt-out events or analytics in the remote MCP server/demo.

backend-investigator telemetry status   # local settings and installation ID; no network
backend-investigator telemetry disable  # persist opt-out; no final event
backend-investigator telemetry reset    # opt out and remove the local installation ID
export BACKEND_INVESTIGATOR_TELEMETRY=false  # force off in this process and its children

State is private and per OS user in ~/.config/backend-investigator/telemetry/state.json, outside project workspaces and npm/npx caches. Environment true does not grant consent. CI and test processes do not send statistics. Restart MCP after enabling. Events are mcp_started, mcp_connected, tool_used, diagnostic_started and diagnostic_completed. Additional fields are only fixed tool/diagnostic, origin, outcome and strategy enums, plus app_version, $process_person_profile: false and $geoip_disable: true. The installation UUID is distinct_id; PostHog assigns receipt time. No OS, Node/client metadata, arbitrary arguments, error messages or diagnostic content are properties.

PostHog documents EU storage in Frankfurt. HTTPS exposes a connection IP to the recipient; IP is not an application event property and GeoIP is disabled by request. No maximum retention period is yet guaranteed by this local release; events may remain until the operator deletes them or a configured policy expires them. A verified retention period, IP-discard settings, DPA and personless-event deletion procedure are prerequisites for public distribution.

For previously sent event deletion, save the ID shown by telemetry status and contact the distributor through the channel that supplied the package. Reset removes only the local ID, not sent events. Disabling sends no final event. Running senders check shared state before each request; no new request begins after successful disable, though in-flight traffic cannot be recalled.

The full notice is shipped as PRIVACY.md in the installed package (for a global installation, find it under npm root -g in @mr.zedov/backend-investigator). This privacy section is inline so it remains readable on npm without a broken relative file link.

Source requests and the AI client's handling of results still involve external systems. Tool results can contain production messages, query text and business/personal data. Redaction is not a guarantee that every sensitive value is removed. Check your policies before enabling tools.

backend-investigator cli project list finds your saved project IDs.
backend-investigator cli source list --project UUID lists source IDs.
backend-investigator cli source test --project UUID --source UUID checks one source.
backend-investigator cli --help lists advanced commands.
backend-investigator secret ENV_NAME saves an exported secret for references configured through the CLI; it never accepts a password as a command argument.
Use Show Output for VS Code startup/transport logs. An SDK-managed process may have separate logs. Tool errors are the primary safe source diagnostics.
Local stdio MCP writes JSON lifecycle records to stderr, never protocol stdout. Records contain a timestamp, process ID and fixed event names, with package version, startup stage or shutdown reason where relevant. They do not contain workspace paths, project/client names, credentials, tool arguments or results. These are local client-captured logs, not PostHog events; they require no telemetry consent and do not create an installation UUID or log file. local_mcp_ready means the transport is listening; local_mcp_initialized means a client completed MCP initialization. local_mcp_stopping / local_mcp_stopped distinguish stdin EOF, transport closure and SIGINT/SIGTERM. local_mcp_startup_failed identifies the startup stage; local_mcp_launch_failed covers release-entry failures before startup. local_mcp_transport_error reports a protocol/transport error without logging its potentially sensitive payload; it does not itself mean the process exited. Forced kills and crashes may leave no final record.
A running server with discovered tools in VS Code is not proof that an SDK-managed agent session received it. If the agent cannot find its tools, compare the MCP output with the Agent Host log for that session. If the server was not passed to the session, restarting the server alone may not help. Try Developer: Reload Window, start the server through MCP: List Servers, then open a new agent session. This is a recovery step, not a guarantee or a fix for client configuration synchronization.
Missing secrets, unresolved inputs, authentication rejection, network/TLS errors and insufficient privileges produce actionable errors. An authentication rejection does not reliably distinguish a wrong password from an unknown role.
Exit codes: 0 completed (findings allowed), 1 failure, 2 incomplete data.

Feedback

Record your OS, Node version, client, package version, installation step, safe error code and whether the result helped. Do not include secrets, raw logs, SQL or personal data. Send this to the distributor through the same channel that supplied the package. No public support site or issue tracker is promised yet. Useful feedback is a concrete successful investigation or reproducible installation failure, not just a download count.

Use backend-investigator --version to include the installed version in feedback.

Backend Investigator Free Use License

These terms apply to the Backend Investigator software distributed under this license.

Permission is granted, free of charge, to install and use Backend Investigator for internal development, testing, troubleshooting, observability and diagnostic purposes in projects and systems you are authorized to access.

Commercial organizations and individual developers may use Backend Investigator in commercial projects.

This license does not transfer ownership of the software or grant permission to redistribute, republish, sublicense, sell, rent, modify for redistribution, or offer Backend Investigator or a substantially derived version of it as a product or hosted service to third parties.

Backend Investigator is proprietary software and is not open source. The source repository may remain private. Distribution of compiled or packaged JavaScript does not grant any rights beyond those expressly provided by this license.

You may make copies reasonably necessary for installation, deployment, backup and permitted internal use.

You retain ownership of your source code, configuration, logs, diagnostic data and other project data. If you voluntarily provide feedback, do not include credentials, secrets, personal data or confidential production information.

You are responsible for ensuring that you have authorization to access the systems, repositories, databases, logs and infrastructure used with Backend Investigator. You are also responsible for account permissions, network security, secret management and the behavior of any AI client or model connected to the software.

Backend Investigator provides diagnostic assistance and does not guarantee the correctness of its analysis, recommendations or generated results. Review outputs before applying changes to production systems.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE SOFTWARE IS PROVIDED "AS IS" AND "AS AVAILABLE", WITHOUT WARRANTIES OF ANY KIND.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE COPYRIGHT HOLDER SHALL NOT BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, OR FOR LOSS OF DATA, PROFITS, REVENUE OR BUSINESS ARISING FROM THE INSTALLATION OR USE OF THE SOFTWARE.

Nothing in these terms excludes or limits rights or liability that cannot lawfully be excluded or limited.

Third-party dependencies are governed by their respective licenses. Their copyright notices, license terms and redistribution requirements must be respected.

Future versions, features, editions or services may be offered under different terms, including paid commercial terms. This license does not guarantee maintenance, support, future availability, continued free access to future versions or access to future functionality.