caterium-app/ops/timeweb
pavlov346346 66d4414634 Ops: retarget Timeweb auto-deploy to app.caterium.ru, not the apex domain
caterium.ru and app.caterium.ru are separate Timeweb sites with separate
document roots. The apex domain's root is reserved for an unrelated future
site, so auto-detection must never be able to land there. Drop the generic
$HOME/public_html and unverified app.caterium.ru/public_html guesses in
favor of the confirmed real path ($HOME/caterium-app/public_html), and
require CATERIUM_WEB_ROOT explicitly in the documented cron command.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-10 20:39:16 +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.