Managed cloud beta
OwlEye is preparing a public hosted Free beta targeted for Tuesday, 11 August 2026 at 12:00
Asia/Kolkata, reachable through the dashboard link on owleye.dev. It is not general
availability. The date is a release target, not a promise that an unchecked safety or privacy gate
will be waived.
When that launch gate passes, anyone can create a Free account—there is no invitation list or waitlist. Abuse controls can still reject automated floods, disposable addresses, and plus-address aliases; that is signup hygiene, not an invite gate.
One hosted product
Section titled “One hosted product”This service has no runtime edition flag. Loopback HTTP and logged OTP delivery are developer conveniences only. A non-loopback API listener fails startup without hosted production safeguards, and tier retention is always stamped and reconciled by the service.
The managed release requires canonical HTTPS, secure cookies for the authenticated console, real SMTP delivery, production Google OAuth, private or TLS-protected ClickHouse, durable SQLite, encrypted tested backups, secret management, readiness probes, migrations, monitoring, and an on-call incident path. The public analytics SDK remains cookie-free; console authentication is a different surface and uses secure HttpOnly cookies.
Proposed beta retention
Section titled “Proposed beta retention”These periods use calendar months. Active data is queryable normally. Post-active grace removes data from normal analytics but delays purge eligibility. Paid grace includes a controlled owner export; the one-time Free grace does not provide an archive or ordinary export.
| Cloud tier | Active analytics | Post-active grace | Purge eligibility |
|---|---|---|---|
| Free | 3 calendar months | One inactive month before the account/site subject’s first purge; no archive/export feature | First purge at month 4; later data at month 3 |
| Pro | 18 calendar months | 1 calendar month with owner export | Month 19 |
| Business | 18 calendar months | 1 calendar month with owner export | Month 19 |
| Custom | 36 calendar months | 2 calendar months with owner export | Month 38 |
The Free grace happens once per customer account; a legacy standalone site is the fallback subject. It does not restart after inactivity, creating or renaming another site, upgrading, or downgrading. Free has no user-facing backup or archive product. A legally required access export remains available regardless of plan.
Upgrades can extend facts that still exist but cannot resurrect purged data. A downgrade applies the shorter tier to new facts after the paid entitlement ends; it does not silently shorten dates already stamped on older facts.
Tuesday reconciliation
Section titled “Tuesday reconciliation”Tier retention is reconciled every Tuesday at 12:00 Asia/Kolkata. A row can therefore wait up to seven additional days before eligible purge work is enqueued. Physical ClickHouse deletion is asynchronous and must be verified separately; “up to seven days” describes the normal scheduling lag, not an unbounded deletion-completion promise.
On launch day, the scheduler must still claim and record its expected empty/new-data run at noon. The production deploy and smoke tests happen before that boundary, not at the same instant. The first normal data-bearing weekly review after launch is Tuesday, 18 August 2026 at noon IST.
The service must deduplicate upcoming-cutoff notices, durably enqueue purge work, verify ClickHouse mutations, and retain minimal completion evidence. Customers should receive one useful cutoff notice or digest, not the same warning every week.
A verified erasure request overrides the tier, grace period, and Tuesday schedule. A narrow, documented legal hold can delay only the data counsel identifies. Access and portability requests are rights workflows, not paid backup features.
Email and disaster recovery are different things
Section titled “Email and disaster recovery are different things”A retention email is metadata-only notification. It contains no analytics attachment and is not an export or backup.
OwlEye can keep short-lived encrypted internal disaster-recovery backups even where a tier has no user-facing archive. Those backups are inaccessible through normal analytics, have restricted operator access and a documented expiry, and must replay erasure and retention tombstones after a restore before service resumes.
Current readiness boundary
Section titled “Current readiness boundary”The codebase now includes cloud policy stamping, active-window query filtering, Tuesday run claims, durable retention jobs, a deduplicated notice outbox, bounded ClickHouse deletion paths, completion evidence, priority site erasure, readiness health, and focused tests. Code presence is not production proof.
Before cloud tier retention can be promised, the deployed environment still has to prove the exact migrations and calendar cutoffs, one-time account grace, SMTP delivery and retry, end-to-end purge completion, in-flight-ingestion handling around deletion, restore-and-tombstone replay, alerts, and an operator-observed Tuesday reconciliation. That evidence must identify the tested revision.
Until that proof and the final go/no-go are recorded, this page describes the beta contract—not an available SLA or a compliance certification. Read privacy and compliance readiness for the operator and customer responsibilities that technology cannot replace.