Openclaw Web Platform Spec

# OpenClaw Web Platform Spec

Status: Proposed  
Audience: Product, design, engineering, growth, operations  
Companions: [openclaw-v2-program-upgrade-spec.md](openclaw-v2-program-upgrade-spec.md), [openclaw-desktop-product-spec.md](openclaw-desktop-product-spec.md), [openclaw-membership-billing-spec.md](openclaw-membership-billing-spec.md)

## 1. Goal

This document defines the separate web product and cloud coordination layer that complements the local OpenClaw application.

The website should not be a marketing-only brochure. It should be a real product surface that helps users:

- discover scenario templates
- sign up and manage membership
- connect their local OpenClaw runtime
- attach cloud hosts for remote execution
- launch Manus-style tasks from the web
- review result pages, content, and automations across devices
- manage billing, teams, content assets, and integrations

Core thesis:

> The web platform is the control plane and service surface; the local OpenClaw app remains the trusted execution home; cloud hosts extend capacity and availability.

## 2. Product Positioning

### 2.1 What the website is

A hybrid product platform combining:

- public site and conversion funnel
- authenticated member console
- team and billing system
- content and template management system
- cloud orchestration panel
- artifact and automation hub

### 2.2 What the website is not

It should not force all execution into the cloud. The design must preserve local-first trust while enabling optional cloud power.

## 3. Hybrid Operating Model

OpenClaw Web should support three execution modes.

### 3.1 Local mode

- task starts from web or local
- execution runs on the user’s local machine
- web receives metadata, status, and synced artifacts only if allowed

### 3.2 Cloud mode

- task runs on a linked cloud host or managed runner
- useful for long-running jobs, scheduled tasks, browser automation, and always-on bindings

### 3.3 Hybrid mode

- planning, sensitive work, and some tool calls stay local
- heavy automation, website publishing, crawling, scheduled jobs, or remote notifications run in cloud

## 4. Strategic Value Of The Web Layer

The web platform unlocks value that a local-only app cannot provide well:

- account identity across devices
- membership and billing
- shared team workspaces
- remote artifacts and dashboards
- remote triggers and scheduled automations
- website and content publishing workflows
- cloud-based Browser Operator jobs
- centralized template discovery and update delivery

## 5. Manus-Style Experience Goals

The web platform should adopt the strong product patterns typically associated with Manus-like experiences.

### 5.1 Guided task entry

Users should start tasks through structured forms and task launchers, not only blank chat.

### 5.2 Outcome-centric result pages

Every major run should produce a web-viewable result page.

### 5.3 One-click automation handoff

Users should be able to turn outputs into recurring or triggered workflows.

### 5.4 Browser Operator as a visible capability

Research, collection, site verification, competitive scanning, and publishing checks should be packaged as product actions.

### 5.5 Email and business workflow integration

Email, docs, and SaaS updates should be presented as operational follow-through, not hidden technical plumbing.

## 6. Top-Level Product Areas

The website should include the following product surfaces.

### 6.1 Marketing site

Public pages for:

- homepage
- solution pages
- template library landing pages
- pricing
- docs/help
- case studies
- blog/content hub

### 6.2 Authenticated app

Logged-in product console for:

- dashboard
- systems
- tasks
- artifacts
- automations
- vault
- cloud hosts
- billing
- settings

### 6.3 Admin/CMS

Operational back office for:

- content management
- template publishing
- pricing and plan control
- support operations
- user health and onboarding insights

## 7. Primary Web User Journeys

### 7.1 New member journey

1. Land on product website
2. Understand template-driven value
3. Choose a plan
4. Create account
5. Download or connect local OpenClaw app
6. Create first system
7. Launch first task
8. Review first artifact

### 7.2 Existing desktop user journey

1. Sign in on web
2. Link local app
3. Import or register local systems
4. Enable optional sync and backup policies
5. Attach a cloud host if needed
6. Launch or monitor tasks from web

### 7.3 Team user journey

1. Join workspace by invite
2. View shared systems and artifacts
3. Launch approved workflows
4. Collaborate on outcomes
5. Manage role-based access

## 8. Recommended First-Class Web Templates

The web platform should feature task systems that immediately demonstrate value. Recommended launch set:

