These pages describe the current Oplut website, account surfaces, CLI/runtime, device evidence sync, catalog, and planned product direction reflected in the public codebase.
Privacy posture
Oplut is local-first by design. The CLI/runtime should make hardware behavior visible on the machine where the hardware runs, then sync compact evidence only when you authenticate, upload, or use a cloud feature. The goal is useful physical visibility, not raw data collection for its own sake.
Account and authentication data
We collect account details such as name, email address, email verification status, password authentication records, account sessions, user agent, IP address, API key, plan tier, and creation/update timestamps.
If Google or GitHub sign-in is enabled and you use it, we store the provider account identifiers and tokens needed to operate sign-in through Better Auth.
Password reset emails and contact notifications may be sent through Resend or another configured email provider.
Billing data
If you purchase a paid plan, Stripe handles checkout, payment details, invoices, and subscription management. Oplut stores subscription status, plan tier, Stripe customer ID, and Stripe subscription ID so the app can enforce device limits and account access.
Inquiry and contact data
When you contact Oplut or request access, we may collect your email, name, company, role, pain summary, discovery source, request status, admin notes, and related timestamps so we can respond and manage invitations.
Device registry data
When you authenticate a device, Oplut may store device name, fingerprint, linked account, board, peripheral, OS version, architecture, model name, model revision, connected peripheral summaries, hardware profile, project label, status, service status, and last-used timestamps.
Device auth sessions include temporary device codes, user codes, device name, device fingerprint, approval status, expiration, and approval timestamps.
Dashboard jobs may store requested goals, status, output, result URLs, errors, and timing so authenticated devices and the dashboard can coordinate work.
Setup and catalog evidence
Setup workflows may sync config IDs, config hashes, setup goal, board, peripheral, OS, architecture, run ID, mode, hardware snapshot, summary, duration, failure stage, failed step, command snippets, stdout/stderr snippets, expected output, error class, service name, output URL, and result status.
Baseline, check, and health evidence
Baselines may include baseline ID, label, type, source, status, capture time, compact metrics, and metadata.
Checks may include check ID, baseline ID, status, source, observed time, changed fields, current metrics, recommendation, and metadata.
Health observations may include target, metric, value, unit, baseline value, delta, severity, message, source, observation type, status, metadata, and recorded time.
Components, calibration, and artifacts
Oplut may store component keys, component class, display name, vendor, model, revision, firmware version, driver summary, attachment summary, lifecycle status, calibration artifact type, peripheral, local path hint, metadata, evidence artifact summaries, provenance, trust status, sensitivity flags, upload opt-in flags, and capture timestamps.
What stays local by default
Raw camera frames, video, audio, full IMU logs, full sensor streams, microphone recordings, private project files, calibration image sets, and large diagnostic bundles are not uploaded by default.
Local baseline, check, health, rig, and evidence files may be written under the local Oplut configuration directory by the CLI/runtime.
Raw or sensitive artifacts should require a clear workflow and opt-in before cloud upload.
How we use data
We use collected information to operate accounts, authenticate devices, deliver setup configs, record known-good baselines, compare current hardware behavior, display dashboard history, enforce plan limits, provide support, debug failures, secure the service, improve setup reliability, and build aggregate understanding of hardware behavior over time.
Aggregation and learning
Oplut may use de-identified or aggregated evidence to learn which boards, OS versions, peripherals, config hashes, service surfaces, metrics, failure classes, and recommendations are reliable. Device reset can preserve a compact learning snapshot unless the request disables that preservation.
Sharing and processors
We share data with service providers only as needed to run Oplut, including hosting and database infrastructure, authentication support, email delivery, payment processing through Stripe, optional Google or GitHub OAuth, security tooling, and limited first-party analytics if enabled. We do not sell personal data.
Controls and deletion
You can sign out, reset your password, manage billing through Stripe, and revoke linked devices where the product exposes those controls.
Revoking a device deletes that device's linked detailed records such as health observations, baseline checks, baselines, calibration artifacts, data collection sessions, evidence artifacts, components, setup failure patterns, setup events, and the device record.
Account deletion or privacy requests can be sent to hello@oplut.com. We may retain records where needed for security, billing, legal obligations, abuse prevention, or de-identified aggregate learning.
Security
Oplut is built to keep credentials separate from reusable setup profiles and evidence records. No internet-connected service can be guaranteed perfectly secure, so avoid submitting secrets or sensitive raw artifacts unless a workflow specifically requires them.
Children
Oplut is intended for builders, teams, labs, and organizations working with hardware. It is not intended for children under 13.
The important boundary is simple: Oplut should sync compact evidence for setup, baseline, drift, health, and provenance workflows, while raw media, full sensor streams, and private project files stay local unless you explicitly choose an artifact workflow.