caterium-app/ops/timeweb
2026-09-17 17:30:57 +03:00
..
api-proxy.php Restore Caterium schema and switch production to fresh Supabase 2026-09-17 17:30:57 +03:00
caterium-production-sync.sh Ops: retarget Timeweb auto-deploy to app.caterium.ru, not the apex domain 2026-09-10 20:39:16 +03:00
README.md Ops: retarget Timeweb auto-deploy to app.caterium.ru, not the apex domain 2026-09-10 20:39:16 +03:00

Timeweb fallback auto-deploy

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.