1 Executive Summary

HomeTown Social is a hyper-local community platform combining a social network, six local news publications, a marketplace, events, a member CRM (the Growth Desk), and an Academy. This guide explains — in plain language — exactly how the platform is built, where every piece lives, what could go wrong, and precisely how to recover it if any single provider fails.

The key message is reassuring: HomeTown Social is built on a resilient, decoupled architecture. The website's core data does not live with the company that serves the web page. No single provider going offline can destroy the platform or its data. The most important asset — our members, their content, and our business data — is stored independently and can be reconnected to a new host quickly.

2 How HomeTown Social Is Built

The platform is made of three independent layers, each from a different company. Think of a business: the storefront (where customers walk in), the warehouse (where inventory is kept), and the road network (how goods move between them). If the storefront's landlord has a problem, the warehouse and its inventory are untouched.

Current Hosting

The application file is currently served through Ghost, via the managed Ghost host Midnight. Ghost also powers our news/blog publishing and provides the news feeds (RSS) that flow into the six news channels. So Ghost plays two roles: it serves the app file, and it is the content engine behind the news portals.

Supporting Services

• Domain name: hometownsocial.ca — controlled at the registrar and pointed via DNS (managed through Cloudflare).
• Cloudflare: runs the Worker (network layer), manages DNS, and provides security/CDN.
• Supabase: the live database (Layer 2).
• JSONBin (legacy/secondary): an older secondary store for a few minor items; no longer relied on for critical data. Supabase is now primary for everything essential.

Plain-English Data Flow

1. A member opens hometownsocial.ca in their browser.
2. The domain (via Cloudflare DNS) directs them to the current web host (Ghost/Midnight), which serves the single application file.
3. As the member uses the app, it talks to the Cloudflare Worker (the network layer).
4. The Worker securely reads and writes data to the Supabase database.
5. The member sees live, up-to-date content.

3 Provider & Account Inventory

The master list of every service the platform depends on. Keeping this current — with account owners and login recovery details stored securely — is itself a key safeguard. (Do not store passwords here; keep them in a shared password manager.)

4 Risks We're Guarding Against

A good plan names the specific things that can go wrong so each has a countermeasure. In rough order of importance:

5 Backup Strategy

Backups follow the well-proven 3-2-1 rule: keep three copies of anything important, on two different types of storage, with at least one copy off-site (away from the primary provider).

5.1 The Database (Highest Priority)

Supabase is the most valuable asset. It must be backed up automatically and regularly, with copies stored somewhere other than Supabase itself.

• Enable Supabase's built-in automated backups (available on paid plans — worth the cost for a business asset).
• Schedule an independent export of the full database weekly, stored off-site — Google Drive, Dropbox, or an S3/R2 bucket not inside the Supabase account.
• Retain a rolling history (e.g. last 8 weekly backups) so we can recover from corruption noticed late, not just the newest copy.
• Test a restore at least once — an untested backup is only a hope.

5.2 The Application File

• Keep every version of the app file, labelled by version number and date. (Already our practice.)
• Store master copies in version control (private GitHub repo) and a shared cloud folder both partners can access.
• Record which version is currently live so a rollback is unambiguous.

5.3 The Network Layer (Cloudflare Worker)

• Keep the Worker's code in version control so it can be redeployed exactly if the account is lost or misconfigured.
• Document its settings (the database address it points to and any keys) securely.

5.4 Configuration & Credentials

• Maintain a secure shared password manager (1Password / Bitwarden) with every login, API key, and recovery code.
• Grant at least two partners access to every critical account.

5.5 Recommended Backup Schedule

6 Recovery Plan (Step-by-Step)

The heart of this guide: exactly what to do if something fails. Keep this plan and the credentials accessible offline, not only inside the systems it protects.

The most likely disruption and the least severe — the data is safe in Supabase. Just serve the app file from a different place and point the domain at it.

1. Confirm the outage is the host, not the domain or database (try loading the site; check the host's status page).
2. Take the latest known-good application file (from the shared folder / version control).
3. Deploy it to the standby host (see §7 — a warm standby such as Cloudflare Pages, Netlify, or a second Ghost host should already be prepared).
4. Update the domain's DNS (in Cloudflare) to point hometownsocial.ca to the standby host.
5. Verify the site loads and members can log in and see live data (confirms the Supabase connection is intact).

The most serious scenario — which is why the backup strategy in §5 exists. Restore the database from a recent backup.

1. Stop making changes — avoid writing new data over a corrupted state.
2. Identify the most recent clean backup (Supabase automated backup, or the weekly off-site export).
3. Restore that backup into Supabase (or into a new Supabase project if the account itself is the problem).
4. If a new project was created, update the Cloudflare Worker to point to the new database address.
5. Verify data integrity — log in; check members, posts, and CRM leads are present and correct.

1. Confirm the app loads but cannot read/write data (a sign the Worker is the issue).
2. Redeploy the Worker from its saved code in version control.
3. Confirm it points to the correct Supabase database address and keys.
4. Verify live data flows again.

1. Use the shared password manager and documented recovery method (backup email, phone, 2FA codes) to regain access.
2. If one partner is unreachable, the second partner's recovery access (§3) allows continuity.
3. Once restored, rotate credentials and update the password manager.

1. If expired: renew immediately at the registrar (auto-renew should prevent this).
2. If DNS is misconfigured: correct the records in Cloudflare to point to the current host.
3. Allow time for the change to propagate, then verify.

1. Identify the last known-good version number (we keep every release).
2. Re-upload that version to the live host, replacing the broken file.
3. Verify the site works. Because data lives in Supabase, rolling back the app does not lose any member data.

7 Hosting Options & Recommended Standby

Because the application is portable, we have many hosting options. For resilience we want a warm standby ready to take over. (Prices/URLs are indicative — confirm on each provider's site before committing.)

7.1 Managed Ghost Hosts (Like Our Current Setup)

These keep the exact experience we have now — someone else runs the Ghost server, updates, backups, and email. Best for a like-for-like backup of the news/publishing side.

7.2 Static Hosts (Ideal for the App File Itself)

Because the member app is a single file talking to Supabase directly, it can be served by simple, extremely reliable static hosts — an excellent, low-cost (often free) warm standby for the application, separate from the Ghost news side.

7.3 Self-Hosted / VPS (Maximum Control, Needs Technical Management)

7.4 Recommendation

8 Recommended Action Checklist

Concrete steps to move from "well-positioned" to "fully protected," in suggested priority order:

• Enable Supabase automated backups (paid plan) Critical
• Set up weekly off-site database export + retention Critical
• Create shared password manager; add all accounts High
• Give both partners recovery access to every account High
• Put app file + Worker code in a private GitHub repo High
• Stand up a Cloudflare Pages warm standby for the app High
• Set up a second managed Ghost host for news Medium
• Confirm domain auto-renew + registrar lock are on Medium
• Perform one test database restore Medium
• Review this plan every 6 months; keep it current Ongoing