SveltyCMS prioritizes the security of your installation. To achieve this, we use an Active Update Check system inspired by Drupal and WordPress.

1. The Security Check Mechanism

SveltyCMS does not “track” you in the traditional sense. Instead, your server periodically asks our central registry via a Secure, Hashed ID: “Attributes of this installation (Version X, Node Y). Are there any known vulnerabilities?”

The Exchange

This is a mutually beneficial exchange:

• You Get: Immediate notification of security patches, vulnerability alerts, and feature updates directly in your Admin Dashboard.
• We Get: Anonymous aggregate data (Version, DB Type, Components Used) to help us prioritize development.

How Identification Works (Privacy First)

• No IP Address Storage: We do NOT store your raw IP address. Incoming IPs are salted, hashed (SHA-256), and truncated to 16 characters on arrival. This allows us to count unique active servers without storing any traceable IP data.
• No Content Tracking: We do NOT read, inspect, or transmit database content, collections, or user credentials.
• Geolocation Anonymization: Coordinates (latitude and longitude) are rounded to 1 decimal place, offering a precision window of ~11km. This shows the general region or city while preventing the identification of specific homes or offices.

Instead, your CMS generates a unique Installation ID by hashing your private JWT_SECRET_KEY.

• We see: a3f0..., 7b29... (One-way hash).

• We NEVER see: Your actual specific key or domain ownership details unless publicly inferable.

• This ensures that if you move your site to a new server/IP, your history remains consistent, but unauthorized users cannot spoof your ID without your secret key.

• Stable Machine ID: We generate a secondary “Stable ID” based on hardware traits (OS type, Arch, Core count). This is 100% Anonymized — the raw hardware data is never transmitted.

  Instead, it is combined and hashed into a one-way fingerprint on your server, allowing us to recognize when multiple “Installation IDs” (from fresh installs) belong to the same development machine without knowing anything about the machine itself.

Data Collected

1.5 Safety & Robustness (Ghost Mode)

To ensure the telemetry service never interferes with user experience or system stability, we implement several safety layers:

• Dependency Hardening: Telemetry services now use explicit await db.ensure<Feature>() guards. They do not trigger initialization of heavyweight modules like the Content Manager; instead, they verify that the specific sub-system is READY before attempting access.

• Progressive Activation: The telemetry check is scheduled during the WARMING phase. This ensures it runs strictly in the background after the primary API is already operational.

• Connection Awareness: All external calls respect the dbAdapter connection status. If the database is not connected, cycles are skipped gracefully to prevent race conditions during early boot.

• Strict Timeouts: All external calls have mandatory timeouts (5s for Geolocation, 10s for the Heartbeat). If the server is slow, the check is skipped.

• Fail-Safe Backgrounding: Telemetry runs strictly in the background using “fire-and-forget” async patterns. It is never awaited by the main request cycle.

• Non-Fatal Failures: Hardware metric collection and network errors are wrapped in try-catch blocks. The system fails silently and logs issues as warnings rather than errors.

• Rate Limiting: Each IP address is limited to 1 check per 12 hours (enforced by client and server).

• Environment Isolation: Telemetry is automatically disabled during build processes (building flag) or in CI/CD environments.

1.7 Comparative Telemetry Landscape

SveltyCMS vs. The Monoliths (WP/Drupal)

Legacy monoliths typically lack a unified, non-blocking telemetry system. Users often rely on third-party security plugins or “site health” modules that can execute synchronous network requests, potentially slowing down the admin dashboard.

SveltyCMS specifically designs telemetry as a WARMING phase secondary task, ensuring it never competes for the critical path resource.

SveltyCMS vs. SaaS (Contentful)

In a SaaS environment like Contentful, “telemetry” is the platform’s core — every interaction is tracked, logged, and monetized internally. There is no concept of “Ghost Mode” because the user does not own the infrastructure.

SveltyCMS provides the benefits of SaaS analytics (security alerts, update notifications) while maintaining the sovereignty of a self-hosted platform, including the ability to completely sever external connections if required for highly secure air-gapped environments.

2. Privacy & Opt-Out

You retain full control. If you operate in a high-security air-gapped environment, you can disable these checks.

Environment Variable (Hard Disable)

SVELTYCMS_TELEMETRY=false

3. Server Implementation (Tech Spec)

Endpoint

• URL: https://telemetry.sveltycms.com/api/check-update
• Method: POST

Latest Payload Structure

{
  "current_version": "0.6.0",
  "node_version": "v20.10.0",
  "environment": "production",
  "is_ephemeral": false,
  "installation_id": "sha256_hash_of_secret",
  "stable_id": "sha256_hash_of_hardware_traits",
  "db_type": "mongodb",
  "location": {
    "country": "Germany",
    "country_code": "DE",
    "region": "North Rhine-Westphalia",
    "city": "Cologne",
    "latitude": 50.9375,
    "longitude": 6.9603,
    "isp": "Hetzner Online GmbH",
    "org": "Hetzner Cloud"
  },
  "metrics": {
    "users": 150,
    "collections": 12,
    "roles": 5
  },
  "system": {
    "cpu_count": 8,
    "cpu_model": "Intel(R) Core(TM) i7...",
    "total_memory_gb": 32,
    "os_type": "Linux",
    "os_arch": "x64"
  },
  "widgets": "[\"Seo\"]"
}

SveltyCMS Telemetry vs Other CMS

Your Advantages Summary

• Multi-Layer Authentication: HMAC signature (stops automated spoofing), Repository URL whitelist (only github.com/SveltyCMS/SveltyCMS), and Cached version verification.
• Zero-Latency Design: All blocking checks are in-memory; GitHub API calls run async in background; Version cache persists for 1 hour.
• Scalability: Ready for thousands of heartbeats; Rate limiting prevents abuse; Upsert logic prevents duplicate records.
• Open Source Ready: Works even though code is public; Makes spoofing require significant effort.

4. HMAC Authentication (Secure Registration Handshake)

To prevent data spoofing and ensure that only authentic SveltyCMS installations can submit telemetry, we use a Dynamic HMAC-SHA256 Handshake.

The Registration Flow

1. First Boot: On the very first telemetry check, the CMS calls /api/register on the telemetry server.
2. Secret Issuance: The server generates a Unique, Cryptographically Secure Secret (64-character hex) and returns it to the CMS.
3. Local Storage: The CMS saves this secret securely in its own database (TELEMETRY_CLIENT_SECRET).
4. Signing: Every subsequent payload is signed using this unique secret.
5. Validation: The telemetry server fetches the secret associated with the installation_id and verifies the HMAC signature.

Benefits and Resilience of this Architecture

• Anti-Spoofing: Even though the code is open-source, an attacker cannot spoof your installation’s data because they do not have your unique secret.
• No Hardcoded Salts: We’ve eliminated the “public salt” vulnerability.
• Replay Protection: All requests include a 5-minute timestamp window. Invalid or expired signatures result in a 403 Forbidden response.
• Auto-Recovery: If the signature fails (e.g. database resets causing desynchronization, returning a 403 Forbidden code), the CMS automatically purges the cached secret and invokes the handshake again to obtain a fresh one.
• Connection Diagnostics: Admins can query /api/telemetry/diagnose to run automated pings and status checks.

5. Fair Source Licensing (BSL 1.1)

This telemetry also helps us understand the “Economy” of our ecosystem to enforce our Fair Source license.

• Small Business (<$1M): Free forever.
• Enterprise (>$1M): Commercial license required.

View License Details on GitHub

Related

• Architecture Overview
• Security Overview
• State Management