Running the FaceKom Stack (local dev & compose runtimes)

Running the FaceKom Stack

How a senior engineer brings the FaceKom (“Vuer”) stack up. There are three distinct run modes, two CLI wrappers (bin/facekom and bin/vuer.sh), and a per-service supervisord process model that is the same whether the service runs in a container or in local “dev” mode. This note documents them from the scripts/configs — it never runs the commands.

Hosts/URLs/DNS are environment facts and live in dev-environment; this note references them rather than restating them. For the per-repo internals see vuer_oss, vuer_css, vuer_cv, vuer_docker. For how images are built/tagged see build-deploy-release. For the service map see architecture-overview; for the test pipelines see testing.

See also: INDEX

No application Dockerfiles live in the app repos. vuer_oss/vuer_css/vuer_cv carry no Dockerfile — "docker" is a NODE_ENV/PYTHON_ENV profile name, and the runtime is supervisord + nginx inside an image built elsewhere (vuer_oss §3 warning, vuer_cv §3 warning, vuer_css §3). The compose files below mount host source into prebuilt images pulled from harbor.techteamer.com.

---

1. The three run modes

Mode	Driver	Compose / config	Source
(a) Full local-dev environment	bin/facekom CLI	run/*.yml (symlinked docker-compose.yml); build side build/facekom.yml, build/services.yml, build/qtsp.yml, build/cv_dev.yml	vuer_localdev/bin/facekom, bin/locations.cfg, build/facekom.yml
(b) vuer_docker compose runtime	bin/vuer.sh CLI (or raw docker-compose -f …)	dev.yml + per-service vuer-oss.yml/vuer-css.yml/esign-*.yml/vuer-cv*.yml/services.yml/facekom-library.yml	vuer_docker/bin/vuer.sh, dev.yml, vuer-oss.yml, README.md
(c) One service in local “dev” mode	supervisord inside the service container	supervisor_<svc>_dev.conf + nginx_<svc>_dev.conf + package.json scripts	vuer_oss/supervisor_vuer_oss_dev.conf, nginx_vuer_oss_dev.conf

These are layered, not exclusive: mode (a)/(b) start containers, and inside each app container mode (c)‘s supervisord runs the actual processes. “dev” vs “docker” is just which supervisor_<svc>_*.conf / NODE_ENV the container boots with.

vuer_localdev (mode a) and vuer_docker (mode b) are two generations of the same idea — both are compose-based image factories + runtimes for the same product. vuer_localdev is the newer cluster-capable env (RabbitMQ + PostgreSQL clusters, QTSP, security-world/HSM); vuer_docker is the long-standing single-node dev/CI env. See build-deploy-release for the build-pipeline lineage.

---

2. Mode (a): bin/facekom — full local-dev environment

vuer_localdev/bin/facekom is a bash dispatcher: it resolves a <command> <subcommand> to a shell function facekom_<command>_<subcommand> (or facekom_<command>) and runs it (bin/facekom:28-50,296). On every invocation it first sources bin/locations.cfg and runs bin/devenv_setup.sh (bin/facekom:8-9,294).

What bin/facekom actually does (verified from the script)

• Picks the compose binary: prefers docker compose (v2), falls back to docker-compose; aborts if neither works (bin/facekom:12-26). README recommends installing the docker-compose-plugin and using v2 (README.md:33-50).
• docker_command() is the core: it builds <compose> --env-file <.env> [--env-file <local.env>] -f <yml> <subcommand> "$@", echoes it, then runs it. The env file is always $ENV_FILE (PROJECT_DIR/.env), plus local.env if present (bin/facekom:115-139, paths from bin/locations.cfg:35-36).
• Runtime vs build dirs: runtime compose lives in RUN_DIR=$PROJECT_DIR/run; build compose in BUILD_DIR=$PROJECT_DIR/build (bin/locations.cfg:21-24).

facekom command	Effect	Source
facekom version	prints docker / compose versions + which compose binary is used	bin/facekom:54-63
facekom env	dumps resolved workspace/runtime dirs + the default compose symlink target	bin/facekom:65-86
facekom use <name>	symlinks run/<name>.yml → run/docker-compose.yml as the default runtime compose	bin/facekom:88-99
facekom pull [svc]	<compose> … -f run/docker-compose.yml pull	bin/facekom:170-172,115-139
facekom up [svc] / facekom run [svc]	… up -d (in RUN_DIR)	bin/facekom:180-186
facekom down / facekom stop [svc]	… down / … stop	bin/facekom:188-194
facekom status	docker ps formatted table	bin/facekom:176-178
facekom build [target]	no-arg → runs bin/build.sh; else <compose> -f build/<target>.yml build --progress plain	bin/facekom:143-149
facekom rebuild <target>	build --no-cache	bin/facekom:151-153
facekom push [target]	push images (loops build/*.yml, skipping cv_dev)	bin/facekom:155-168
facekom bash <ctr> / facekom exec <ctr> …	docker exec -it <ctr> bash / arbitrary	bin/facekom:236-246
facekom sv <ctr> …	docker exec -it <ctr> supervisorctl …	bin/facekom:250-258
facekom mq <ctr> …	docker exec -it <ctr> rabbitmqctl …; facekom mq_cluster_destroy resets the 3 cluster nodes	bin/facekom:262-279
facekom pg_cluster_status / …_switchover	pg_autoctl show state / perform switchover on pgmonitor-1	bin/facekom:282-292
facekom log …	search/follow/tail logs under RUNTIME_LOG_DIR	bin/facekom:198-232

bin/devenv_setup.sh — environment bootstrap (idempotent)

Runs on every facekom call (and standalone with a verbose arg). It only creates dirs / symlinks if missing (ensure_dir/ensure_link, bin/devenv_setup.sh:25-53):

• Creates the workspace + opensource/fork project roots (bin/devenv_setup.sh:56-58).
• Creates ~/bin and symlinks ~/bin/facekom → the repo’s bin/facekom (so facekom is on PATH) (bin/devenv_setup.sh:61-62, bin/locations.cfg:6-8).
• Creates the runtime data dirs: records, archive, import_data, the three RabbitMQ cluster nodes (rabbitmq-cluster-1..3), avast, and the PostgreSQL cluster dirs (postgresql-cluster-pgmonitor-1, postgresql-cluster-pgnode-1, postgresql-cluster-pgnode-2) (bin/devenv_setup.sh:65-77). (mssql/oracledb lines are commented out.)

Mode (a) is cluster-shaped: RabbitMQ runs as a 3-node cluster (mgmt consoles on :15672/:15673/:15674, admin/admin — README.md:80-85) and PostgreSQL via pg_autoctl monitor + 2 data nodes. The facekom mq_cluster_destroy / pg_cluster_* helpers exist precisely because of this topology (bin/facekom:272-292).

build/facekom.yml & build/cv_dev.yml (build side)

build/facekom.yml defines the app build services vuer-oss, vuer-css, janus — each FROM its app/<svc>/Dockerfile with build args including APP_VERSION=${VUER_VERSION}, UID/GID=${DEV_UID}/${DEV_GID}, MQ_CLIENT=*.rabbitmq.local, and NODE_VERSION=${NODE_VERSION} (build/facekom.yml:4-47). The CV dev image is built separately: build/cv_dev.yml builds vuer_cv from app/vuer_cv/Dockerfile, mounting host source via an src=/workspace/vuer_cv additional build context, tagging …/vuer_cv_dev:${CV_DEV_TAG}.… (build/cv_dev.yml:4-19). (build/cv_dev_fk.yml is the FaceKom-flavored CV image variant, cv_dev_fk.yml:4-19.)

bin/build.sh (run by facekom build with no args) is the full image build + CA/cert flow — it (re)generates self-signed certs via rabbitmq tls-gen, optionally bumps SECURITY_NUMBER + per-image *_BUILD_NUMBER in .env, then builds services → qtsp → facekom image sets (bin/build.sh:116-147). Image versioning/SECURITY_NUMBER semantics are documented in build-deploy-release and vuer_localdev/Build.md.

---

3. Mode (b): vuer_docker compose runtime (bin/vuer.sh)

vuer_docker/bin/vuer.sh is the day-to-day dev runtime wrapper. Like facekom it dispatches <cmd> <subcmd> → vuer_<cmd>_<subcmd> (bin/vuer.sh:25-47,503). Many subcommands operate inside the already-running containers via docker exec.

What bin/vuer.sh does (verified)

• vuer docker up|down|restart|update — the only commands that touch compose. They cd /workspace/vuer_docker and run, hard-coded, docker-compose -f esign-css.yml -f esign-oss.yml -f vuer-css.yml -f vuer-oss.yml -f dev.yml <up -d|down|restart> (bin/vuer.sh:299-336). docker update also git pulls + pulls images first (bin/vuer.sh:327-335).
• vuer server start|stop|restart|status [process] — docker exec <container> supervisorctl <action> [process|all]; accepts the meta-targets vuer (= vuer_oss+vuer_css) and esign (= esign_oss+esign_css) (bin/vuer.sh:198-287). This is how you bounce individual Node processes.
• vuer dev build|install|reinstall|watch — docker exec <ctr> running npm run build / yarn / rm -r node_modules && yarn / npm run watch (bin/vuer.sh:428-501).
• vuer checkout <branch> [project] — the customization-branch workflow: assert clean tree → server stop → git checkout+pull → yarn → server start → npm run build (bin/vuer.sh:126-140). Known branches include devel + the customization/* set (bin/vuer.sh:109-122).
• vuer db init <ctr> — docker exec <ctr> bin/db/create_user admin … operator … (seeds an admin + operator) (bin/vuer.sh:185-190).
• vuer log [project] [file] — tail -qF /workspace/vuer_docker/workspace/log/<project>/<file>.log (bin/vuer.sh:340-347).
• vuer workspace init — mkdir -p records ocr archive under /workspace (bin/vuer.sh:156-168).

vuer.sh asserts you are in a project root for some commands: only vuer_oss, vuer_css, esign_oss, esign_css are valid project names (bin/vuer.sh:5-23). cd and wipe/init are stubs ("not implemented").

The compose files (dev.yml + per-service)

dev.yml provides the shared infrastructure containers, all network_mode: host (dev.yml:1-57):

Service (dev.yml)	Image / build	Notes	Source
rabbitmq	built from ./rabbitmq/Dockerfile	message bus; mounts vuer_mq_cert	dev.yml:4-16
postgresql	built from ./postgresql	primary DB; DB_NAME="vuer_oss,esign_oss,vuer_oss_test", user/pass dev/dev, data in /workspace/postgresql_data	dev.yml:18-33
nginx_proxy	nginx:stable	front proxy (ssl/security/gzip/proxy confs + proxy_servers.conf)	dev.yml:35-46
syslog-ng	balabit/syslog-ng:3.29.1	log aggregation	dev.yml:48-56

Per-service compose files add the app containers, all network_mode: host, mounting host source into the prebuilt harbor images:

• vuer-oss.yml — janus (built) + vuer_oss (image …/vuer_oss:${VUER_VERSION}.${VUER_BUILD_NUMBER}-${SECURITY_NUMBER}), mounting /workspace/vuer_oss, records, archive, import_data, vuer_mq_cert, test_resources, certs, and TSA test CAs; sets DEV_DOMAIN (vuer-oss.yml:1-49).
• vuer-css.yml, esign-oss.yml, esign-css.yml, facekom-library.yml, services.yml (pdfservice + nyilvantarto, services.yml:4-34), clamav.yml, portal-css.yml — analogous per-service definitions (file list: git -C vuer_docker ls-files | grep '\.yml$').
• CV: vuer-cv.yml runs the prebuilt CV image (…/vuer_cv:${VUERCV_TAG}.…, vuer-cv.yml:4-18); vuer-cv-dev.yml runs vuer_cv_dev mounting host /workspace/vuer_cv for development (vuer-cv-dev.yml:4-18); vuer-cv-gpu.yml adds NVIDIA env. README §“vuer_cv development” + “GPU Support” cover the pip-install/supervisorctl restart all loop and the nvidia-container-runtime setup (README.md:404-475).

macOS uses a dedicated macos-vuer-dev.yml instead of host networking: it defines explicit oss/css bridge networks (172.16.238.0/24 / 172.16.239.0/24), depends_on ordering (postgresql → rabbitmq → janus → vuer_oss → vuer_css → nginx_proxy), publishes ports (5432, 80/443), and mounts repos from ~/repositories/* with :cached (macos-vuer-dev.yml:1-145). Host-mode compose files won't work on Docker Desktop for Mac.

Raw compose recipes (from README — common tasks)

The README documents the bare docker-compose invocations that vuer.sh wraps (README.md:353-389): start shared infra docker-compose -f dev.yml up -d; start vuer docker-compose -f vuer-css.yml -f vuer-oss.yml up -d; start esign -f esign-css.yml -f esign-oss.yml up -d; pull CV -f vuer-cv.yml pull. Post-install each app container needs yarn && yarn build (or pnpm install && pnpm build for facekom_library) run inside it (README.md:315-351).

---

4. Mode (c): per-service supervisord process model

Each app repo ships two supervisord profiles — supervisor_<svc>_dev.conf (local dev, NODE_ENV=dev) and supervisor_<svc>_docker.conf (container, NODE_ENV=docker) — plus matching nginx_<svc>_{dev,docker}.conf. The program set is identical between dev and docker; the differences are NODE_ENV, log sizes, and the user for nginx/redis (root in dev vs techteamer in docker — supervisor_vuer_oss_dev.conf:7,23 vs supervisor_vuer_oss_docker.conf:7,23). To run a single service in “dev”, you launch its container/image with the _dev conf (or copy it to /etc/supervisor), and supervisord starts everything.

vuer_oss = 7 Node processes + nginx + redis

supervisor_vuer_oss_dev.conf defines (each directory=/workspace/vuer_oss, user=techteamer, autorestart=true, exitcodes=0,2, stopsignal=TERM):

Program	Command	Role	Source
nginx	/usr/sbin/nginx -g "daemon off;"	reverse proxy / static	…dev.conf:5-19
redis	redis-server /etc/redis/redis.conf	bundled redis	…dev.conf:21-27
vuer_oss	node server.js	main web/socket/RPC server (migrates DB on boot)	…dev.conf:29-48
vuer_integration_log	node integrationLog.js	integration-log RPC sink	…dev.conf:50-69
vuer_media	node media.js	media/streaming web server	…dev.conf:71-90
vuer_oss_convert	node convert.js	converter daemon (queue-convert)	…dev.conf:92-111
vuer_cron	node cron.js	scheduled jobs	…dev.conf:113-132
vuer_background	node background.js	reports/exports/archive/recognition	…dev.conf:134-153
vuer_oss_storage	node storage.js	storage-engine worker	…dev.conf:155-174

That’s 7 Node processes (server, integrationLog, media, convert, cron, background, storage) + nginx + redis. Full per-process responsibilities, boot recipe, and the “only server.js migrates the DB / RabbitMQ is fail-fast” gotchas are in vuer_oss §3 & §10.

Ports & routing (nginx_vuer_oss_dev.conf): nginx listens :20080 (dev) with server_name ~^oss\.(.+)\.dev$; upstreams are vuer-oss 127.0.0.1:10081 (web), socketio-oss 127.0.0.1:10080 (/socket.io), vuer-oss-media 127.0.0.1:10079 (records/screenshots/emrtd-photo/…); static /js /css /img … cached 1y; everything else → :10081 (nginx_vuer_oss_dev.conf:1-95). The _docker nginx variant uses the same 10081/10080/10079 upstreams but listens on the container’s public port (see vuer_oss §3).

vuer_css

supervisor_vuer_css_dev.conf defines nginx + redis + a single vuer_css Node program (node server.js, directory=/workspace/vuer_css, NODE_ENV=dev) (supervisor_vuer_css_dev.conf:5-48). CSS is a lighter, customer-facing node — one server process, not seven. Ports: web vuer-css 127.0.0.1:10083, socket socketio-css 127.0.0.1:10082, plus the Web-SDK-demo vuer-css-sdk 127.0.0.1:10084; dev nginx listens :30080 (main) and :30081 (sdk-demo) (nginx_vuer_css_dev.conf:1-11,86). Details in vuer_css §3.

eSign mirrors Vuer: esign_oss/esign_css/portal_css each carry their own supervisor_<svc>_{dev,docker}.conf + nginx_<svc>_{dev,docker}.conf with the same dev/docker split. See esign_oss, esign_css, portal_css.

vuer_cv = HTTP + WebSocket + ~10 model workers (Python)

vuer_cv is not Node and not supervised the same way — it uses its own supervisor_vuer_cv_docker.conf and a Python boot chain (docker_entrypoint.sh → prepare.sh → supervisord -n). It runs nginx, redis, the HTTP app (app_http.py under uWSGI), the WebSocket app (app_websocket.py), and a fleet of per-model RPC worker entrypoints — app_face, app_card_detector, app_ocr, app_text_detector, app_detectron2, app_mrz, app_pad, app_onnx (i.e. app_http + app_websocket + 8 model workers = 10 app_*.py entrypoints, several scaled by numprocs from config). Ports: nginx :4080, uWSGI socket :40081, WS workers 40082+worker. Redis is the in-container RPC bus over a unix socket — no RabbitMQ. Full detail (entrypoint table, scaling env vars, env-version lock) in vuer_cv §3, §7, §10.

Running only the main process is not "running the service." For vuer_oss, node server.js alone leaves media/convert/cron/background/storage/integration-log dead (vuer_oss §10). For vuer_cv, you need the model workers up or HTTP/WS calls block waiting for an RPC queue that never answers. Always start the whole supervisord set.

---

5. Node runtime

The CV worker fleet is Python (interpreter fixed by the image — vuer_cv §2). The Node services use a single Node major across the board:

• Core apps run Node 22. vuer_oss requires node >=22.18.0 (vuer_oss/package.json:28-30), vuer_css requires node >=22.0.0 (vuer_css/package.json engines). CI matrices test 22 & 24 (vuer_oss §2, vuer_css §2). build-deploy-release confirms the core image line is Node 22.
• The image’s Node version is a build arg: build/facekom.yml passes NODE_VERSION=${NODE_VERSION} into the app Dockerfiles (build/facekom.yml:18,33); vuer_localdev/.env sets NODE_VERSION="22.x" (.env:48).
• vuer_docker/install/ ships three pinned installers — install-nodejs-20.sh, install-nodejs-22.sh, install-nodejs-24.sh — each identical except NODE_VERSION="20.x"|"22.x"|"24.x"; all add the NodeSource RPM repo (rpm.nodesource.com/pub_${NODE_VERSION}/…) then install via two separate microdnf calls — microdnf -y install python3 followed by microdnf -y install nodejs --disablerepo="*" --enablerepo="nodesource-nodejs" (install/install-nodejs-22.sh:7,10-24, the two install calls at :23-24; same shape in the 20/24 variants). install/tools/install-nodejs-22.sh is the copy used by the testenv image. The generic install/install-nodejs.sh and the per-version scripts are the source of truth for which Node lands in each image.

The three install-nodejs-{20,22,24}.sh scripts exist so different components/eras can pin a Node major without code changes; core Vuer apps select 22. Picking 20 or 24 is a per-Dockerfile choice driven by the NODE_VERSION arg.

---

6. Bring up the full stack (step list, from the scripts)

These steps are transcribed from the scripts/README for reference. This note does not execute them.

Mode (b) — vuer_docker (the common dev path):

1. Prereqs / DNS / certs / harbor login — your dev domain + /etc/hosts entries and docker login https://harbor.techteamer.com; check out the cert repo (README.md:1-122). Host/URL specifics → dev-environment.
2. Clone the app repos into /workspace (vuer_oss, vuer_css, esign_oss, esign_css, and for CV vuer_cv) (README.md:123-164).
3. Pull images: docker-compose -f dev.yml -f vuer-css.yml -f vuer-oss.yml pull (+ esign-*.yml, vuer-cv.yml) (README.md:140-164).
4. Start shared infra first: docker-compose -f dev.yml up -d → brings up postgresql, rabbitmq, nginx_proxy, syslog-ng (dev.yml:4-56; README “Start common containers only” README.md:355-359). These are the dependencies that must be up first (see §7).
5. Start the apps: docker-compose -f vuer-css.yml -f vuer-oss.yml up -d (+ esign) — or, equivalently, vuer docker up which composes esign-css esign-oss vuer-css vuer-oss dev together (bin/vuer.sh:311-317).
6. Post-install inside each container: docker exec -it vuer_oss bash → yarn && yarn build; repeat for vuer_css, esign_css, esign_oss (README.md:315-343). vuer db init vuer_oss seeds admin/operator (bin/vuer.sh:185-190).
7. (optional) common services / library: services.yml (pdfservice, nyilvantarto) and facekom-library.yml up (README.md:166-183).
8. Iterate: vuer dev watch <project> to rebuild on change; vuer server restart <project> [process] to bounce a supervised process; vuer log <project> to tail.

Mode (a) — vuer_localdev:

1. bin/devenv_setup.sh verbose then confirm which facekom (README.md:25-31).
2. facekom version to verify compose v2 (README.md:39-48).
3. (first time / image changes) facekom build → bin/build.sh regenerates CA/certs + builds services/qtsp/facekom image sets (bin/build.sh:130-147); facekom push to publish.
4. facekom use <name> to pick the default run/*.yml, then facekom pull and facekom up.
5. facekom status / facekom sv <ctr> status / facekom log … to observe; cluster helpers facekom mq …, facekom pg_cluster_status for the RabbitMQ/PostgreSQL clusters.

---

7. Dependencies that must be up first

Verified from the compose files / boot code:

• PostgreSQL — the system of record, owned by vuer_oss (only server.js migrates on boot — vuer_oss §10). In dev.yml it serves DBs vuer_oss,esign_oss,vuer_oss_test (dev.yml:29-33); macos-vuer-dev.yml makes everything depends_on it first (macos-vuer-dev.yml:28-29,63,87,111).
• RabbitMQ — the primary integration bus for the Node services; fail-fast (a closed AMQP connection triggers process.exit(2) in vuer_oss/vuer_css). No broker → no boot (vuer_oss §9-10, inter-service-comms). Present in both dev.yml (single node) and vuer_localdev (3-node cluster). In macos-vuer-dev.yml, janus/apps depends_on rabbitmq (macos-vuer-dev.yml:63-64,111-112).
• Redis — required by the CV service as its in-container RPC bus (unix socket, started by CV’s own supervisord — vuer_cv §9), and bundled per-container as a redis supervisord program for vuer_oss/vuer_css (supervisor_vuer_oss_dev.conf:21-27). For vuer_oss a shared Redis is optional (only if HARedis.config is set — vuer_oss §9); vuer_css uses Redis for sessions (vuer_css §2).
• Janus (WebRTC media) is a startup dependency of vuer_oss in the macOS compose (vuer_oss depends_on janus, macos-vuer-dev.yml:111-112) and is bundled in vuer-oss.yml (vuer-oss.yml:4-21). See vuer_oss §9 and architecture-overview.

Startup order, in short: PostgreSQL + RabbitMQ (+ Redis for CV) → Janus → vuer_oss → vuer_css / esign → CV. dev.yml (shared infra) is therefore brought up before the per-service compose files. Host-mode compose files don’t encode depends_on, so on Linux the operator enforces order by starting dev.yml first (step 4 above); the macOS bridge-network compose encodes it explicitly.

---

Unverified / gaps

• run/*.yml contents (mode a runtime): the vuer_localdev/run/ directory’s compose files were not enumerated/read here — bin/facekom resolves them dynamically via facekom use/docker-compose.yml symlink, and the clone listing only exposed build/*.yml. The set of runtime services (and exact RabbitMQ/PostgreSQL cluster topology containers) is described from devenv_setup.sh dirs + README, not from a runtime compose file.
• Exact vuer_localdev infra image versions: .env shows RABBIT_VERSION_NUMBER=3.13.2, POSTGRESQL_VERSION_NUMBER=15.4, JANUS_VERSION_NUMBER=0.13.4, NODE_VERSION=22.x (vuer_localdev/.env), which differ from vuer_docker/.env (RABBIT 4.1.4, POSTGRESQL 16.6); not reconciled across the two envs here.
• eSign / portal_css supervisor program sets: stated to mirror Vuer (dev/docker split) from the file inventory; the individual esign_*/portal_css supervisor_* programs were not opened in this pass — see their repo notes.
• nginx_proxy (front) routing in dev.yml/macos: proxy_servers.conf maps the public *.facekomdev.net hostnames to the per-service nginx ports; that mapping file was not read here (env/URL detail belongs to dev-environment).
• facekom build sub-targets (services, qtsp, facekom) enumerate to build/*.yml; only facekom.yml, cv_dev.yml, cv_dev_fk.yml were read — services.yml/qtsp.yml (build side) contents not opened.

---

Sources

Files actually read:

• vuer_localdev (/Users/levander/coding/facekom-v2-clones/vuer_localdev): README.md, Build.md, bin/facekom, bin/devenv_setup.sh, bin/build.sh, bin/monitoring.sh, bin/locations.cfg, build/facekom.yml, build/cv_dev.yml, build/cv_dev_fk.yml, .env (grep), git ls-files.
• vuer_docker (/Users/levander/coding/facekom/vuer_docker): README.md, bin/vuer.sh, dev.yml, vuer-oss.yml, vuer-cv.yml, vuer-cv-dev.yml, macos-vuer-dev.yml, services.yml, install/install-nodejs-20.sh, install/install-nodejs-22.sh, install/install-nodejs-24.sh, .env (grep), git ls-files.
• Per-service profiles: vuer_oss/supervisor_vuer_oss_dev.conf, vuer_oss/supervisor_vuer_oss_docker.conf, vuer_oss/nginx_vuer_oss_dev.conf, vuer_css/supervisor_vuer_css_dev.conf, vuer_css/nginx_vuer_css_dev.conf; vuer_oss/package.json (engines, grep), vuer_css/package.json (engines + scripts).
• Cross-linked verified docs (not re-derived): vuer_oss (7-process model, ports 10081/10080/10079, gotchas), vuer_css (ports 10083/10082/10084), vuer_cv (app_http.py + app_websocket.py + 8 model workers, Redis RPC), build-deploy-release (Node 22, image lineage).