94 lines
5.1 KiB
Markdown
94 lines
5.1 KiB
Markdown
# 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:
|
|
|
|
```text
|
|
$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:
|
|
|
|
```text
|
|
$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
|
|
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:
|
|
|
|
```sh
|
|
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:
|
|
|
|
```sh
|
|
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.
|