- Website Development System
- Project Development System
- Content Growth System
- One-Person Company System
- Sales Development System
- Legal Document System
- Financial Research System

The Website Development System should be a headline template because it directly supports your plan to build sites with the same product.

## 9. Website Development System Spec

This is the dedicated system template for planning, building, publishing, and iterating websites.

### 9.1 Purpose

Enable a user to go from idea to live site using local OpenClaw, web control, and optional cloud execution.

### 9.2 Inputs

- business type
- target audience
- desired pages
- brand voice
- references / competitor URLs
- required integrations
- preferred tech stack
- CMS needs
- SEO priorities
- domain and hosting status

### 9.3 Outputs

- site strategy brief
- sitemap
- wireframe text spec
- page-by-page copy
- design direction
- CMS model definition
- implementation task breakdown
- deployment plan
- SEO checklist
- post-launch optimization backlog

### 9.4 Suggested team roles

- strategist
- information architect
- copywriter
- UI planner
- implementation lead
- SEO operator
- QA reviewer
- publisher operator

### 9.5 Execution pattern

1. structured intake
2. web and competitor research
3. draft site architecture
4. generate page content and component plan
5. generate implementation work package
6. connect CMS/deployment targets
7. publish or hand off
8. monitor and iterate

### 9.6 Result page requirements

Each site project should produce a result page with:

- project summary
- sitemap
- page briefs
- copy blocks
- brand notes
- implementation repository links
- CMS model overview
- deployment status
- next-step automation actions

## 10. Membership System

The web platform must include a full membership system.

Detailed membership tiers, pricing, recharge wallet, model multipliers, and web/client execution rules are defined in [openclaw-membership-billing-spec.md](openclaw-membership-billing-spec.md).

### 10.1 Account model

Support:

- email/password
- OAuth providers
- magic link
- optional enterprise SSO later

### 10.2 User states

- anonymous
- registered
- verified
- active subscriber
- paused subscriber
- admin/operator

### 10.3 Plan types

Suggested initial plans:

- Free
- Pro
- Team
- Business
- Enterprise

### 10.4 Plan controls

Plans may limit or meter:

- number of systems
- number of cloud jobs
- Browser Operator runs
- artifact storage
- Vault retention
- team members
- premium templates
- premium integrations

## 11. Billing And Subscription Requirements

The website should support:

The detailed package matrix, daily quota model, top-up strategy, and billing APIs are defined in [openclaw-membership-billing-spec.md](openclaw-membership-billing-spec.md).

- monthly and yearly billing
- usage-aware overage rules where needed
- invoice history
- payment method management
- upgrade / downgrade / cancel flows
- coupon and trial support
- workspace-level billing ownership

## 12. Content Management System Requirements

The website needs a real CMS layer, not hardcoded pages only.

### 12.1 CMS-managed content types

- landing pages
- template detail pages
- docs pages
- blog posts
- case studies
- release notes
- pricing copy
- onboarding announcements
- in-app education modules

### 12.2 CMS goals

- non-engineers can update marketing and educational content
- template metadata can be published consistently
- SEO pages can be scaled quickly
- multilingual support can be added later

## 13. Desktop-Link And Local Bridge

The website must work with the user’s local computer in a safe and explicit way.

### 13.1 Local bridge concept

A local OpenClaw bridge process should let the web console talk to the user’s machine through authenticated, permissioned channels.

### 13.2 Bridge responsibilities

- device registration
- secure session establishment
- status reporting
- job dispatch approval
- artifact sync
- Vault policy sync
- cloud/local routing selection

### 13.3 User controls

Users must be able to choose:

- which systems are linked to web
- what data is synced
- whether tasks may be launched remotely
- whether cloud jobs may read local snapshots or artifacts

## 14. Cloud Host Integration

The product should support user-owned cloud hosts and managed cloud runners.

### 14.1 Supported modes

- self-hosted VM
- managed cloud worker
- dedicated organization runner

### 14.2 Cloud host responsibilities

- long-running automations
- scheduled jobs
- always-on bindings
- remote browser tasks
- website publishing pipelines
- external webhook handling

### 14.3 Cloud host health data

Expose:

