Ghost skill documentation
The full package includes these instructions, the Python savings calculator, feature-parity checks, migration guidance, and maintenance references.
v0.1 draft. The calculator is locally tested. The reusable migration workflow has not yet had an independent test-site rehearsal.
Assess my savings ↗--- name: killhostingbill-ghost description: Assess whether self-hosting will save a Ghost publication money, prepare and perform an authorized Ghost-to-Ghost migration with explicit feature parity, and set up ongoing maintenance. Use for replacing managed Ghost hosting or evaluating that move. WordPress, Magento, and migrations to a different CMS are outside this first version. metadata: version: "0.1.0-draft" --- # KillHostingBill Ghost Keep the publication and reduce its total cost without creating routine admin work for its owner. Staying with the current host is a successful outcome when migration does not make sense. This first draft comes from one small Ghost publication. It includes tested local cost arithmetic and operational guidance, not a generally validated unattended migration engine. Use current official tools rather than replaying commands from the original migration. ## Scope and execution Identify the publication, source host, DNS authority, destination, required features, and authorized work. An assessment or skill-drafting request authorizes no production changes. Prepare a reviewable plan before purchases, DNS cutover, subscriber sends, or cancellation. Proceed when the user has already authorized the concrete action. Do not repeatedly ask for the same permission. Use a dedicated workspace and site-specific record. Do not borrow credentials, schedules, DNS records, or files from another migration. Respect background-only browser preferences. If tools cannot operate in the background, finish independent preparation and explain the exact access gap. Read only the reference needed for the current phase: - Assessment: [savings-assessment.md](references/savings-assessment.md). - Migration planning or execution: [ghost-migration.md](references/ghost-migration.md) and [feature-parity.md](references/feature-parity.md). - Operations setup or handoff: [maintenance.md](references/maintenance.md). - Case limitations or unfamiliar workarounds: [case-lessons.md](references/case-lessons.md). ## 1. Assess fit and savings before provisioning Inventory features already enabled, not just those the owner remembers naming. Ask only about material ambiguities. Capture content, media, members, newsletters, comments, scheduling, analytics, editor tools, staff, integrations, network features, and recovery requirements. Initial execution scope is a conventional Ghost blog or informational publication with portable themes, free members, and ordinary newsletters. Paid subscriptions, high write volume, bespoke database modifications, identity or external workflow dependencies, and uncertain data portability need a separately reviewed plan. Assess them, but do not imply this draft validates their migration. WordPress and Magento remain future work. Verify actual billing and current provider prices, renewal rates, usage allowances, and taxes. Compare the full required replacement against the current setup, including email, analytics, storage, backups, agent usage, maintenance, and one-time costs. Account for nonrefundable commitments and upfront cash separately from normalized monthly costs. Do not promise savings from a headline VPS price or temporary free allowance. Use `python3 scripts/assess_savings.py assessment.json` for arithmetic, following the reference schema. Unknown costs remain unknown, never silently zero. Present first-year net savings, expected ongoing savings, a plausible usage-growth case, and remaining owner effort. Recommend moving, staying, or resolving material unknowns. Do not provision until the user has chosen a costed option. If referral links are available, disclose the relationship beside the recommendation and verify the program permits this distribution. Rank providers by user fit and total cost. No affiliate deals or tracking links are bundled with this draft. ## 2. Establish an explicit parity contract Create a feature matrix with source behavior, destination behavior, required status, test evidence, and accepted differences. Use the [parity reference](references/feature-parity.md). Native analytics, image editing, newsletter history, unsubscribe links, staff access, integrations, and backup policy must be considered explicitly. Choose the install method from required features and current Ghost documentation. Cloudflare edge services are not the Ghost origin. A basic Ghost-CLI installation does not establish native web-analytics parity. A free image editor is a substitution, not proof of identical behavior. For each row use `pending`, `verified`, `accepted difference`, or `blocked`. Mark a difference accepted only with actual user agreement. Keep missing historical data and human support visible. Do not use “full parity” when rows remain unresolved. ## 3. Prepare and rehearse away from production Follow the [migration reference](references/ghost-migration.md). Obtain complete exports and media before cancelling anything. Preserve identifiers and unsubscribe status. Keep exports and secret-bearing configuration private and out of distributable artifacts. Restore into an isolated destination with outgoing newsletters and automatic publishing disabled. Pin versions and record source and destination schemas. Reconcile content, member, media, and history records, then test required workflows. Do not replay imports on an occupied database unless duplicate handling is understood. Prepare a final-sync procedure, DNS diff, original record snapshot, TLS plan, and rollback path. A static export is inadequate when new posts, signups, or unsubscribes continue during migration. ## 4. Cut over and verify when authorized Reconfirm prepared changes and existing authorization. Execute the final snapshot and delta reconciliation, preserve unrelated DNS and mail records, activate the destination, and verify the real domain, admin, publishing, email, comments, analytics, and integrations. Keep only one system sending newsletters or publishing scheduled content. On failure, stop the failing action and inspect before retrying. If rollback is needed, account for writes since cutover. Switching DNS back alone is not a data rollback. Never import an old database over new member or publication activity without reconciliation. Cancellation is a separate action after verified cutover, restorable off-server backup, and a documented end-of-service date. Do not cancel or remove the old copy solely because DNS resolves to the destination. ## 5. Establish maintenance and handoff Follow the [maintenance reference](references/maintenance.md). Put essential backups, certificate renewal, process recovery, and health checks on always-on infrastructure. Use an external monitor for outages. An agent reviews evidence and handles exceptions, with narrow access where possible. Verify where the agent's schedules execute and whether access works without the owner's computer. Record saved/enabled schedules separately from observed successful scheduled runs. Do not promise unattended maintenance merely because a prompt was scheduled. Deliver a cost report, parity matrix, migration evidence, recovery instructions, and maintenance record in the user's workspace. Include version pins, backup frequency/retention, alert destination, update boundaries, quota checks, credential locations without secret values, and pending verification. Use `assessed`, `prepared`, `implemented`, and `verified` accurately. Keep routine successful oversight quiet unless the user asks for reports.