Privacy First

PECU Telemetry & Privacy

PECU is open-source software. Telemetry is optional, anonymous, and designed to help us understand how PECU is used in the real world. We collect technical information about hardware and software configurations—not about you or your data.

Quick Summary

  • Telemetry is optional and can be disabled at any time via environment variable or config file.
  • All data is anonymous and identified only by a random instance ID generated locally.
  • We never collect hostnames, IP addresses, usernames, VM names, file paths, logs, secrets, or any personally identifiable information.
  • All telemetry data is technical, aggregated, and used solely to improve PECU's compatibility, reliability, and feature priorities.
  • Data is transmitted over HTTPS with HMAC-SHA256 signature verification.

What We Collect

Instance & PECU Information

instance_id
A randomly generated identifier (32-64 hex characters) stored locally in ~/.config/pecu/instance.id. This is not a hostname, username, or hardware serial number—just a random ID to differentiate installations.
pecu_version
The version of PECU you're running (e.g., v2024.12.10).
pecu_channel
Which update channel you're using: stable, legacy, or testing.
usage_profile
A category you selected during first run, chosen from a predefined list: homelab_personal, hosting_commercial, internal_corporate, educational_lab, or other.

Operating System

Basic OS information to understand which Linux distributions and kernel versions PECU is running on:

  • os (Linux, FreeBSD, etc.)
  • arch (x86_64, aarch64, etc.)
  • kernel (kernel version string)
  • distro_id (debian, ubuntu, etc.)
  • distro_version (11, 22.04, etc.)
  • init_system (systemd, openrc, etc.)

Proxmox Environment

Details about your Proxmox VE installation to guide compatibility testing and feature development:

  • proxmox_detected: Whether Proxmox VE is installed.
  • pve_version: Proxmox VE version (e.g., 8.1).
  • pve_kernel_series: Kernel series (e.g., 6.5).
  • pve_node_name: The node name as configured in Proxmox (e.g., "pve", "node1"). This is a local identifier, not a FQDN or public hostname.
  • pve_cluster: Whether this node is part of a cluster.
  • pve_cluster_nodes: Number of nodes in the cluster (if clustered).
  • pve_qemu_count: Number of QEMU VMs.
  • pve_lxc_count: Number of LXC containers.
  • pve_storage_count: Number of storage definitions.
  • pve_subscription_mode: Repository type (no-subscription, enterprise, test, unknown).
  • pve_ha_enabled: Whether High Availability is configured.
  • rootfs_type: Root filesystem type (zfs, ext4, lvm-ext4, xfs, btrfs, etc.).

Note: We collect counts and types, not VM/container names, not storage sizes, not IP addresses or network configurations.

CPU & Memory

Hardware details to understand common deployment profiles and optimize documentation:

  • cpu_model, cpu_vendor (Intel, AMD, ARM, Other)
  • cpu_cores, cpu_threads, cpu_sockets
  • cpu_cores_per_socket, cpu_threads_per_core
  • cpu_virt_support (whether CPU supports virtualization extensions)
  • total_ram_mb, swap_total_mb, swap_used_mb

Storage: ZFS & Ceph

  • zfs_present: Whether ZFS is installed.
  • zfs_pool_count: Number of ZFS pools (not their names or sizes).
  • ceph_present: Whether Ceph is installed.

We do not collect pool names, sizes, or utilization percentages.

GPU Information

GPU hardware and passthrough configuration to improve GPU-related features and documentation:

  • gpu_count (total number of GPUs detected)
  • gpu_vendor (NVIDIA, AMD, Intel, Other)
  • gpu_model (e.g., "RTX 3080", "RX 6800")
  • gpu_nvidia_count, gpu_amd_count, gpu_intel_count
  • gpu_passthrough_detected (whether IOMMU/VFIO is configured)
  • gpu_vram_total_mb, gpu_vram_min_mb, gpu_vram_max_mb, gpu_vram_avg_mb
  • gpu_vram_known_count (how many GPUs have known VRAM values)

Feature Usage Counters

These counters track which PECU features are actually being used, helping us prioritize development and testing:

  • usage_repo_actions: Times repository management was used.
  • usage_gpu_passthrough_runs: Times GPU passthrough setup was run.
  • usage_kernel_tweaks_runs: Times kernel tweaks were applied.
  • usage_vm_templates_validate: Times VM templates were validated.
  • usage_vm_templates_apply: Times VM templates were applied.
  • usage_rollback_runs: Times configuration rollback was used.

These are cumulative counts, not logs of what you did or when.

Last Run Outcome

  • last_run_actions_total: Number of actions attempted in the last run.
  • last_run_actions_failed: Number of actions that failed.
  • last_run_last_error: A short, predefined error code (e.g., ERR_PKG_INSTALL), not free-form text or stack traces.

This helps us identify common failure modes and improve error messages and defaults.

What We Do NOT Collect

PECU telemetry is designed to be anonymous and technical. We explicitly do not collect:

  • Hostnames (FQDNs) or domain names
  • IP addresses (public or private)
  • MAC addresses
  • Usernames or email addresses
  • VM or container names
  • Configuration file contents
  • File paths or directory names
  • Disk sizes or storage utilization
  • Network configurations
  • Logs or command history
  • SSH keys, passwords, or tokens
  • Any personally identifiable information

