Cara kami menyiapkan situs shared hosting untuk maintenance dengan Cloudflare Workers

Pemberitahuan memberi jendela maintenance enam jam tanpa durasi downtime pasti. Menunggu email server down menyisakan jeda manual; memindahkan DNS ke satu halaman hanya mempertahankan pesan, bukan konten dan alat browser.

Berikut implementasi yang benar-benar kami pasang: tiket HostArmada, logika Worker, snapshot, jebakan rekursi, pengaman paket gratis, SEO, iklan, analitik, dan batas yang kami nyatakan apa adanya.

Catatan waktu: per 18 Juli 2026, maintenance terjadwal belum berlangsung. Hasil ini berasal dari kegagalan origin paksa, staging privat, audit snapshot, dan pass-through live yang sehat, bukan dari jendela maintenance sebenarnya.

Yang dijelaskan tiket HostArmada

Maintenance dijadwalkan 22 Juli 2026 pukul 10.00–16.00 CDT. Kami menanyakan apakah itu enam jam penuh, kemungkinan migrasi sementara, layanan terdampak, endpoint luar yang memberi 503 untuk setiap URL, rollback, dan kredit layanan.

Setelah eskalasi, admin menjelaskan enam jam adalah jendela cadangan, bukan downtime pasti. Gangguan diperkirakan lebih singkat tetapi tak dapat dipastikan karena perubahan perangkat keras, pembaruan sistem, dan verifikasi. Memindahkan lalu mengembalikan akun berisiko pada DNS, sinkronisasi, email, dan database.

HostArmada menawarkan vhost pada server tak terdampak dengan halaman maintenance dan perubahan A record manual di awal/akhir. DNS eksternal tetap resolve, tetapi web, database, email, dan panel di server asal tidak terjangkau. Backup dan prosedur pemulihan tersedia; kredit ditinjau setelah dampak nyata. Penawaran itu wajar untuk halaman informasi, tetapi manual dan bukan kontinuitas situs fungsional.

That offer was fair for a maintenance notice. It was still manual and did not provide functional-site continuity, so we used it as the baseline to improve rather than portraying it as a provider failure.

Linimasa bukti: dari email maintenance ke kontinuitas teruji

Urutan ini memisahkan pengumuman provider, pertanyaan kami, hasil build/uji, dan kejadian nyata yang belum berlangsung.

1. Juli 2026 — email maintenance

   Pemberitahuan Start Dock mencadangkan 22 Juli 10.00–16.00 CDT: upgrade CPU, RAM, SSD; keamanan/software web; kernel; pembersihan tmp/cache/log; optimasi. Prosedur disebut tidak dapat dibalik setelah dimulai.

2. 16 Juli — pertanyaan dieskalasi

   Durasi nyata, migrasi, endpoint 503 luar, web/DB/email, backup, rollback, dan kredit.

3. 17 Juli — jawaban HostArmada

   Enam jam adalah jendela; downtime mungkin lebih singkat, migrasi ditolak karena sinkronisasi, vhost plus A-record manual ditawarkan.



4. Desain dipilih 17 Juli; tindak lanjut dikirim 18 Juli

   Worker origin-first selalu aktif, snapshot, staging privat, collision check, 503, dan rollback.



5. 17–18 Juli — uji terkontrol

   1.514 halaman, 1.234 aset, 2.748 path diaudit, gagal/pass-through diuji, rekursi diperbaiki, apex/www fail-open aktif.

6. 18 Juli — siap, kejadian belum terjadi

   Lapisan aktif dan teruji; maintenance tanggal 22 belum terjadi. Durasi, traffic, dan pendapatan nyata menunggu bukti sesudahnya.

Arsitektur: origin lebih dulu, snapshot hanya saat gagal

Worker selalu aktif pada rute apex dan www. Ia meminta origin asli dengan timeout terbatas. Respons sehat diteruskan utuh sehingga PHP, sesi, header, iklan, dan analitik tetap normal.

Jika jaringan gagal, timeout, atau status 500, 502, 503, 504, atau 520–527, Worker mencari path yang sama pada aset snapshot. GET dan HEAD berlanjut. Setiap permintaan selanjutnya menguji origin lagi, jadi pemulihan otomatis.

Snapshot sengaja bukan stack PHP kedua, sehingga tak ada dua database writable, konflik sesi, email ganda, atau rekonsiliasi data.

Alur permintaan

Pemulihan origin otomatisSetiap request berikutnya mencoba host; respons sehat langsung diteruskan.

Halaman provider atau kontinuitas Worker?

Halaman maintenance cocok untuk semantik sederhana; snapshot membutuhkan persiapan lebih tetapi mempertahankan sebagian besar perjalanan baca dan alat client-side.

Yang diterima pengguna dan crawler

Halaman, alat browser, CSS, skrip, gambar, dan font dilayani dari snapshot dengan pemberitahuan kecil. Canonical dan structured data tetap memakai URL asli.

