* ops: run the Telegram bots and the assistant on vps3
telegram-bot and ask ran on the free cloud project, which paused itself
after a quiet week; every bot went silent and the deploy job failed against
the paused project. They now run in their own edge-runtime container on vps3
(bots/), from /opt/pezkuwi-bots.
Separate from the shared functions runtime because that one verifies a JWT
on every request, which Telegram cannot send, and holds the platform's wallet
keys, which a public bot feeding user text to a language model should not
sit next to. The new runtime holds only the keys the two functions read.
- telegram-bot refuses updates without Telegram's secret-token header
(TELEGRAM_WEBHOOK_SECRET); the main slot reads TELEGRAM_BOT_TOKEN_MAIN,
since TELEGRAM_BOT_TOKEN on vps3 is the miniapp's sign-in check.
- nginx keeps the public URL shape:
supabase.pezkuwichain.io/functions/v1/{telegram-bot,ask}.
- deploy.yml ships them with a new bots-deploy verb on the existing deploy
key; the host script accepts exactly main, telegram-bot and ask, restarts
the container and fails unless the bot comes back refusing unsigned updates.
- Registry: _cloud_hosted becomes _hosted_elsewhere; the gate refuses those
names in the shared volume and reports any copy there as stale.
* ask: send the legacy service key as a bearer token on vps3
The vps3 gateway has no opaque sb_secret keys and honours the service_role JWT
only as a bearer token; sent on apikey alone it reads as anon, the limiter's
count fails, and every question is refused as rate-limited.
Pinning trufflehog to a commit made dependency review list it as a changed
dependency, and its AGPL-3.0 licence is on the deny list. It is the scanner
this workflow runs, executed in CI and never shipped or served, so it is
allowed by name; the deny list still applies to everything else.
The deploy reached VPS3 as root with one key, handed to appleboy actions
referenced by tag, and on every run it reinstalled the edge-function
ownership gate and its registry as root. That gate guards every project's
functions in the shared volume, so any change merged here could rewrite the
rule that protects pwap's functions.
Now CI connects as miniapp-deploy with two keys, each pinned on the host
(authorized_keys restrict,command=) to a script in ops/host:
- MINIAPP_SITE_DEPLOY_KEY -> miniapp-site-receive: the site tar on stdin,
into /var/www/telegram.pezkiwi.app, nothing else.
- MINIAPP_FUNCTIONS_DEPLOY_KEY -> miniapp-functions-ssh: `gate-sha`, or
`deploy` with functions.tgz on stdin, run through sudo for exactly those
arguments.
Root installs the gate and registry from ops/; the deploy checks the host's
copies against them and refuses to deploy functions while they differ.
The asset cleanup that ran after each deploy (/opt/cleanup-miniapp.sh, only
on the host) protected lazy chunks by mtime and so removed live ones when a
build was shipped more than two hours after it was made; it took seven pages
down for about two minutes on 2026-10-09 while this was being tested, and
they were restored from the same tar. The receive script now keeps every
file of the new build and removes other assets only after four hours. Its
tests cover that (red with the keep rule removed) and the refusals; CI runs
them with shellcheck, and apply-repo-settings.sh requires the job.
VPS3's host key is pinned. The commented-out VPS1 deploy is gone; that host
no longer exists. Every action is pinned to a commit SHA.
* chore(deps): move vulnerable dependencies to patched versions
Direct dev dependencies: vite ^5.4.1 -> ^6.4.3 (5.x has no patched
release for the fs.deny bypass and launch-editor advisories; also lifts
esbuild from 0.21.5 to 0.25.12), vitest and @vitest/coverage-v8 ->
^4.1.11, postcss -> ^8.5.23.
Transitive packages refreshed within their existing ranges:
brace-expansion, js-yaml, baseline-browser-mapping, qs, @humanfs/node,
browserslist, postcss-selector-parser, nanoid, form-data, @babel/core,
picomatch.
Overrides with a floor at the patched version where a parent pins an
old release: axios ^1.20.0 (tronweb pins 1.15.0) and ws ^8.21.0
(ethers pins 8.17.1).
* fix(security): address open code scanning findings
- auto-merge: pass workflow_run.head_branch through env instead of
interpolating it into the shell script (code injection).
- ci, deploy, code-quality: restrict GITHUB_TOKEN to contents: read.
- telegram-bot: return a generic error body on failure; the error stays
in the function log instead of being echoed to the caller.
- p2p-e2e-test.py: stop printing a prefix of the service-role key.
The organisation's code security configuration enables CodeQL default
setup, and GitHub refuses to apply it while a workflow runs CodeQL itself:
the configuration failed on this repository with "Code scanning conflict".
Default setup covers what this job did. The job ran the default query
suite with no config file, path filters or packs, and the languages it
analysed are among those default setup detects here. Default setup takes
over the scan; this workflow keeps its other jobs.
security-events: write served only the SARIF upload, so it goes with it.
contents: read is all the remaining jobs need.
Two pieces of infrastructure existed only on servers, as single copies with no
history and no review:
/usr/local/bin/supabase-deploy-functions the gate both projects deploy through
/opt/supabase-self-hosted/functions-registry.json who owns which function name
The gate exists to stop silent drift between what a repo declares and what a
server actually runs. Leaving it unversioned meant the mechanism was drifting the
same way it was built to prevent — and losing that host would have lost it
entirely, along with any record of why it works the way it does.
Both are now in ops/ and synced to the host by CI on every deploy, installed
before the functions they validate so a change to the gate ships together with
them. Verified identical to the server copies by checksum before committing, so
this captures the running state rather than replacing it.
Branch protection gets the same treatment: apply-repo-settings.sh is idempotent
and has a --check mode that reports drift without changing anything. It was
applied by hand through the API today, so nothing here reflected it.
Documented alongside: why the registry lives in this repo even though pwap-web
depends on it (a pwap-web change needs a PR here — deliberate friction, since
the registry is the record of who owns what and should not be edited on a server
where nobody sees the change), and why listing each CI job individually in the
protection rules is a weakness here that pwap-web avoids with an aggregate job.
The functions in this repo do not all live in the same place, and the deploy
step I added yesterday sent all of them to the self-hosted host on vps3.
telegram-bot and ask are served from the cloud project vbhftvdayqfmcgmzdxfv.
Both Telegram bots reach it by webhook — ?bot=krd is @pezkuwichainBot and
?bot=dks is @DKSKurdistanBot — and news.pex.mom's assistant calls ask there.
Copies of both still sit in the vps3 volume from before that split, holding a
bot token revoked on 2026-07-19, and take no traffic. Deploying to vps3 was
therefore updating a dead copy while the live one kept running old code.
So the self-hosted job now excludes those two, and a second job deploys them to
the cloud project. That closes a real gap: they had been deployed by hand for
months, and git drifted far enough behind that on 2026-07-21 the running
function body had to be extracted from the deployed bundle to recover it.
The host registry records the split too, so the gate cannot be pointed at the
wrong target by accident.
The Supabase edge-function volume on the host is shared with pwap-web, which
deploys into it by rsyncing its whole tree. Both projects defined a function
called telegram-auth, so on 2026-06-28 pwap-web's login-widget handler replaced
this project's initData handler. Sign-in and every wallet screen behind it have
returned 401 ever since; nothing failed loudly because the name still resolved.
Rename this project's two colliding functions to a tgm- namespace so the two
deploys can no longer reach the same directory, and point the client at the new
name. process-withdraw is renamed too: it is currently unreferenced here, but it
moves platform funds, so leaving it shadowed by another project's version is not
something to keep.
Also deploy functions from CI. They were last pushed by hand in April, so seven
of them had drifted behind the repo and one had never shipped at all. The new
step writes through the host's ownership gate, which refuses any name this
project does not own — the drift and the collision both stop here.
Ownership is recorded in /opt/supabase-self-hosted/functions-registry.json.
- Split monolithic ci.yml into focused workflow files
- Add code-quality.yml with complexity analysis and duplicate detection
- Replace template codeql.yml with comprehensive security.yml (CodeQL, dependency audit, dependency review, secret scan)
- Separate deploy into its own workflow triggered by CI success
