Separate the application from the operating promise
Ghost's hosting guide describes the self-hosted application and the managed Ghost(Pro) service. Its comparison assigns installation, server maintenance, updates, certificates, backups and email delivery to different operating arrangements. Those are documented responsibilities. They do not establish demand for a new publication-management business. The example below is an original, hypothetical service design checked against that guide on 6 November 2026; no customer deployment or paid pilot is reported. A separate local publishing rehearsal is recorded below.
Define a deliverable someone can inspect
Imagine a publisher who already owns a Ghost publication and wants a four-week operating handoff. Offer design starts with a concrete packet: an installation inventory, an agreed maintenance window, one recovery rehearsal using disposable content, an email-delivery checklist and an escalation contact. Content strategy, subscriber growth and round-the-clock response are outside this illustrative scope. A service description saying only “we manage Ghost” leaves those boundaries unresolved.
- Updates: identify who decides when an update is applied and what would trigger a rollback. The handoff needs an owner and a record, not just an automatic-update label.
- Recovery: name the material to preserve and the authorised test destination. A backup file being present is different from a restored publication opening correctly.
- Newsletter delivery: establish which service sends mail, who owns the sender configuration and who handles a failure. Do not promise inbox placement or send test messages to real subscribers without permission.
- Support: state the staffed window and escalation route. A solo operator should not inherit an unlimited availability promise from a vendor's marketing language.
Work the operating allowance explicitly
Here is a hypothetical four-week budget. The rate is an invented value for the operator's time, not a Ghost price, quotation or measured wage. The hosting/email allowance is also an assumption, not a vendor tariff:
- Time value: $30 per hour
- Hosting/email allowance: $20
- Weekly checks: 20 minutes × 4 = 80 minutes = $40
- Recovery rehearsal: 30 minutes = $15
- Support allowance: 30 minutes = $15
- Recurring operating allowance: $20 + $40 + $15 + $15 = $90
- One-time onboarding: 2 hours × $30 = $60
- First four-week allowance including onboarding: $150
Change the support assumption before naming a price. If support takes 90 rather than 30 minutes, it adds $30 and raises the recurring allowance to $120. A four-week worksheet is not an annualised monthly quotation. Taxes, payment fees, acquisition work, extraordinary incidents and profit targets remain outside this simplified example.
Compare three ways to solve the job
A publisher comfortable operating infrastructure may retain self-hosting and buy only the missing recovery or maintenance work. Someone who wants infrastructure duties handled by a provider should compare the actual Ghost(Pro) plan and its current terms. A publication with requirements for direct database access or core modifications needs to examine which arrangement permits that work. The useful comparison is ownership of each obligation, rather than assuming the cheapest server produces the cheapest service.
Close a pilot with evidence
An eventual rehearsal should record the disposable article used, the backup and restored version, checks of images and navigation, the time spent and unresolved failures. The local publishing and restart checks below do not include a backup-restoration rehearsal. Keep the offer narrow if an important recovery dependency cannot be explained or support repeatedly exceeds its allowance. A customer's decision to pay, return or expand the scope would be separate evidence; repository popularity and a plausible spreadsheet do not provide it.
What we actually ran: a disposable publishing handoff
On November 6, 2026, we ran the existing cached Ghost 6.72.0 installation with Node 22.23.4 on a macOS arm64 workstation. We created a new development configuration, a new better-sqlite3 database and copied the bundled themes into a private test directory. The server listened only on loopback. We initialized a synthetic owner account with a random password kept in memory; no existing publication, account or database was reused.
This was an HTTP/API rehearsal, not a browser review. Mail used Ghost's stub transport. An additional guard on the owned Node process blocked non-loopback connections; it intercepted two attempts to contact static.ghost.org. No email delivery, paid membership, provider account or model call was tested. The sanitized observations JSON records the actual checks, requests and limits.
Follow one item from draft to public feed
We created an original disposable note through the Admin API's HTML input mode. Its first body contained the marker SOLO_GHOST_DRAFT_V1. Creation returned 201 and draft status. The anonymous article URL returned 404, and the RSS feed did not contain that item's slug. A separate unauthenticated request to the Admin posts endpoint returned 403. Those checks distinguish a saved editorial object from a public page.
Next we sent an edit with the returned update timestamp, a revised body marked SOLO_GHOST_PUBLISHED_V2 and published status. The update returned 200. The anonymous article then returned 200 with the revised marker and without the first draft marker. Parsing the RSS XML found the published URL and revised content. We also created a second note that remained a draft; it stayed absent from RSS.
These observations exercise this installed version's actual state transitions. They do not establish multi-editor approval, an unauthorized-user security audit or the quality of an editorial review. Ghost's HTML-input documentation notes that conversion into its editor format can change markup. We checked the meaningful content markers rather than assuming the resulting HTML would equal the input bytes.
Inspect an export, then test a controlled restart
The authenticated native content-export endpoint returned JSON with version 6.72.0 and 20 data collections. We inspected the two test records: one published note retained its revised content, and the other retained its draft state and private marker. The raw export stays private because a full content/settings export can contain more than the public article. The downloadable receipt includes only selected nonsecret observations, not an account, session, database or restore bundle.
We then stopped our own process and restarted it against the same isolated test database. The published URL and RSS item remained available, the second note remained a draft in the authenticated API, and its anonymous URL still returned 404. This demonstrates persistence across a controlled process restart. It does not demonstrate restoring from the export, recovering after disk loss, moving media or restoring a live subscriber business.
Ghost's export guidance separates content/settings, members, themes, routes and media. A service handoff therefore needs an inventory of dependencies and a genuine restore destination. This test did not reduce that obligation to a JSON download.
Read the measurements at their actual scope
The completed run passed 24 assertions and recorded 18 workflow HTTP responses, in addition to readiness polling. Fresh startup reached the setup-status endpoint in 2.342 seconds; restart reached it in 1.009 seconds. Five snapshots of the owned Node process ranged from about 235.7 to 299.9 MiB RSS. They are individual workstation observations with a tiny fixture, not peak memory, idle capacity, a Linux/MySQL benchmark or a forecast for a shared VPS.
Two earlier harness attempts failed before the complete workflow: the first lacked the local installation's package-location symlink; the second wrongly expected JSON from a successful text session response. Both are retained in the evidence history, and an overbroad intermediate PASS label was corrected. Only the completed run supports the publishing/export/restart statements. All owned processes were stopped, the private port was closed, and the existing cached publication database's fingerprint remained unchanged.
Use the test to narrow the service offer
404 Media's own FAQ states that it uses Ghost and discusses login help, email preferences, subscription cancellation and receipts. That real publication illustrates recurring support responsibilities beyond installing a CMS. It supplies no evidence about our service demand, revenue or ability to operate its business.
A defensible first offer here is narrower: prepare and inspect a draft-to-publication handoff, retain a private content export and verify a controlled restart. Before offering recovery or subscriber operations, add an authorized restore rehearsal, media checks, actual mail configuration and the relevant payment and support responsibilities. The earlier cost worksheet remains hypothetical; this local test does not turn its allowances into a quoted price or measured labor budget.
The reproduction script uses Python's standard library and an already installed Ghost version. Supply its Ghost directory, matching Node binary, a never-used working directory and an unused loopback port. It creates its own credentials, runs the checks and stops only its own process. No Ghost core module, separate publishing framework or paid integration was written.