Aksi tulis tidak berpura-pura sukses. POST dan aksi yang tidak tersedia mengembalikan 503 Service Unavailable, Retry-After: 300, dan Cache-Control: no-store, sesuai penggunaan maintenance sementara dalam RFC 9110.

This distinction matters: returning a pretty 200 OK “maintenance” page for a failed form can mislead users and crawlers. Returning a controlled 503 for the unavailable action is both more honest and easier for clients to retry.

Matriks fallback sebenarnya

Cara kami membangun dan memverifikasi snapshot

Kami merayapi produksi yang sudah dirender, bukan pohon PHP lokal yang berisi perubahan belum terbit. Hasilnya 1.514 halaman, 1.234 aset first-party, dan paket 2.749 file sekitar 547,6 MB; semua file di bawah batas individual.

Canonical dan schema dipertahankan; referensi relatif lama diperbaiki hanya pada salinan. Tracker dihapus saat capture. Worker produksi menambahkan GA4, AdSense, dan Clarity hanya di homepage; staging tetap privat, tanpa tracking, dan noindex.

QA mencakup TypeScript/unit, kegagalan origin lokal, staging terautentikasi, browser, preview origin, dan audit remote penuh; seluruh 2.748 path halaman/aset publik berhasil.

Staging privat sebelum rute publikAutentikasi, noindex, paksa gagal, bandingkan origin, lalu setujui.

Reproduksi dengan aman: langkah dan kode tersanitasi

1. Tetapkan kontrak. Host, metode aman, status pemicu, timeout, path tak dikenal, dan penghapusan rute. Respons non-200 belum tentu outage.

2. Crawl produksi render. Mulai dari sitemap canonical, ambil resource same-origin HTML/CSS, normalisasi URL, blok traversal, dan gagalkan build jika limit lewat.

3. Pertahankan makna. Simpan canonical, hreflang, schema, link, dan aset alat client; hapus service worker/tracking. Tambahkan ads/analytics hanya di produksi.

4. Gunakan ASSETS dan run_worker_first. Origin diperiksa sebelum snapshot; contoh hanya placeholder.

5. Cegah rekursi. Gunakan nama DNS-only terkontrol satu zona untuk resolveOverride, pertahankan URL/Host, lalu uji TLS/vhost.

6. Staging privat. Secret, noindex, robots blok, tanpa iklan/analytics, dan origin preview.

7. Pasang apex lalu www. Tolak collision, verifikasi redirect, dan gunakan fail-open hanya untuk ketersediaan.

8. Pisahkan rollback. Hapus hanya rute milik sendiri, pertahankan Worker/snapshot, cabut izin sementara.

{
  "name": "example-host-outage-fallback",
  "main": "src/index.ts",
  "compatibility_date": "2026-07-17",
  "assets": {
    "directory": "./snapshot/dist",
    "binding": "ASSETS",
    "run_worker_first": true,
    "html_handling": "none",
    "not_found_handling": "none"
  },
  "vars": {
    "MODE": "production",
    "ORIGIN_BASE": "https://example.com",
    "ORIGIN_RESOLVE_OVERRIDE": "origin-bypass.example.com",
    "ORIGIN_TIMEOUT_MS": "4500"
  }
}

const FALLBACK_STATUSES = new Set([
  500, 502, 503, 504, 520, 521, 522, 523, 524, 525, 526, 527
]);

try {
  const origin = await fetch(originRequest, {
    signal: AbortSignal.timeout(4500),
    redirect: "manual",
    cf: { resolveOverride: "origin-bypass.example.com" }
  });
  if (!FALLBACK_STATUSES.has(origin.status)) return origin;
  return serveSnapshot(request, origin.status);
} catch {
  return serveSnapshot(request);
}

if (!new Set(["GET", "HEAD"]).has(request.method)) {
  return new Response("Temporarily unavailable", {
    status: 503,
    headers: {
      "Retry-After": "300",
      "Cache-Control": "no-store",
      "Content-Type": "text/plain; charset=utf-8"
    }
  });
}

# Build from rendered production and validate the package
python scripts/build_snapshot.py
npm run types
npm run check
npx wrangler deploy --env staging --dry-run

# Deploy and test the private preview (use your own secret securely)
npx wrangler deploy --env staging
python scripts/smoke_staging.py --base "https://<private-preview>" --password "<secret>"

# Inspect, activate, or remove only the owned routes
python scripts/manage_routes.py status
python scripts/manage_routes.py activate --confirm ACTIVATE-KBT-FALLBACK
python scripts/manage_routes.py deactivate --confirm REMOVE-KBT-FALLBACK

Rencana uji: buktikan gagal, pass-through, dan pulih

Uji homepage, alat utama, CSS/JS, artikel, Arabic RTL, lokal panjang, robots, missing path, HEAD, POST, redirect www, tema mobile.

