Plain language. No disappearing clauses.

1. Scope and roles

This notice covers bridgesllm.ai, downloads served from that domain, the limited operational telemetry that an Owner can control in BridgesLLM Portal, and the installer’s limited install and update lifecycle events.

A Portal installation runs on a server chosen and operated by its owner. That operator controls Portal accounts, files, projects, apps, connected providers, optional public shares, mail, Remote Desktop, backups, and retention on that host. BridgesLLM does not become the controller of everything stored on a self-hosted installation merely because the software was downloaded.

If an organization or another person gave you access to their Portal, ask that operator about their policies. They control that installation.

2. The public website

What the site deliberately collects

The static marketing pages do not embed advertising pixels, behavior analytics, third-party fonts, session-replay tools, or cross-site tracking scripts. The site does not create a marketing account or ask for a newsletter address.

Standard server records

Like a normal web server, the infrastructure serving this site and its downloads can receive request metadata such as IP address, date and time, requested path, response status, user agent, referrer, and transfer size. These records may be used for security, reliability, abuse prevention, and aggregate operational review.

This paragraph is about visitors to bridgesllm.ai — people reading these pages or downloading the installer. It is a separate matter from a running Portal, which is covered in section 4. Visiting this website and operating a Portal are not linked to one another.

GitHub, X, and any other external destination linked from this site receive requests under their own policies when you follow those links.

3. Data on a self-hosted Portal

Portal accounts, local configuration, files, projects, app sources, database records, agent transcripts, credentials, and service data are stored on the operator’s host or in services the operator connects. BridgesLLM does not receive that content through the telemetry channels described below.

Self-hosting does not mean every action stays on one machine. A prompt sent to an external AI provider leaves the Portal host. Pulling source, installing packages, fetching a webpage, sending mail, sharing an app publicly, or connecting a remote model also communicates with another system selected or enabled by the operator.

4. Portal telemetry and installer lifecycle events

What BridgesLLM cannot see

The people who use your Portal never contact BridgesLLM. Their browsers talk to your server, and the conversation ends there. BridgesLLM does not receive, and has no mechanism to request, any of the following:

• Who signs in to your Portal, or when, or from where.
• The addresses, devices, locations, or session activity of your Portal's users.
• Usernames, email addresses, passwords, or provider credentials.
• Prompts, chat messages, tool arguments, file contents, project or app content, or command output.

There is no sign-in feed, no per-user reporting, and no way to reconstruct one from what is sent. A Portal reports on itself, not on the people using it.

Why this information is kept at all

The reports exist to keep the software working, and they are used for three things:

• Catching abuse. Distinguishing normal installs from a host hammering the release and download endpoints.
• Sizing the infrastructure. Knowing the real load on downloads and updates so installs stay fast and finish cleanly.
• Knowing what is still running. Understanding which Portal versions remain in the field, so the installer keeps covering the upgrade paths people actually need instead of dropping one that is still in use.

These are the current uses. If BridgesLLM ever wanted to use this information for another purpose, that would be a change published in this notice and in the release documentation — not a silent expansion.

The Portal operational report

Fresh Portal setup enables operational telemetry by default. The Owner can turn it off during setup or later in Portal settings. An update retains the installation’s existing saved choice instead of silently changing it.

When enabled, Portal sends the following limited fields shortly after startup and then about every 24 hours while it remains running:

The Portal operational report does not include prompts, chat messages, tool arguments, project or app content, file contents, credentials, usernames, email addresses, provider tokens, or host command output.

Disabling the Portal operational report stops that report only. When an Owner opens Dashboard, Portal separately checks the version endpoint for update availability; an Owner can also request a manual refresh. Those version lookups send no operational telemetry payload. Like any web request, the endpoint still records ordinary server metadata — the time, the requested path, the user agent, and the address the request came from, which is your Portal's server rather than any person's browser.

Installer lifecycle events

Separately, the installer sends limited install and update lifecycle events regardless of the Portal telemetry setting. Each event contains only the event type, Portal version, operating-system name and version, and a random installation ID. The Portal telemetry switch does not disable these installer events.

5. Other network requests are not telemetry

Turning off operational telemetry does not turn an internet-connected server into an offline machine. The following requests can still occur when the operator asks for or enables the related action:

• the separate Portal version check when an Owner opens Dashboard or requests a manual refresh;
• installer, update artifact, operating-system, package, container-image, Git, or skill downloads;
• AI provider, OAuth, API, model, or remote-runtime requests;
• web browsing, public egress from a qualified Project runtime, and agent tools;
• DNS, certificate, mail, public app, share-link, and Remote Desktop traffic; and
• normal time, logging, monitoring, or security services configured by the host operator.

Each receiving service can observe standard request metadata and whatever content the operator intentionally sends to it.

6. AI providers, local models, and authentication

Portal does not include universal AI model access. Operators connect provider accounts, API keys, compatible command-line subscriptions, or local and remote model runtimes. Authentication methods vary by provider: some use browser OAuth, some use a device flow or provider CLI, and some use API keys or local credentials.

External providers process prompts, files, tool context, and generated responses under their own terms and privacy policies. A local model can reduce external provider traffic, but remote GPU networking, model downloads, and any tools used by that model still follow the operator’s configuration.

7. Public and optional features

Public app links, share links, mail protocols, custom domains, and similar features are intentionally reachable when enabled. Passwords, expiry, or use limits can narrow access, but they do not make published content private in every circumstance. The operator decides what to expose and remains responsible for removing access when it is no longer needed.

Remote Desktop exposes a powerful workstation surface to authenticated Portal users. Project runtime isolation depends on compatible host capabilities and correct configuration. Neither should be presented as a substitute for careful access control, patching, and backups.

8. Security and retention

BridgesLLM uses measures appropriate to a small public software distribution site, including HTTPS, signed release artifacts, access controls, and limited operational logging. No security measure removes all risk.

Website and telemetry records are retained only as reasonably needed for security, reliability, release compatibility, abuse response, and legal obligations, then deleted or aggregated when they are no longer needed for those purposes.

Retention on a self-hosted Portal is controlled by the operator’s database, files, backups, provider settings, and host policies. Uninstalling cannot discover a copy that was moved outside the recorded managed paths before removal.

9. Choices and rights

• Turn the Portal operational report off during fresh setup, or change it later in Portal settings.
• Understand that the installer’s limited install and update lifecycle events are independent of the Portal telemetry setting.
• Understand that Owner-Dashboard version checks remain separate when the operational report is disabled.
• Choose which external providers, tools, public services, and remote model hosts to connect.
• Ask the operator of a Portal you use about access, correction, export, or deletion of data on that host.
• Contact BridgesLLM about website or telemetry records that may relate to you. Verification may be required, and applicable legal exceptions can apply.

10. Changes and contact

This notice can change when the website, telemetry, or legal obligations change. The effective date at the top identifies the current version. Material changes should be reflected in the public release documentation rather than hidden in silent copy edits.

For privacy questions, open a request through the official BridgesLLM Portal repository. Do not place credentials, private host details, personal data, or security vulnerabilities in a public issue. Use the repository’s security policy for vulnerability reporting.