Start with workload and state
Use scenarios as interview cases
Think through a publishing site, an online store, a membership or course site, and a multisite network. These are prompts for discovery, not capacity classes. For each, ask which visitor requests or scheduled jobs write data; when those writes happen; which periods matter to the business; and who is reachable when a change or incident needs a decision. A brochure site and a store can differ in write sensitivity and consequences of stale data. That distinction does not establish a “sites per GB” threshold or a server size.
For example, an owner with a content site and a store should ask whether the sites share a WordPress installation, who approves plugin releases across them, and who decides what counts as the final accepted order state during a future move. Keep each answer tied to an owner statement or record. If nobody knows, write “unknown,” not a guess.
Record observations with their source and date
Use this worksheet to state what is known and how it was observed. It is an interview and evidence schema, not a test report. Do not convert a quiet observation window into a claim about other periods.
| Field | Record | Evidence source and date |
|---|---|---|
| Site count and network status | ________________ | ________________ |
| Dynamic request peaks and observation window | ________________ | ________________ |
| PHP workers or process observations | ________________ | ________________ |
| Database size, connections and change pattern | ________________ | ________________ |
| Uploads, orders, learner progress, queues | ________________ | ________________ |
| External calls, cache layers, scheduled jobs and mail | ________________ | ________________ |
| Co-resident automation or model work | ________________ | ________________ |
Mark an observation “not representative” if it misses a relevant window or job. PHP configuration limits, package labels and site counts are not substitutes for process, database and workload observations. The runtime guide starts from representative observations; return here from that guide to bring its evidence and gaps back to the path decision. For shared network governance, use the multisite and staging decision.
Turn workload into named authorities
Separate access layers
Map the provider or platform, the root-level operator, panel or WHM roles, ordinary account users, WordPress application and network administrators, and database authority separately. A control-panel menu does not prove that a person has root access, that workloads are isolated, or that the provider will execute a task. Likewise, being able to submit a request is different from having authority to approve or perform it.
Assign duties and evidence
For each important duty, record who decides, who executes, what grant or contract supports that role, who approves a change, how the result would be verified, and who can stop or reverse it. Include reboot and runtime changes, database credentials and version, plugin and custom-code changes, backup creation and deletion, DNS, and mail. Shared duties need named participants and a clear handoff.
| Duty | Decision authority | Operator / grant or contract evidence | Approval, verification and reversal owner |
|---|---|---|---|
| OS, runtime or reboot | ________ | ________ | ________ |
| WordPress code and plugin release | ________ | ________ | ________ |
| Database access and changes | ________ | ________ | ________ |
| Copy access, retention and deletion | ________ | ________ | ________ |
| Domain, DNS and mail changes | ________ | ________ | ________ |
Interview the provider about “managed”
Ask for the exact product and edition, then request a written answer for each relevant duty: included, excluded, approval-gated, or separately billable. Ask who may access root, whether custom code is in scope, how after-hours incidents are handled, and who authorizes and performs an application restore. Record the answer’s source and date. Neither a “managed” label nor a panel license answers these questions by itself.
When access grants are unclear, follow the panel guide’s role and grant map, then return with the verified authority assignments. For patching, support and incident scope, see the layer-by-layer duty decision and bring its verified owners back here.
Compare duties without naming a winner
Self-operated path
A self-operated path requires an identified operator who accepts the relevant root, operating-system patch, runtime and database, observation, recovery, and incident duties. Record that person or contracted role and how the business reaches them. Whether this path costs less or offers more flexibility depends on the actual offer and work; this page makes neither claim.
Contracted duties
A contracted path starts with named duties in an exact product’s written scope. Check edition, exclusions, escalation, approval, and restore clauses. Do not infer WordPress application support, reduced effort, response times or security outcomes from a plan name. Send the duties and billing evidence to the selected-offer worksheet for comparable offer periods; that page returns here so you can choose responsibilities before treating price as a comparison. No offer is selected in this map.
Unresolved essential work
If an essential duty has no accountable operator or no evidence that a provider accepts it, the choice is not ready. Write down the missing clause, access grant, or operator commitment and the person who will obtain it. Then pause the selection until that gap is resolved. This is a decision boundary, not a recommendation for either operating model.
Questions about panel actions go to actual panel grants; WordPress-specific co-resident work goes to the same-box boundary map. The sharing page returns here with its accepted boundary and unresolved owner. Updates and support remain with the security and support owner map.
Name state that must leave with the owner
Inventory data and custody
List WordPress files and its database as distinct items. Separately record mail, DNS, object storage, queues, external APIs, and secrets that the business depends on. For each, name the retrieval owner, the location or contract evidence, who can access and delete it, and whether its copy shares the same failure or deletion authority. A label such as “backup” or “export” does not establish the contents, access window, consistency or continued availability.
For a store receiving writes, ask who decides the final accepted order state, whether background jobs or mail continue during a future capture, and who would reconcile source and destination records. Do not presume a snapshot captures an application consistently or impose a universal maintenance window. If nobody can preserve the original state or decide whether records reconcile, stop before a move. The recovery guide maps files, database and custody; return its owners and open questions to this hub.
Set owner goals, not promises
If useful, have the business owner state recovery point and recovery time objectives (RPO and RTO) as goals. Record the person setting each goal and why it matters. Then request evidence of copy scope, access, retention and a future validation plan from the accountable provider or operator. These goals do not show that a product meets them, and no restore or recovery has been demonstrated here.
Plan exit across separate services
Leaving hosting can also depend on domain registration, DNS, mail, files, database and credentials. Identify separate account owners and written terms for each; having an export does not prove access after a contract ends. The lifecycle page separates the relevant clocks and returns access and authority gaps here. This map does not predict a cancellation date or DNS propagation time.
Keep unknowns visible
Reject convenient proxies
Site count, a PHP memory_limit, the word “unlimited,” panel control, or a package label is not a measurement of application capacity. A daytime glance can also miss scheduled work or a less frequent request peak. Preserve the observation window and its gaps; route questions about PHP processes, database behavior and cache evidence to runtime observations, then return the evidence and remaining gaps here. This hub has no sizing formula, benchmark, or buffer recommendation.
Keep product and contract questions open
Write “unknown” until a dated, exact source answers each relevant item: region and SKU; billing interval and renewal; included duties; copy scope and access; panel edition; mail service; support and escalation; and cancellation or data retrieval terms. A provider ownership page or a related article path helps identify who owns a question. It is not evidence of a particular plan’s price, inclusion, quota, support or policy. Leave each field unresolved if the selected product or contract has not been inspected.
Mail and DNS belong to a separate decision: WordPress documentation describes mail submission through a configured mail transport, but does not establish that a VPS includes a relay, mailbox, IP configuration or delivery result. Route sender-path questions to the mail owner’s inventory, and return its credential and change-owner map here. For domain and service exit, use the lifecycle route above; the general cancellation policy guide owns broader VPS stop/delete terms, while its specific applicability still needs evidence.
Preserve useful boundaries
Keep this hub focused on WordPress operating choices. It retains context for managed versus self-operated duties and costs, general backups versus snapshots, n8n and Local AI. The WordPress-specific question of co-resident data, authority, recovery and work belongs to the sharing guide, which returns its accepted boundary here. No default split or same-box recommendation follows from this page.
Route each unresolved decision
Choose the next owner by question
Use the child page that owns the unresolved detail, and bring its result back to the hub. The destinations below are contextual handoffs: each should answer a named decision rather than serve as a generic related-links list.
- Panel roles, grants or execution authority: map actual grants; return authority evidence.
- WordPress files, database, custody or migration: map state and custody; return owners and unknowns.
- PHP, database or cache observations: interpret observations; return evidence and gaps.
- WordPress alongside n8n or AI work: map WP consequences; return the accepted boundary.
- Renewal, cancellation and service clocks: separate the clocks; return access and authority.
- Mail sender, transport or DNS owner: trace the sender path; return change and credential ownership.
- Multisite or staging governance: map shared governance; return release ownership.
- Updates, support or rollback responsibility: map the duties; return verified ownership.
- Cash and optional customer-entered labor for a selected offer: compare the covered offer period; first choose duties with the responsibility framing.
Close with an owner and stop condition
Before you select a path, fill one row for each unresolved decision:
| Unknown | Evidence needed | Owner and verifier | Stop or reversal condition | Destination |
|---|---|---|---|---|
| ________ | ________ | ________ | ________ | ________ |
| ________ | ________ | ________ | ________ | ________ |
| ________ | ________ | ________ | ________ | ________ |
Verification means a named person checks the stated evidence and records what it does and does not establish. It does not mean that a host, account, restore, migration, mail flow, DNS zone or WordPress installation has been tested here. Stop selection if an essential duty, source or reversal authority is missing. A safe decision record can remain incomplete until the owner obtains it; do not silently replace a blank with a convention or zero.
Sources and scope
The responsibility and workload tables above are owner interview tools, not measured comparisons. For technical follow-up, consult the upstream material directly and confirm that its current scope still applies. These primary sources were recorded in the accepted research packet on 2026-11-06; this date is a capture date, not proof of present host or WordPress state.
- WordPress Developer Resources: Mail — describes WordPress mail submission and the mail transport boundary; it does not establish a VPS mail inclusion or delivery.
- WordPress Developer Resources: Backups — Advanced Administration Handbook — the captured page distinguishes typical site files from the database and describes a typical backup/restore order; it was last updated 2026-10-28 and captured 2026-11-06. It does not establish provider retention, custody or restore outcomes.
- PHP: Supported Versions — upstream branch lifecycle only; a host’s installed version and application compatibility require separate evidence.
- ICANN: Domain Name Renewals and Expiration — domain-registration context, not VPS cancellation or data-retention terms.
Recheck living upstream pages before publication and whenever a decision depends on current requirements. Exact product, contract, installed stack, permissions, support, copies, price, mail, DNS, and recovery evidence were not inspected for a selected provider or site. No operational test or change is represented here.
Page status: Draft — verify sources and exact-product terms before publication. Editorial source date: (America/New_York).