How Skene fits into your stack
This page explains where Skene runs, how it connects to your repositories and apps, and how data flows from your codebase into the embeddable onboarding widget.
Where Skene runs
Skene has two main parts: a managed control plane you log into, and your own environment where your code and applications live.
Skene control plane
A multi-tenant dashboard built on Next.js 15 and Supabase where you create workspaces, connect repositories as sources, review AI-generated milestones and lifecycles, and manage API keys for the widget.
Your environment
Your Git repositories, CI/CD, apps, and docs. Skene connects to these via read-only repo access and a single embeddable JavaScript widget that you add to your product or docs.
How Skene connects to your stack
Skene links to GitHub (and later GitLab and Bitbucket) using read-only authorization on the repositories you choose, so it can inspect your code, configuration, and docs.
No additional SDK or product beacon is required to start an evaluation; Skene works directly from your code, APIs, configurations, and docs.
From repository to onboarding widget
Skene is wired as a pipeline from your repositories into an in-product onboarding widget, so the same understanding of your code drives both the dashboard and the end-user experience.
You connect a repository as a source inside a workspace.
Background jobs send that source to the Skene Agent API, which analyses your code, APIs, and docs to propose onboarding milestones.
In the dashboard you review and approve milestones, and Skene groups them into lifecycles like "Getting Started" or "Advanced usage".
Skene generates a widget configuration (JSON) from those lifecycles and marks the source as published.
Your team (or your customer) embeds a single JavaScript snippet in the app or docs. That widget pulls the published configuration and renders the onboarding checklist for end users.
Multi-tenant workspaces and data model
Skene is multi-tenant by design. Each workspace is its own tenant that contains sites, sources, lifecycles, milestones, API keys, and widget events, all stored in a Postgres database with row-level security.
Workspace
The top-level container for a customer or environment, with members and roles like owner and member.
Sites & Sources
Sites group related surfaces (e.g., marketing site and main app). Sources represent connected repositories.
Lifecycles & Milestones
Model the onboarding and lifecycle journeys. Widget events capture how end users move through those journeys.
Embeddable widget and event tracking
The Skene widget is a framework-agnostic JavaScript file served from the dashboard. You embed it on any site with a single script tag that includes an API key and a source identifier.
On load, the widget detects the dashboard URL and calls a widget configuration API using your workspace API key and source ID.
It renders a floating onboarding checklist for end users and tracks events like first session, page visits, and checklist interactions.
You can keep users anonymous or call a public identify method in the widget to attach your own user IDs and traits.
Security and data boundaries
The architecture is designed to keep customer data isolated and to limit how repository and widget data are used.
Repository access
Read-only and scoped to the repositories you explicitly connect; you can revoke it at any time.
Workspace isolation
Enforced by row-level security policies in Postgres so one workspace cannot see another's data.
Widget APIs
Only return configuration for published sources with a valid, active API key and matching origin.
Questions about the architecture?
Explore security details or see how it all works in practice.