Platform model
Understand accounts, organizations, products, and access grants.
Lepsto organizes your work into products. Your account identifies you, an organization holds your team and billing identity, and each product holds its own resources. A grant determines who can use that product and what they can do.
Account and organization
An account is one person’s identity. The same account can belong to several organizations, but one organization is active at a time.
An organization owns products, memberships, reusable roles, its security policy, and billing identity. Organization pages use the active session context; the organization has no URL slug.
Product and deployment environment
A product is one app, store, game, or other thing you build. It has a name, a globally unique URL slug derived from that name, and its own data and grants. Products are created in eu; the region cannot currently be selected or changed.
The product itself is one access boundary. Within Deployment, environments separate services, variables, volumes, databases, and domains for production, staging, or previews. A deployment environment is not a second platform product.
Membership, grant, and role
Term | What it determines |
|---|---|
Organization membership | Which team you belong to, as an owner, admin, or member. |
Product grant | Which product you can reach, with one role and an optional expiry. |
Role | The operations allowed and denied on that product. |
Permission | A guarded operation key, matched against the role’s allow and deny patterns. |
Organization owners and admins receive concrete grants on every product in that organization. Members need an explicit share for each product. Without one, they cannot see the product. Expired or inactive grants do not provide access.
A member holds one role per product. Use a role that combines the needed permissions instead of stacking roles. A deny match overrides an allow match; no allow match means the operation is denied. See Roles and permissions.
Integrations
An integration connects an external service to the organization. Products use it through attachments, so one connection can serve several products. An unattached connection remains stored but dormant.
Provider boundaries differ. GitHub covers the installation’s repositories and ClickUp covers the authorized team. Google Drive and Google Ads provide narrower boundaries described in the integration guide. A product member can request access; an organization owner or admin decides.
Interfaces and credentials
The web app, CLI, MCP, and REST API expose platform operations with identity and permission checks. A browser session, an OAuth application credential, and an API key have different lifecycles. Signing out of the browser does not revoke the others.
A public key is different again: it authorizes selected public routes of one product, such as an embed’s endpoint. It is not a credential for managing your organization.