Know what runs in your browser, what leaves it, and what SHVL keeps.
Installed workflows only feel safe if the boundary is clear. This page explains the current SHVL setup in plain English: public pages on Cloudflare, product services on Supabase, workflow execution across connected apps and cloud services, and Plausible plus Ahrefs Web Analytics telemetry on the public funnel.
SHVL is not local-only today, and we do not claim it is. The site runs in the browser, workflow requests can call SHVL backend services, and some workflows use third-party app or model providers. The trust standard here is explicit boundaries, minimal retention, and no surprise reuse of your working content.
Runs in your browser
The public site renders in the browser first. A few small pieces of state stay there so the interface works properly.
- Theme preference is stored locally so light or dark mode persists between visits.
- Signed-in pages rely on browser-side session state through the Supabase client.
- Interface actions like opening pages, clicking CTAs, and submitting forms start in the browser before anything is sent elsewhere.
Leaves the browser
When SHVL has to do real work, the browser sends data to SHVL services or the connected tools involved in the workflow.
- Demo requests, sign-in actions, and product actions are sent to Supabase-backed services.
- Workflow execution can call SHVL backend services plus the connected apps needed for the job.
- Some workflows may use third-party connector or model providers where the workflow requires them.
Workflows run across your apps, SHVL services, and the tools the workflow needs.
Your source systems stay where the real business content lives. SHVL sits in the middle to orchestrate the repetitive work rather than trying to become a second archive of record.
- Connected systems like Gmail, Outlook, Sheets, Excel, Slack, and similar tools remain the source of truth.
- SHVL uses cloud services to authenticate, orchestrate workflow steps, and keep operational state like run status and configuration.
- If a workflow uses an external connector or model provider, that should be because the workflow needs it to complete the task, not because we want to quietly broaden the data path.
We track product signals, not the body of your work.
Public marketing pages load js/analytics.js for selected SHVL funnel events and a small Ahrefs Web Analytics tag for page-level measurement. Together they cover page views plus selected conversion events such as checkout clicks, demo requests, and workflow install intent.
- The current public-site analytics posture is product telemetry, not an ad-pixel stack.
- The public funnel no longer posts analytics events to the old shared CompeteDesk endpoint.
- Theme preference is stored in local browser storage.
- If you sign in, browser-side auth state is also maintained so protected pages can work normally.
What this page is and is not claiming.
This page is here to make the boundary legible. It is not a substitute for a formal certification or legal review.
- SHVL is not claiming local-only processing today.
- SHVL is not claiming ISO, EN, BS, or SOC certification on the strength of this page alone.
- SHVL is aiming for content-light telemetry and narrow retention, not pretending that cloud execution means no data processing happened.
Need the workflow, not a black box?
Tell us the repetitive work you want handled first and we can shape the workflow around a boundary you can actually understand.
Related pages: Privacy, Cookies & storage, Terms, and Accessibility.