Data & self-hosting

Effective date: 2026-09-12

Overview

When teams use Pointer to report visual defects or request UI changes, Pointer collects only the technical element and layout context required for developers and AI agents to locate and modify code. This document details the exact data schema captured, privacy controls, storage boundaries, and self-hosted deployments.

What a comment contains

Each submitted comment generates an ElementCapture payload containing technical identifiers of the target element. Child subtrees and parent DOM trees are not included:

Each comment record also contains the comment text authored by the stakeholder, the active environment tag (local, staging, or production), the authenticated author's account identifier, and any follow-up replies.

What is never captured

Pointer is engineered specifically for UI annotations and element inspection. The following data categories are never captured by the widget or extension:

• Application cookies & session tokens — authentication cookies, session headers, and auth tokens remain untouched.
• Browser storage — your application's localStorage, sessionStorage, and IndexedDB data are never accessed.
• Request & response payloads — HTTP request bodies, response contents, and custom authorization headers are never captured.
• Keystrokes & background tracking — there is no passive event logging, session replay, form field scraping, or user activity tracking.
• Pre-click interactions & unrelated pages — nothing is transmitted before an authenticated stakeholder enters comment mode and clicks an element. One exception worth stating plainly: when a project enables Page Context Capture, the widget buffers recent console errors/warnings and failed or slow network calls locally in the browser from the moment it loads, so a bug report can include what happened just before it. That buffer never leaves the browser unless the stakeholder ticks “Report as a bug” on a comment they submit.

Opt-in extras

Two optional diagnostic capabilities exist on a strict opt-in basis:

• Element screenshots — Controlled via a checkbox on each comment. The screenshot is a high-fidelity reconstruction of what the stakeholder sees at comment time (rebuilt from the DOM, so cross-origin images and canvas/video content may differ). Can be completely disabled across the application by passing screenshot="false" to the <pointer-feedback> element.
• Bug-report diagnostic context — Available only when "Page Context Capture" is enabled in project settings and the stakeholder checks "Report as a bug". Captures recent browser console warnings/errors and failed or slow HTTP network calls (method, URL with query parameters stripped, status code, and duration; never request or response bodies or headers).

Controls & deployment guards

Engineering teams have complete control over widget activation:

• Environment guards — Restrict the widget loader behind build-time or environment variables (e.g. VITE_POINTER_ENABLED or NEXT_PUBLIC_POINTER_ENABLED) so Pointer is never mounted in public customer environments.
• Screenshot lockout — Host applications can disable screenshot capability entirely by adding screenshot="false" to the <pointer-feedback> element.
• Targeted backend URLs — The widget, CLI, and extension are thin clients that communicate only with the explicit server endpoint configured by the host application.

Where it lives: Hosted vs. Self-hosted

Pointer is designed with a strict client-server boundary, allowing organizations to run Pointer either as a managed cloud service or self-hosted entirely within their own infrastructure:

• Hosted cloud — Managed API and PostgreSQL database hosted in . TLS encryption in transit and continuous updates.
• Self-hosted — Deploy Pointer's containerized API and PostgreSQL database inside your own cloud VPC (AWS, GCP, Azure) or on-premises servers. All comments, screenshots, and metadata remain strictly within your network perimeter.

Retention & deletion

Feedback comments and projects are retained until deleted by an author or workspace administrator.

Deleting a comment or project hides it everywhere immediately. Under the hood, deleting a comment or a project is a soft delete: the records are stamped with DeletedAt and disappear from all active views, queries, APIs, and exports.

However, the underlying database rows and any uploaded screenshot files remain in storage; a screenshot file is physically deleted only when its author removes the image via edit. Physical purge of deleted records and their screenshot files (and automatic expiry after your plan's retention period) is on our roadmap; until then, contact us for a manual purge.

Plan-specific retention durations (RetentionDays) are available on request for custom enterprise configurations.

Security & workspace isolation

Pointer implements defense-in-depth security across all architectural layers:

• Credential protection — User passwords are encrypted with strong cryptographic hashing algorithms. API keys are stored hashed (SHA-256) for lookup and encrypted for display.
• Session management — Authentication relies on signed JSON Web Tokens (JWT) with a 12-hour lifetime and per-request security stamp validation.
• Database multi-tenancy — Strict database-level query filters enforce multi-tenant isolation, preventing cross-workspace data access or leakage.
• Safe AI automation — Pointer's own CLI and MCP server expose no git push capability at all; a test asserts no command they run contains it. The instructions Pointer hands your AI tool also forbid pushing. That is a strong guard, not a sandbox: an AI agent with general shell access is restrained by those instructions rather than by Pointer. Code edits happen locally and a human pushes.

Questions & resources

For security questions, privacy inquiries, or manual data purge requests, please contact moamen.ui@gmail.com.

You can also review our legal Privacy Policy or explore our technical Documentation.