- online/offline status
- queue depth
- resource utilization
- last heartbeat
- assigned systems
- failure logs

## 15. System Vault On The Web

The web console should expose Vault capabilities without forcing remote ownership.

### 15.1 Web Vault features

- browse snapshots
- compare versions
- restore request initiation
- clone request initiation
- branch visualization
- backup policy settings
- retention policy controls

### 15.2 Ownership principle

If local-only mode is enabled, snapshot data may remain local and the web stores metadata only.

## 16. Artifact And Result Center

Artifacts should be a first-class web object.

### 16.1 Artifact types

- task result page
- website delivery package
- content pack
- research memo
- contract draft
- code delivery summary
- automation report

### 16.2 Artifact actions

- view
- export
- share
- comment
- continue task from artifact
- convert to automation
- pin as team reference

## 17. Automation Center

The website should offer an automation console.

### 17.1 Automation types

- scheduled runs
- trigger-based runs
- inbound channel runs
- Browser Operator runs
- publish/update actions
- email workflows
- SaaS sync actions

### 17.2 Automation controls

- enable/disable
- inspect logs
- retry
- edit parameters
- choose local or cloud execution target

## 18. Channel And SaaS Integrations

The web product should manage integration setup for:

- Telegram
- Feishu
- QQ
- Email
- Slack
- Notion
- Google Drive
- Google Sheets
- CMS and publishing systems
- CRM systems

Principle:

The website manages visibility, onboarding, and policy. Execution may still happen locally or in cloud depending on the selected routing mode.

## 19. Roles And Permissions

The website needs role-aware workspace access.

Suggested roles:

- owner
- admin
- operator
- editor
- viewer
- billing_admin

Permissions should cover:

- system management
- cloud host management
- vault restore rights
- billing access
- artifact sharing
- automation editing
- integration configuration

## 20. Security And Trust Model

### 20.1 Security requirements

- explicit device linking
- encrypted tokens and secrets
- role-based access
- per-system visibility controls
- audit logs for restore, clone, publish, and automation changes
- revocable device and cloud host sessions

### 20.2 Data residency posture

Support clear separation between:

- local-only data
- synced metadata
- synced artifact content
- cloud-executed workflow state

## 21. Web Information Architecture

Suggested routes and product areas:

- `/`
- `/solutions`
- `/templates`
- `/pricing`
- `/docs`
- `/blog`
- `/login`
- `/signup`
- `/app`
- `/app/dashboard`
- `/app/systems`
- `/app/systems/:id`
- `/app/tasks`
- `/app/artifacts`
- `/app/automations`
- `/app/vault`
- `/app/cloud-hosts`
- `/app/integrations`
- `/app/team`
- `/app/billing`
- `/app/settings`
- `/admin`

## 22. Recommended Technical Shape

This document is product-focused, but the website likely needs these major services:

- web frontend
- auth service
- billing service
- CMS/content service
- workspace and system metadata service
- artifact index service
- automation orchestration service
- cloud host registry
- local bridge gateway
- audit and notification service

## 23. Rollout Plan

### Phase 1: Public site and account shell

Deliver:

- homepage
- template library landing pages
- pricing
- auth
- basic member dashboard
- local app linking

### Phase 2: System and artifact console

Deliver:

- systems list
- artifact center
- basic Vault metadata
- Website Development System launch flow

### Phase 3: Cloud and automation

Deliver:

- cloud host linking
- scheduled jobs
- Browser Operator jobs
- email workflows
- publish integrations

### Phase 4: Team and CMS maturity

Deliver:

- team roles
- content management back office
- collaboration features
- deeper billing controls

### Phase 5: Marketplace and ecosystem

Deliver:

- premium template marketplace
- integration marketplace
- partner publishing flows

## 24. Acceptance Criteria

This web platform spec is complete enough for planning when it defines:

- a separate but connected web product
- local + web + cloud hybrid execution
- membership and billing requirements
- CMS requirements
- website-development template behavior
- artifact, automation, and Vault web surfaces
- roles, permissions, and security expectations

## 25. Immediate Follow-Up Docs

Recommended next documents:

1. web technical architecture spec
2. local bridge protocol spec
3. billing and plan matrix
4. CMS content model spec
5. Website Development System detailed workflow spec