The goal is to understand hardware profiles, Proxmox configurations, and PECU usage patterns—not to track individuals, organizations, or customers.

Why We Collect This

PECU telemetry exists for one purpose: to make PECU better for everyone. Specifically:

Understanding deployment environments

Knowing which Proxmox versions, kernel series, rootfs types (ZFS, LVM, ext4, etc.), and CPU/GPU configurations are common helps us focus testing, improve compatibility, and write better documentation.

Prioritizing feature development

The usage_* counters tell us which features are actually used. If GPU passthrough is popular but VM template validation is rarely used, we know where to invest development time.

Improving reliability

Seeing which actions fail most often (last_run_last_error) helps us improve error handling, defaults, and user-facing messages.

Planning maintenance and deprecations

Understanding which PECU versions and update channels are in use helps us decide when it's safe to deprecate old features or require newer dependencies.

All data is analyzed in aggregate. We are not profiling individual nodes or installations—we are building a picture of the PECU ecosystem as a whole.

Telemetry & Support

Telemetry is not only about statistics; it also makes support much more efficient. When you open an issue and include your Instance ID, I can correlate your report with the anonymous technical profile of your node.

How telemetry helps support

  • Shows which PECU version and channel you are running.
  • Shows Proxmox version, kernel series, and whether you are in a cluster.
  • Provides a technical summary of CPU, RAM, GPU and storage stack (ZFS/Ceph).
  • Includes feature usage counters and last run outcome to understand what failed.

With this information, I do not have to ask a long list of "What version are you on?" or "Are you using ZFS or LVM?", which reduces back-and-forth and speeds up debugging.

Your Instance ID

The Instance ID is a random identifier generated locally and stored in ~/.config/pecu/instance.id. It is also displayed in the Release Selector interface and in error footers. When you open a support request, simply copy that value into the issue.

Even with telemetry enabled, I still cannot see your data, only the technical profile of the node behind that anonymous Instance ID.

How You Stay in Control

Telemetry is optional. You decide whether to participate, and you can change your mind at any time. PECU will continue to work normally regardless of your choice.

Controlling telemetry

Environment variable

Set PECU_TELEMETRY to control telemetry behavior:

  • PECU_TELEMETRY=off or 0 or disabled: disables telemetry completely.
  • PECU_TELEMETRY=on or 1 or enabled: enables telemetry without prompts.
Configuration file

Edit ~/.config/pecu/telemetry.opt and set it to either:

  • enabled
  • disabled
First-run prompt

On first run in an interactive terminal, PECU will ask once whether to enable telemetry. The default is "Yes" if you press Enter, but you can decline by typing "no" or "n". Your choice is saved and PECU will not ask again.

Advanced control options

Inspecting the payload

You can run PECU in a verbose telemetry mode that prints the exact JSON payload before sending. This allows you to verify exactly what will be transmitted.

Firewall blocking

If you prefer, you can configure outbound firewall rules to block telemetry traffic entirely. PECU will detect the failure silently and continue operating normally.

Local builds

PECU is open-source. You can build and modify it locally, including removing telemetry code entirely if desired.

Legal & Privacy Notes

PECU telemetry is designed to be GDPR-friendly and anonymous. We do not intentionally collect personal data as defined by GDPR Article 4(1). All data is technical, non-identifying, and used solely to improve PECU.

Telemetry data is transmitted over HTTPS with HMAC-SHA256 signature verification to ensure data integrity.

Users can disable telemetry at any time without affecting PECU's functionality. If you disable telemetry, no data will be sent.

This is a good-faith commitment to transparency and privacy, not legal boilerplate. If you have questions or concerns, please open an issue on GitHub.

Frequently Asked Questions

Can you see my VMs, containers, or data?

No. We collect counts (how many VMs, how many containers) but never names, configurations, or any data stored in them.

Can you see my public IP or hostname?

No. We do not collect IP addresses, hostnames, FQDNs, or any network identifiers.

Do I have to enable telemetry?

No. Telemetry is optional. PECU works exactly the same whether telemetry is enabled or disabled.

What if I don't trust any telemetry?

That's completely reasonable. You can disable telemetry via environment variable (PECU_TELEMETRY=off), edit the config file, block telemetry traffic with a firewall, or build PECU locally and remove telemetry code. PECU is open-source—you have full control.

Why is telemetry opt-in by default?

On first run in an interactive terminal, PECU asks once and defaults to "Yes" if you press Enter. We believe the data helps improve PECU for everyone, but we respect your choice—you can decline at the prompt, or disable it later at any time.

Can I see what data you've collected about my instance?

Yes. You can request a copy of your telemetry data through the Support page. When you provide your Instance ID and email address, we will send you a JSON copy of the latest telemetry payload stored for that instance. You can also inspect the exact payload before it's sent by running PECU in verbose telemetry mode.

Built with Transparency

PECU is built by sysadmins, for sysadmins. We value transparency, privacy, and trust. If you have questions or suggestions about telemetry, please open an issue on GitHub.

Get Support View on GitHub