Mode snapshot: header, canonical, H1, JSON-LD, aset, notice. Origin preview: akses tanpa loop. Produksi sehat: tanpa header fallback dan respons tetap.

Jangan rusak origin publik. Pakai preview/origin uji dan catat waktu snapshot serta hash manifest.

Rollback, pemantauan, dan pemulihan

Rollback segera berarti menghapus hanya rute Worker, bukan DNS atau Worker. Verifikasi apex/www dan purge hanya bila HTML lama tersisa.

Pantau header, status origin, log, halaman kunci, dan 503. Respons sehat pertama pulih otomatis. Setelahnya verifikasi stabilitas, cabut izin, arsipkan metrik, dan refresh snapshot.

Dua jebakan: rekursi satu zona dan limit gratis

Worker pada keyboardtester.click/* tidak boleh memanggil host publik yang sama secara naif. resolveOverride dengan hostname DNS-only yang sudah ada di zona yang sama mengarahkan lookup ke origin sambil mempertahankan URL dan Host canonical. Alamat origin dan jalur bypass harus tetap privat.

Free plan saat ini memberi 100.000 request Worker/hari, 20.000 file statis/versi, dan 25 MiB/file. Paket 2.749 file muat. Rute diatur fail-open: saat kuota habis, Cloudflare melewati Worker ke HostArmada, bukan Error 1027. Ini tepat untuk ketersediaan, bukan kontrol keamanan.

SEO, iklan, dan analitik saat fallback

Halaman snapshot yang ada memberi 200 pada URL asli dengan canonical, schema, dan internal link; aksi tulis memberi 503. Tidak ada domain backup publik atau URL baru untuk disubmit.

Staging berpassword, diblok robots, noindex, dan tanpa tracking. Hanya HTML fallback produksi yang menerima GA4/AdSense tertunda serta Clarity di homepage. Respons origin sehat tidak diubah. Pengukuran dan peluang iklan bertahan, tetapi fill dan pendapatan tak pernah dijamin.

We did not submit fallback URLs to search engines because there are no new public URLs. The continuity layer sits behind the same addresses Google already knows.

Injeksi produksi mengikuti performa live: GA4 setelah interaksi atau 2 detik dari load, AdSense setelah interaksi atau 15 detik, Clarity homepage setelah interaksi atau 12 detik. HTMLRewriter streaming hanya mengubah fallback GET HTML, bukan HEAD, CSS, JS, atau gambar.

Batasan dan kapan memilih solusi lain

Formulir, AI server, email, database write, sesi, dan submission tersimpan tetap offline tanpa origin. Alat browser bekerja hanya jika semua file kebutuhannya tersalin.

Snapshot dapat usang; perbarui setelah perubahan besar dan uji pemulihan juga. Produk transaksi atau write-heavy memerlukan aplikasi serta database ter-replikasi.

Untuk situs konten shared hosting dengan banyak alat client-side, pola ini cocok: tanpa split data, cutover manual, atau domain duplikat, dan mode degradasi jelas. Ia mengecilkan downtime yang terlihat, bukan menghapus semua ketergantungan.

Sumber primer dan bukti langsung

Angka berasal dari manifest serta pemeriksaan deploy/rute tanggal 17–18 Juli 2026. Perilaku produk dan batasannya didukung dokumentasi primer yang ditautkan.

• Cloudflare Workers: Static Assets
• Cloudflare Workers: Platform Limits
• Cloudflare Workers Request API
• Cloudflare Workers Routes API
• RFC 9110: HTTP Semantics
• HostArmada support correspondence, July 16–17, 2026

Pertanyaan umum

• Apakah shared hosting jadi benar-benar zero-downtime?

  Tidak. Salinan baca tersedia, tetapi formulir, write, email, AI, dan sesi tetap membutuhkan origin.

• Haruskah saya mengubah DNS saat host down?

  Tidak untuk pola always-on ini. Worker menguji tiap request dan kembali otomatis.

• Apakah Google melihat halaman maintenance di semua URL?

  Tidak. Halaman yang tersalin tetap 200 dengan canonical/schema; aksi yang tidak tersedia mendapat 503 sementara.

• Mengapa tidak memigrasikan seluruh akun sementara?

  Pindah dan kembali dapat menambah risiko sinkronisasi DNS, file, email, dan database.

• Mengapa resolveOverride?

  Agar Worker tidak memanggil rutenya sendiri. Lookup memakai host lain satu zona, tetapi URL dan Host tetap canonical.

• Apa yang terjadi saat limit gratis habis?

  Fail-open melewati Worker ke origin. Fallback hilang saat origin down, tetapi tak muncul error kuota tambahan.

• Kapan snapshot diperbarui?

  Setelah perubahan besar dan sebelum maintenance, sambil menguji kegagalan serta pemulihan.

Pelajarannya bukan menaruh semuanya di belakang Worker, melainkan memilih lapisan terkecil yang cocok, mengujinya privat, jujur soal batas, dan mengotomatiskan pemulihan.