The day-to-day environment a senior engineer uses to work on FaceKom (vuer_*). This page is the operational counterpart to running-the-stack and build-deploy-release; start from INDEX for the verified knowledge base.
Provenance legend
SOURCE-VERIFIED = read from a repo file (cited as path / path:LINE).
ENV/OPERATIONAL = dev-box specifics (SSH, Tailscale, SSHFS, dnsmasq, URLs, registry). These are not in repo source; they come from the team’s operational notes and live under the callout below.
1. The two-location model
There are two ways the same code reaches your tools, and they behave very differently.
Reading a remote-only file when no local checkout exists.
The #1 environment trap (ENV/OPERATIONAL)
On the SSHFS mount/Users/levander/coding/mnt/Facekom/, ls / find / Glob return EMPTY and Grep is unreliable — the files still exist. Concluding “the file isn’t there” from an empty listing is the single most common mistake. For discovery against the mount, run find / grep over SSH (see §2); use the Read tool only once you know the exact path. Write / Edit / git do not work on the mount at all.
This caveat applies to the mount only. When a service is checked out locally under /Users/levander/coding/facekom/<svc> (the normal case — vuer_oss, vuer_css, vuer_cv are frequently local), all tools work normally and you should not SSH for code discovery.
Operation
Local checkout
SSHFS mount
Read (known path)
yes
yes
ls / find / Glob
yes
NO (empty)
Grep
yes
unreliable
Write / Edit
yes
NO
git
yes
NO
2. The remote dev box
HOST CHANGED 2026-07-01 — the old box is decommissioned
lederera-447-fk-hardver (reached as ssh Facekom, ProxyJump FKJumpBox) is offline since ~2026-06-27 and decommissioned. Never use ssh Facekom again. The dev/build/test host is now the fk-dev Tailscale VM. Canonical reference: dev-build-host.
Operational/environment knowledge (team setup; not repo source)
Host:fk-dev — GCP VM on tailnet taild4189d.ts.net, IP 100.91.108.61.
SSH (Tailscale SSH, no keypair):
command ssh ops@fk-dev.taild4189d.ts.net
ssh gotcha: the user’s shell aliases ssh/scp to a _kaku_wrapped_ssh function that is not loaded non-interactively → always use command ssh / command scp.
Remote workspace:/workspace/vuer_*/ (e.g. /workspace/vuer_oss, /workspace/vuer_css) — bind-mounted into the containers.
Read-only discipline: treat the box as read-only for investigation. Do not SSH to mutate state unless explicitly asked.
Native builds: container image builds still run native on the remote host, not emulated on the Mac (qemu SIGSEGV / overlay-IO) — only the host changed.
3. DNS & dev URLs
Operational/environment knowledge (team setup; not repo source)
dnsmasq resolves *.facekomdev.net → Tailscale IP 100.103.48.49.
Per-engineer dev URLs (note the -lederera suffix — each engineer gets their own host slice):
The remote FaceKom dev box (now fk-dev; formerly reached via the retired ssh Facekom) runs Docker — operate services with docker exec -it <svc> … and docker compose …. This is settled: user-confirmed 2026-05-30. The earlier “Podman 5.7.1” note for this box was incorrect and has been corrected. All operational runbooks here (status, logs, DB, queues) use the Docker form. (ENV/OPERATIONAL)
5. The _dev vs _docker profile split (SOURCE-VERIFIED)
Each service ships two parallel runtime profiles, selected by filename suffix: _dev = the local/per-engineer dev profile, _docker = the containerized profile. Both an nginx vhost and a supervisor process file exist for each. (vuer_oss/ also carries a third, supervisor_vuer_oss_e2e_test.conf, for the E2E harness — see testing.)
Verified file inventory (SOURCE-VERIFIED — ls of vuer_oss/ and vuer_css/):
none (nginx_vuer_oss_docker.conf — no server_name)
So _dev is a name-based virtual host on a high port (20080), matching oss.<anything>.dev — i.e. multiple engineers’ vhosts can coexist on one nginx behind the dnsmasq/Tailscale routing from §3. _docker is the plain in-container default server on :80. Everything downstream is shared — same upstreams (vuer-oss → 127.0.0.1:10081, socketio-oss → :10080, vuer-oss-media → :10079; nginx_vuer_oss_dev.conf:1-10), same root /workspace/vuer_oss/web, same media/socket.io location routing and error.html/502.html error pages.
supervisor: what actually differs
supervisor_vuer_oss_dev.conf (SOURCE-VERIFIED) defines the process fleet that makes up “vuer_oss” — each a node <entry>.js with environment=NODE_ENV="dev", autorestart=true, exitcodes=0,2, startsecs=0 (so a crash restarts in ~1–2s, which is why a crash-loop fills logs fast):
Supervisor program
Command
Role
vuer_oss
node server.js
main API / web server (supervisor_vuer_oss_dev.conf:29-48)
vuer_integration_log
node integrationLog.js
integration logging
vuer_media
node media.js
media (records/screenshots)
vuer_oss_convert
node convert.js
conversion worker
vuer_cron
node cron.js
scheduled jobs
vuer_background
node background.js
background processing
vuer_oss_storage
node storage.js
storage worker
Plus nginx and redis as supervised programs in the same file (supervisor_vuer_oss_dev.conf:5-27). The _docker supervisor file is the container-profile equivalent (same programs, container-tuned). These program names are exactly what you pass to supervisorctl restart (see running-the-stack).
Practical read
If you’re editing nginx/supervisor for local work you almost always want the _dev files; the _docker files are baked into the image. The two are intentionally kept in lockstep so a service behaves the same locally and containerized apart from the listener/vhost.
vuer_docker/.env — the version knobs (SOURCE-VERIFIED)
vuer_docker/.env is the single place that pins every image tag/version for the dockerized dev stack. Read verbatim (vuer_docker/.env):
2026.1.UBI9 means the OSS/CSS/portal images are built on Red Hat UBI9, not the Ubuntu the host box runs — host OS ≠ container base. DEV-tagged components (pdfservice, nyilvántartó, facekom library, CV build number) are built locally rather than pulled as a fixed release. Bumping a stack component = edit this file, not the compose YAML. (SOURCE-VERIFIED + interpretation)
6. First-time connect / orientation checklist
Local checkout exists? Work from /Users/levander/coding/facekom/ — all tools work there. Only touch the SSHFS mount if a service isn’t checked out locally. (§1)
Reach the box:command ssh ops@fk-dev.taild4189d.ts.net (Tailscale SSH; ssh Facekom / lederera-447-fk-hardver is decommissioned). Confirm Tailscale is up if the host won’t resolve. (§2)
Confirm DNS/URLs: hit the fk-dev MagicDNS URLs, e.g. https://oss-fk-dev.taild4189d.ts.net (css-, esign-*, portal- likewise). The old dnsmasq → 100.103.48.49 / *-lederera.facekomdev.net chain in §3 died with the old box. (§3)
See what’s running:docker exec -it vuer_oss supervisorctl status (and vuer_css, vuer_cv). The program names map 1:1 to §5’s supervisor table. (§4–§5)
Never ls/Glob/find the SSHFS mount — use SSH find/grep for remote discovery. (§1)
Editing infra locally? Pick the _dev nginx/supervisor files; _docker ones are image-baked. (§5)
Changing a stack version? Edit vuer_docker/.env. (§5)
Container runtime is Docker on the remote box (user-confirmed 2026-05-30) — operate FaceKom via command ssh ops@fk-dev.taild4189d.ts.net + docker exec / docker compose. (§4)
ssh Facekom alias / FKJumpBox ProxyJump and the dnsmasq 100.103.48.49 mapping are OBSOLETE as of 2026-07-01 — that box is decommissioned. Host truth now lives in dev-build-host (fk-dev, Tailscale SSH + MagicDNS, no dnsmasq).
Remote runtime = Docker — SETTLED (user-confirmed 2026-05-30). The remote dev box (now fk-dev) runs Docker (docker exec, docker compose); the old “Podman 5.7.1” note for it was wrong. No longer a gap (see §4 callout). The repo’s vuer_docker/.env independently confirms a docker-compose stack.
_docker nginx/supervisor internals beyond the listener line were not line-by-line diffed here; only the listen/server_name divergence is verified. The CSS pair (nginx_vuer_css_*.conf, supervisor_vuer_css_*.conf) was confirmed to exist but not read.
vuer_cv runtime-generated nginx (Jinja2) is an ENV note, not verified from a template file in this pass.