Product requirements
This document defines what the self-hosted OrbitPage application must support. Use it to assess a feature or regression; installation and editing instructions belong in the linked
This document defines what the self-hosted OrbitPage application must support. Use it to assess a feature or regression; installation and editing instructions belong in the linked guides. It describes the current product, not a roadmap.
Goal
Anyone can create and maintain a public page without writing code, regardless of their job or intended use. The owner runs the application on their own server and controls its content, data, and access.
An installation serves a main page, optional additional pages, a menu and an optional shop. It works without an OrbitPage SaaS account or cloud database.
Required behavior
| Area | Expected result | Guide |
|---|---|---|
| Setup | Browser setup checks the instance, creates the first administrator, and opens the dashboard | Deployment |
| Visual editing | Saved profile, blocks, layouts, and theme survive reload and render on the public page | Content and design |
| Public destinations | Enabled menus and published additional pages resolve at their URLs; hidden content stays private | Dashboard |
| Sharing and discovery | QR codes, scheduled campaign links, metadata, sitemap, and text files use the configured public URL | Publishing, SEO |
| Analytics and consent | Visit details and third-party tracking follow consent; reports are available in the dashboard | Analytics and privacy |
| Newsletter | The owner can configure SMTP, verify it, manage confirmed subscribers, and send or schedule campaigns | Newsletters |
| Shop | Shared catalog/editor, private digital delivery, services, orders and customers use owner Stripe, SQLite and local SMTP without an OrbitPage fee | Shop |
| AI editing | With an optional provider key, the assistant proposes changes and applies them only after confirmation | AI assistant |
| Accounts | Roles restrict reads and changes on the server; each user can manage their password and TOTP | Account and team |
| Automation | Personal API tokens have limited access and expiry and can be revoked | API |
| Recovery | Data and secrets survive updates; exports, version history, infrastructure backups, and admin recovery have documented procedures | Backups, Maintenance, Recovery |
Requirements across features
- Support keyboard controls, visible focus, phone and desktop layouts, and reduced motion.
- Use the same page schema and renderer for preview and the public page.
- Validate input and permissions on the server. Public responses must not expose drafts, account details, secrets, or editing metadata.
- Preserve existing SQLite data, supported backup formats, and documented URL aliases during upgrades.
- Translate dashboard controls without changing saved page content. Public URLs have no dashboard-language prefix.
- Keep external providers optional: normal editing works without AI, GA4, or SMTP.
The OSS edition has no paid feature tiers or plan quotas for pages and blocks. Storage and request limits still apply. Hosted billing, tenants, managed storage, moderation, Stripe Connect platform policy and custom-domain provisioning belong to the managed service. Owner commerce belongs to the self-hosted application.
For implementation details, see Application, Architecture, and Design system.