Levandor

Dev-box deploy recipe — testing an InstaCash eSign release

4 min read

How to point the shared FaceKom dev box at an InstaCash eSign release and smoke-test it. The box is normally running Raiffeisen, so testing InstaCash eSign means re-aligning the whole partner chain to InstaCash, not just the two eSign repos. Validated against eSign 1.3.0.11 on 2026-06-26 (on the old on-prem box).

Host changed (2026-07-01) — run this on fk-dev, not ssh Facekom

This recipe was validated on the on-prem box (ssh Facekom = lederera-447-fk-hardver), which is now decommissioned (offline since ~2026-06-27). The recipe still applies unchanged — run it on the fk-dev Tailscale VM (command ssh ops@fk-dev.taild4189d.ts.net), which has the same bind-mounted /workspace/<repo> + supervisord layout. See dev-build-host and fk-dev-nusz-deploy-and-8959-verification.

For Agents

  • Host: fk-dev (command ssh ops@fk-dev.taild4189d.ts.net). Code is bind-mounted from /workspace/<repo> into each container — so you switch versions by git checkout on the host tree, then rebuild inside the container.
  • The trap: the box defaults to Raiffeisen. eSign does not run in isolation — esign_oss/esign_css talk over RabbitMQ to vuer_*. A mixed chain (InstaCash eSign + Raiffeisen vuer) is an invalid test. Align every repo to InstaCash.
  • The eSign ticket pins only the eSign version. It does not pin a vuer version — so use the latest InstaCash vuer tag for vuer_oss/vuer_css. pdfservice is partner-agnostic → leave it on main.
  • Rebuild in-container, not on host: docker exec <c> sh -c 'cd /workspace/<repo> && yarn install && yarn build', then supervisorctl restart all.

Chain alignment — what version each repo gets

All four app repos must move together

Leaving any vuer_* repo on Raiffeisen while the eSign repos are on InstaCash gives a cross-partner chain that does not represent a real InstaCash deployment.

RepoTargetWhy
esign_osstag instacash-1.3.0.11the release under test
esign_csstag instacash-1.3.0.11the release under test
vuer_osstag instacash-1.9.11.50latest InstaCash vuer; the eSign ticket pins no vuer version
vuer_csstag instacash-1.9.11.50latest InstaCash vuer; kept in lockstep with vuer_oss
pdfservicemain / 2.0.12partner-agnostic — no per-client tag, leave as-is

Why instacash-1.9.11.50 for the vuer side

The eSign release ticket (ASSICASH-92) only specifies the eSign component versions. eSign still needs a running vuer chain behind it, so pick the latest InstaCash vuer tag rather than guessing — that is instacash-1.9.11.50 (the most recent InstaCash vuer release; cf. ASSICASH-65 = FaceKom 1.9.11.50 in youtrack-tesztjegyzokonyv-attachment-recipe). pdfservice carries no partner tag, so its main/2.0.12 is correct for every partner.

Recipe

git fetch --tags first

The dev-box clones predate the instacash-1.3.0.11 tag (the local branches were checked out before the tag was cut on 2026-06-08). Without an explicit tag fetch, git checkout instacash-1.3.0.11 fails with pathspec … did not match. FaceKom clones also have narrowed fetch refspecs, so origin/<branch> refs can go stale — always fetch tags explicitly before checking one out.

Per repo on the host (/workspace/<repo>):

# 1. Preserve any work-in-progress on the box's current (Raiffeisen) checkout
git -C /workspace/<repo> stash
 
# 2. Make sure the tag exists locally, then check it out (detached HEAD)
git -C /workspace/<repo> fetch --tags
git -C /workspace/<repo> checkout <tag>

Tags: esign_oss/esign_css → instacash-1.3.0.11; vuer_oss/vuer_css → instacash-1.9.11.50; pdfservice stays put.

Then rebuild inside each container (source is bind-mounted, so the build must run where node/yarn live) and restart supervised processes:

docker exec <container> sh -c 'cd /workspace/<repo> && yarn install && yarn build'
# once all repos are built:
docker exec <container> supervisorctl restart all

Verify

Green = supervisord RUNNING + the two startup log lines + a 200 on the UI

  1. Process state — supervisorctl status shows every program RUNNING (not FATAL/BACKOFF).

  2. Startup log lines — each service’s log should show both:

    • RabbitMQ connection established
    • Web server is listening

  3. Listening ports (from esign):

    ServicePorts
    esign_oss10180 (socket), 10181 (admin UI), 10182 (external API)
    esign_css10183 (web), 10184 (socket)
    vuer_css10082, 10083

  4. UI reachable — esign_css returns HTTP 200 on :10183.

Gotchas

A "dirty" repo after checkout may be a false alarm

After git checkout <tag>, vuer_css reported as dirty — but the only change was an untracked .claude/ directory, not a real code modification. Confirm git status before assuming the checkout is wrong; an untracked tooling dir does not affect the build.

Old ERROR lines in logs may be historical

Log files persist across restarts. ERROR entries you see after restarting may be left over from the prior (Raiffeisen) run, not the new InstaCash boot. Check timestamps against the restart time before treating an error as current. The authoritative “it booted clean” signal is a fresh RabbitMQ connection established + Web server is listening pair dated after the restart.

Graph View

Backlinks