Timeweb fallback auto-deploy

Backend access without external browser dependencies

The browser loads the pinned Supabase SDK from public/vendor/, then sends Auth, REST, Storage and Functions traffic to the same-origin PHP entry point https://app.caterium.ru/api/index.php?__caterium_path=.... The query route is deliberate: nginx can serve static extensions before Apache, so rewriting a storage URL ending in .jpg is insufficient on this hosting.

public/api/index.php must be identical to ops/timeweb/api-proxy.php. The app copy is deployed with the release; the dedicated API host copy is installed separately at /home/c/ci503744/public_html/api-proxy/index.php. Only app.caterium.ru and api.caterium.ru are accepted, with a fixed Supabase upstream and the existing allowlist of backend paths. Browser authorization is forwarded unchanged; RLS remains enforced. Responses are private/no-store, and the service worker never caches /api/.

Safe reads and password login may retry on api.caterium.ru. Direct Supabase fallback is disabled. Writes and refresh-token exchanges are not replayed; uncertain saves retain the existing read/revision recovery path. The Supabase client still uses the project URL internally, preserving existing auth sessions.

Updates use HTTP: a revision-only request every 20 seconds while visible, and chat refresh every 10 seconds. Unchanged bases are not downloaded again. Requests from the previous account are discarded. Typing/online indicators require a future WebSocket-capable proxy and are not advertised by the HTTP mode.

This covers application data and media. Optional map/geocoding providers remain external and do not gate login or order loading. If the login page itself cannot open, diagnose DNS/TLS/operator connectivity separately.

Use this only for the Year/shared-hosting fallback where system crontab is unavailable and scheduling is configured in the Timeweb panel.

Production target: app.caterium.ru

Caterium runs as its own Timeweb site (panel name caterium-app), bound to app.caterium.ru, with document root:

$HOME/caterium-app/public_html

caterium.ru (the apex domain) is a separate Timeweb site (panel name "Основной сайт") reserved for a future, unrelated site. This script must never write there. CATERIUM_WEB_ROOT is always passed explicitly in the cron command below for this reason — do not rely on auto-detection for this account.

What it does

caterium-production-sync.sh checks the GitHub production branch, deploys only when the commit changed, validates that public/index.html exists, creates a rollback archive before changing live files, prevents overlapping runs, and keeps the four newest backups.

If CATERIUM_WEB_ROOT is unset, it falls back to auto-detecting $HOME/caterium-app/public_html only — it will never guess the account's default document root.

One-time setup

Copy ops/timeweb/caterium-production-sync.sh from this repository to:

$HOME/caterium-production-sync.sh

Check it transferred with LF line endings (a CRLF copy from a Windows machine will fail sh -n with a syntax error around the for loop):

sh -n "$HOME/caterium-production-sync.sh" || sed -i 's/\r$//' "$HOME/caterium-production-sync.sh"
chmod 700 "$HOME/caterium-production-sync.sh"

The deploy checkout authenticates over the GitHub SSH deploy key already configured in ~/.ssh/config on the account. If that config uses a Host alias other than github.com (for example github-caterium), pass the matching URL via CATERIUM_REPO_URL, e.g. git@github-caterium:pavlov346346-source/caterium-app.git — plain git@github.com:... will not pick up the alias's IdentityFile.

Before relying on cron, create $HOME/.caterium-deploy once so the log redirect below has somewhere to write on the very first run:

mkdir -p "$HOME/.caterium-deploy"

Timeweb panel Crontab

Create one task:

Name: Caterium production sync
Schedule: every 5 minutes — minute */5, hour *, day *, month *, weekday *

If Timeweb offers a "Сценарий SH" interpreter option and lets you set environment variables for it, point it at $HOME/caterium-production-sync.sh with CATERIUM_WEB_ROOT and CATERIUM_REPO_URL set as below.

If it only offers an arbitrary command, use:

mkdir -p "$HOME/.caterium-deploy" && CATERIUM_REPO_URL="git@github-caterium:pavlov346346-source/caterium-app.git" CATERIUM_WEB_ROOT="$HOME/caterium-app/public_html" /bin/sh "$HOME/caterium-production-sync.sh" >> "$HOME/.caterium-deploy/cron.log" 2>&1

CATERIUM_WEB_ROOT is set explicitly on purpose, so a change on the Timeweb side (a new site, a renamed site) can never make this script fall back onto the wrong document root instead of failing loudly.

The leading mkdir -p matters: without it, the very first cron run fails before the script even starts, because the shell opens the log file for the >> redirect before executing anything, and $HOME/.caterium-deploy does not exist yet on a fresh account.

The old Cloudflare Worker must remain enabled as a fallback until the Timeweb production domain, SSL, Supabase flows, uploads and PDF generation have been verified.

5.1 KiB Raw Blame History