Bring deploy/ in line with the renamed app directories and with the
domains that are actually configured in the per-app .env files:
fitnes fitness.exorecovery.ru 3000 fitness-landing
hotel hotel.exorecovery.ru 3001 hotel-landing
medcenterphysio physio.exorecovery.ru 3002 physio-landing
medcenterstart start.exorecovery.ru 3003 start-landing
apps.conf, the README provisioning steps (directories, bare clones,
systemd units, the sudoers whitelist) and the exo-deploy usage line all
used the old medcenter / medcenterpersonal keys. The README table and
app.build.env.example still carried the *_DOMAIN placeholders.
Also refresh the tracked .env.example files: real VITE_SITE_URL values
instead of the old exodevices.ru sub-paths, and the amo lead tags that
match apps.conf.
Two lockfile fixes, both of which broke `npm ci` in exo-deploy:
- medcenterstart had no lockfile at all after package-lock.json and
pnpm-lock.yaml were removed — restore package-lock.json and keep the
pnpm one deleted, since the deploy path is npm;
- medcenterphysio/package-lock.json had lost "resolved" and "integrity"
on 147 of its 236 entries — restore the complete file.
Verified: exo-render-nginx renders all four vhosts with no leftover
placeholders, and every package-lock.json agrees with its package.json.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The repo had no infrastructure at all: no Dockerfile, no nginx config, no
systemd unit, no deploy script, no CI. Deployment guidance existed only
as two prose lines in each README.
Target shape is one reg.ru KVM box serving all four landings, each on its
own domain root. nginx serves the built SPA off disk and proxies only
/api/* to a small Express process per app, so a crashed or restarting API
takes down the form rather than the page. Releases are built on the
server into a timestamped directory and swapped in by renaming the
`current` symlink.
deploy/apps.conf domains and ports, the one place to edit
deploy/README.md hardware/software spec, provisioning, runbook
deploy/bin/ exo-deploy, exo-render-nginx
deploy/nginx/ vhost template, shared snippets, http extras
deploy/systemd/ one template unit for all four instances
deploy/env/ annotated templates for the two env files
exo-deploy asserts the VITE_SITE_URL substitution actually happened,
prunes devDependencies after building, precompresses for gzip_static,
health-checks after the swap and rolls back on its own if the new release
fails to answer. exo-render-nginx refuses to emit a vhost while a
placeholder domain is still in apps.conf.
Secrets are split across two env files: the amoCRM token stays in
/etc/exo at mode 640 and is injected by systemd, while only public
build-time vars are copied into a release. dotenv does not override
variables already in the environment, so the two coexist safely.
Chose systemd over Docker deliberately — no database, no conflicting
runtimes, no CI or registry to build images in, and containerising fights
the serve-static-from-disk design. Reasoning and the triggers to revisit
it are recorded in the README.
Domains are still placeholders; nothing here has been run against a
server yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Yuriy PanovandClaude Opus 5
yuriy.pandClaude Opus 5