Skip to content

Current Scope

Jump to bottom
Nick Hamze edited this page Sep 1, 2026 · 6 revisions

Current scope

Fleet for OpenStation is an early feature-plugin preview. Its first job is to prove a useful agency workflow that also puts OpenStation on more WordPress sites.

Included now

  • One WordPress install acts as the Fleet hub.
  • OpenStation sites connect through OAuth Authorization Code with PKCE.
  • Access tokens are short-lived; refresh tokens rotate and expire.
  • Connections and encrypted credentials are stored per hub user.
  • Managed sites and hubs can both revoke OAuth grants.
  • A Core Application Password can bootstrap an OpenStation installation when OAuth is not available yet.
  • Fleet detects missing, inactive, active, and network-active OpenStation installs.
  • Fleet installs or activates OpenStation through the Core Plugins REST API.
  • A selected-site workspace stays in the current OpenStation window.
  • Dedicated views manage common content, plugin, and site-setting operations.
  • The Full API console can use any REST route available to the approved account, including plugin routes.
  • Pretty and plain WordPress REST URLs are supported.
  • Path-based multisite siblings can connect without letting the hub connect to itself.
  • The Fleet window is centered and capped at 1040 × 760 instead of opening full width.

Not included yet

  • Bulk actions across sites
  • Background jobs, schedules, or alerts
  • Backups or restores
  • Uptime monitoring
  • Security scanning
  • Site Health aggregation
  • Client reports
  • Team-shared credentials or site lists
  • Interactive sign-in to a managed site's wp-admin
  • Private-network or localhost production targets
  • A hosted control plane
  • A target-site Fleet agent
  • Dedicated polished interfaces for every Core or plugin REST route

The API console exposes what the WordPress API supports; it does not manufacture API support for features that have none.

Why this preview stays focused

WordPress Core already provides capabilities, HTTP requests, plugin installation, REST controllers, and a bootstrap credential. OpenStation adds the narrower piece Core does not provide: a Fleet-specific OAuth server with short-lived, rotating credentials.

That is enough to test the product loop:

  1. An agency installs OpenStation and Fleet on a hub.
  2. The agency connects a client site.
  3. Fleet detects that OpenStation is missing.
  4. The agency installs it with one button.
  5. The agency reconnects through OpenStation OAuth.
  6. OpenStation gains another active installation and the site becomes manageable from Fleet.

The next feature should come from observed agency pain, not from a speculative maintenance-platform checklist.

Graduation into OpenStation core

The intended long-term split is:

  • OpenStation core owns the managed-site OAuth server and, after validation, the Fleet user experience.
  • WordPress Core remains responsible for users, capabilities, safe HTTP, REST routes, and plugin operations.
  • The feature plugin remains the test boundary until the workflow is stable enough to graduate.

No compatibility promise has been made for the preview's internal storage shape or private PHP identifiers.

Clone this wiki locally