4SO LabA Site needs organizational context
Organization, Project, Role and Site define access boundaries and Ownership from the start.
MANAGED WORDPRESS PLATFORM
4SO Enterprise WordPressSelf-contained WordPress PaaS
Turns WordPress from a standalone installation into a Platform Resource; Identity, Infrastructure, Storage, MySQL, Valkey, Edge, Observability, Capacity, recovery and Security sit under one Product Control Plane.
Self-containedAPI-firstMulti-tenantRecovery-ready
4SO Enterprise WordPress components: sites on managed platform services
- 1Domain & TLS edgeDomain binding, HTTPS and public edge policy as product lifecycle.
- 2Site runtimesEach Site is a resource with ownership, generation and observed health, on an RKE2 foundation.
- 3Product API + RBACKeycloak/OIDC supplies identity; product RBAC owns organization, project and site authorization.
- 4MySQLA first-class platform data service for site content.
- 5ValkeyManaged cache with its own lifecycle.
- 6Persistent storageStorage lifecycle and policy for site data.
- 7Backup & PITRBackup, PITR, clone and staging are product workflows, not emergency runbooks.
- 8ObservabilityVictoriaMetrics, Loki, Alloy and Grafana for site and platform health.
01PROBLEM & OUTCOME
Product problem
Enterprise WordPress is not a CMS; it is a platform lifecycle.
When Site, Domain, Storage, Database, Cache, Update, Security and Backup are operated with separate tools, every site becomes an operational island. This product turns them into manageable resources in a self-hosted PaaS.
Site infrastructure is part of the product
Storage, MySQL, Valkey, Edge and Observability are managed as Platform services.
Recovery should not be an emergency runbook
Backup, PITR, Clone, Staging and Resume are product-owned, traceable paths.
Updates require Preflight and Verification
Content or runtime changes are made with a clear Impact, Generation and Result.
02CAPABILITY SNAPSHOT
Capability snapshot
Every layer of a WordPress Platform, in one product model.
The focus is the site lifecycle: creation, Domain binding, capacity, Update, recovery, Security and day-to-day operations.
Site Management
Create, Suspend/Resume, Clone, Staging and the lifecycle of every Site.
Organization, Project and RBAC
User and Operator access on product-owned boundaries.
Storage Platform
Storage lifecycle and Policy for site Data and backups.
Database and Cache
Data services under the Platform lifecycle and capacity.
Domain, TLS and Edge
Domain Binding, HTTPS and Edge policy within the Site management path.
Observability and APM-lite
Health, Metrics, Logs and operations from the Site's point of view.
Capacity and Scaling
Capacity Policy and Scale decisions matched to the workload.
Recovery, Access and Security
Backup/PITR, Access grant, Security policy and Safe Update.
4SO
Panel, API and AI/MCP are not three separate decision authorities. All of them work on the same Product RBAC and Durable Operations, so no interface can bypass the lifecycle.
03PLATFORM DEPLOYMENT MODEL
Deployment model
The Production core starts at three nodes and grows as a Platform.
The WordPress runtime sits on a self-hosted Foundation; sites are built on the same Platform, and Capacity or Region expand without changing the user model.
| Profile | Foundation | Site runtime | Use |
|---|---|---|---|
| Production Core | 3 nodes | Sites on Platform Services | Enterprise baseline with infrastructure HA |
| Scale-out | Core + added nodes | Broader Site Capacity | More capacity without building a separate Platform |
| Staging / Clone | Same product authority | Separate environments for Test/recovery | Change testing, Clone and controlled transfer |
| Multi-region | Product-defined regions | Placement and Edge matched to the Region | Site distribution and recovery across multiple failure domains |
04ARCHITECTURE
Architecture
A Site is operated on top of a set of Platform Services.
The Control Plane holds Intent, RBAC and Operations; the Infrastructure, Storage, Data, Edge and recovery layers execute change, and the Site runtime shows the result.
EXPERIENCEUser / Operator / API / MCPMultiple interfaces on one product authority and Permission Model.
↓
AUTHORITYOrganization / Project / SiteRBAC, Durable Operations, Audit and Generation.
↓
PLATFORMInfrastructure · Storage · MySQL · Valkey · Edge · ObservabilityThe services beneath a Site, under the Platform's own lifecycle.
↓
SITE RUNTIMEWordPress SitesThe actual Site runtime, Domain, Health and observed state.
| Layer | Component / Plane | Responsibility | Operational behavior |
|---|---|---|---|
| Foundation | RKE2 | Self-hosted platform runtime and node lifecycle | The Platform is built and verified before any Site |
| Identity | Keycloak / OIDC + Product RBAC | Delegated identity and Organization/Project/Site authorization | The identity provider does not replace the Product permission model |
| Data Plane | MySQL + Valkey | Persistent site data and cache/session acceleration | Data services have their own lifecycle and capacity |
| Storage / Edge | Platform storage + Domain/TLS/Edge planes | Persistent content, public binding and request edge | Domain and storage are part of the Site lifecycle |
| Observability | VictoriaMetrics · Loki · Alloy · Grafana | Metrics, logs and operator visibility | Site health is built from telemetry and runtime read-back |
| Recovery | Backup · PITR · Clone · Staging | Point-in-time recovery, isolated verification and promotion | Restore is a product workflow, not an emergency command |
TECH
Install Authority. Production installation starts from a sealed artifact and operator-owned intent; before bootstrap, Remote Doctor assesses every target without mutation.
| Stage | Authority / Component | Behavior |
|---|---|---|
| Artifact admission | Trusted SHA256 + sealed release preparer | The hash is checked before extraction, and exact archive/tree parity is verified again after extraction. |
| Operator intent | Normalized install config | Node/IP/role/data-device, URLs and SSH host-key fingerprints are explicit; the installer guesses none of them. |
| Remote admission | Read-only Remote Doctor | The independent SSH fingerprint and target readiness are confirmed before bootstrap/runtime mutation; TOFU is not accepted. |
| Foundation | RKE2 → Authority/Identity → Storage | The Platform foundation is built and read back before Site services. |
| Data / Edge | MySQL → Valkey → Edge → WordPress | Data, cache and public edge are part of the same Platform lifecycle. |
| Day-2 planes | Observability → Capacity → Recovery → Access → Security | Installation is complete only when the operational planes are also available after runtime. |
| Operator handoff | Credential-free handoff metadata | The Panel/Identity URL and the owner-only credential path are handed off; no password/token is printed in the handoff or logs. |
05LIFECYCLE
Lifecycle
From Create to recovery, a Site is a live Resource.
The lifecycle covers Setup, Domain, Capacity, Update, Backup, recovery and Security, not just the initial WordPress installation.
01PreparationPreflight
02Create SiteCreate
03Domain and TLSBind
04OperationOperate
05CapacityScale
06Safe UpdateUpdate
07RecoveryRecover
08MonitoringObserve
06SITE & PLATFORM PROFILES
Operational profiles
Site, recovery and Platform each have a defined process.
Users do not need to manage Kubernetes details or the underlying services for day-to-day work.
Site OperationsDAY-2
Day-to-day work for each Site.
- Create / suspend / resume
- Domain / TLS
- Health / operations summary
Safe UpdateCONTENT & RUNTIME
Controlled change of Managed Content and the runtime.
- Preflight
- Schedule / campaign
- Verification / recovery
RecoveryPITR / CLONE
Recovery and creation of an environment separate from Production.
- Backup / PITR
- Clone
- Staging / promotion workflow
CapacitySCALE
Resource management based on Policy and Usage.
- Capacity policy
- Workload profile
- Scaling decisions
Edge & SecurityPROTECTION
The Site's public boundary and security policy.
- Domain binding
- Edge policy
- Security posture
Access & AIGOVERNED
Human and agentic access under the same RBAC.
- Access grants
- Delegated MCP
- No direct shell/SQL authority
07ACTION & WORKFLOW CONTRACT
Site flow and Durable Operation
Intent, Operation, Outbox, Audit and Observed Generation form a single chain.
A Site mutation is bound to a specific generation through an Idempotency-Key and request fingerprint; DR, Plan Migration, Runtime Transition and Recovery lifecycles can fence general Site changes.
01IntentREQUESTED
02DispatchOUTBOX PENDING
03ReconcileRUNNING
04ObserveGENERATION READ-BACK
05SuccessCOMPLETED
06FailureFAILED
07ResumeFAILED → RUNNING*
CANARY BRANCH
Safe Update with Promote / Rollback
Staging and Canary prove the change path before Cutover.
UPDATE INTENT
↓
STAGING + CANARY
↓
HEALTH
PASS?
PASS?
PROMOTE
↙ ↘
ROLLBACK
A Canary failure never reaches Cutover, and rollback authority must be valid.
RECOVERY FORK
PITR in an isolated environment
Restore first builds Clone/Staging, then Promote or Abort.
RECOVERY POINT
↓
RESTORE + REPLAY
↓
CLONE / STAGING
↓
APP
VERIFY
VERIFY
PROMOTE
↙ ↘
ABORT
Active Recovery fences overlapping lifecycles.
GENERATION LOOP
Intent ↔ Observed Generation
A Site is Ready only when generation and dependencies converge.
TARGET
GENERATION
GENERATION
→
RECONCILE
↓
READ
BACK
BACK
↑
OBSERVED
GENERATION
GENERATION
←
DATA · CACHE
EDGE · RUNTIME
EDGE · RUNTIME
Site intent stays bound to the same Durable Operation and Generation.
Missing telemetry or dependency = unknown, not Ready.
Create Site
A Site is a multi-layer resource, not just a container.
01Org / Project02Plan / Region03Storage04MySQL / Valkey05WordPress Runtime06Observed Generation
Failure / RecoveryGeneration is not considered converged until Data/Cache/Runtime are ready.
Domain + TLS
Public edge is part of the same Site's lifecycle.
01Domain Intent02Ownership / DNS03Certificate04Edge Binding05HTTPS Probe06Activate
Failure / RecoveryInvalid TLS or DNS stops activation.
Safe Update
Change is proven in staging/canary before cutover.
01Update Intent02Compatibility03Backup Checkpoint04Staging05Canary Verify06Promote
Failure / RecoveryGeneration drift or an invalid rollback fingerprint makes the operation stale.
PITR / Clone
The recovery point is first verified in an isolated environment.
01Select Point02Recovery Fence03Restore / Replay04Clone / Staging05App Verify06Promote / Abort
Failure / RecoveryRestore never reaches Promote without App Verify.
Capacity / Scale
Scale passes through telemetry and placement authority.
01Observe Load02Policy03Capacity Admit04Place05Scale Runtime06Health Read-back
Failure / RecoveryMissing telemetry means neither healthy nor a definite need to scale.
ADDITIONAL OPERATIONAL FLOWS
Additional operational flows
Migration and Site deletion must also have explicit, recoverable lifecycles.
Plan Migration
Plan or Runtime changes run with a checkpoint and a controlled cutover.
01Source / Target02Compatibility03Capacity Gate04Backup Checkpoint05Stage Target06Sync / Canary07Cutover Verify
Failure / RecoveryGeneration drift or a Canary failure triggers Block/Rollback of the operation, and Cutover never happens without Verification.
Delete Site
Deleting a Site is a destructive action with a Fence and an ordered release of dependencies.
01Exact Confirmation02Recovery Fence03Deletion Requested04Dependency Order05Release Data / Edge06Observed Deprovision07Audit Close
Failure / RecoveryActive Recovery or Migration blocks Delete; Success is recorded only after dependency Deprovision is observed.
| Action / Flow | Admission / Preconditions | Execution / Lock | Success Criterion | Failure / Recovery |
|---|---|---|---|---|
| Create / Reconcile Site | Org/Project/Plan/Region, generation and platform readiness must be valid | Site intent + Operation + Outbox + Audit are bound to one resource/generation | ObservedGeneration converges with TargetGeneration and data/cache/storage/application readiness | A failed Operation is terminal; only explicitly resumable runtime families can move Failed→Running |
| Suspend / Resume | The Site is not deleted and no DR/Recovery/Plan Migration/Runtime Transition fence is active | New generation + durable Operation + site.reconcile outbox | Observed Site state converges with the suspension intent | A conflict is rejected with 409 instead of overwriting; idempotent replay returns the same request |
| Safe Update / Runtime Transition | Valid compatibility, staging canary and rollback checkpoint/fingerprint | The target PHP/runtime transition is bound to the exact staging/backup authority | Canary/target runtime and generation verification before cutover | Drift in generation or rollback authority makes the operation stale/blocked |
| Backup / PITR | Provable recovery point and data-plane compatibility | The recovery request/operation passes through the same Product authority | Restored Site/Data and runtime health are confirmed before promotion | Active Recovery fences other overlapping lifecycles; failure has its own recovery path |
| Plan Migration | Source/Target Plan and usage/capacity admission | Requested → Reconciling → Prepared → Completed | Plan cutover only after project/site dependencies are ready | Failed can enter RollbackRequested → RollingBack → RollbackPrepared → RolledBack |
| Delete Site | confirmSiteId must equal the exact Site ID and purgeData=true; active recovery is not allowed | The Site is suspended and DeletionRequested + durable Operation/Outbox/Audit are recorded | Dependencies are released and deprovisioning is observed | A repeated Delete or an overlapping lifecycle does not overwrite; destructive intent is explicit and generation-bound |
FLOW
* Resume is not universal. Only operation types with a durable runtime generation and a defined resume owner can move from Failed back to Running; for all others, the terminal state is immutable.
08OPERATIONS CATALOG
Operations catalog
Operators work with Sites and Outcomes, not with Kubernetes components.
Instead of exposing backend entities, the Panel shows the processes needed to operate WordPress.
Run WordPress as a platform, not a collection of servers and plugins.
4SO Enterprise WordPress brings Site, Data, Edge and recovery operations together under one experience.