From debaeb2b6f580edd1de5f0f9a3c1e7867d6844bf Mon Sep 17 00:00:00 2001
From: Rokojori Sunday, 12 July 2026
- Full project directory restructure — source/, build/app/, build/data/,
- source/pages/ with a copy-pages build step.
+ Full project directory restructure and first production deployment —
+ source/, build/app/, build/data/, source/pages/; Roject live at
+ roject.rokojori.com via nginx + systemd on Server A.
+ Roject deployed to Server A and served publicly at
+
+ Several build gaps were discovered and fixed during the deploy:
+ component CSS files were never in source control (moved to
+ Roject — Session Summary
First production deployment — roject.rokojori.com
+ https://roject.rokojori.com. Stack: Node.js 20,
+ ts-node running source/server/index.ts managed
+ by a systemd service, nginx as TLS-terminating reverse proxy with a
+ Let's Encrypt certificate, port 3000 kept closed at the IONOS firewall.
+ source/components/); vendor libraries were in the gitignored
+ build/app/vendor/ (moved to source/vendor/);
+ mkdirSync calls in the server lacked { recursive: true }
+ causing a crash on a fresh clone; and the library-ts browser
+ tsconfig.roject.json still referenced the old
+ public/ outDir instead of build/app/.
+ The copy script was also expanded to copy all non-TS static assets
+ (CSS, SVG, etc.) from all frontend source directories.
+
+ systemd is already present on every Linux server and integrates with
+ journalctl for log management. PM2 is easier for day-to-day
+ Node.js process management but adds an extra global dependency. For a
+ single-service deployment systemd is sufficient and keeps the server
+ dependency surface minimal.
+
+ CSS files, vendor libraries, and SVGs were historically placed directly
+ in public/ (gitignored) and never tracked. A fresh server
+ clone exposes this immediately — nothing in build/ exists
+ until the build runs, and the build can only copy what it finds in
+ source/. Moving all static assets to source/
+ makes them first-class source files and ensures a clean deploy from any
+ fresh clone.
+
@@ -121,7 +176,14 @@
source/library-ts/browser/tsconfig.roject.json — outDir updated
package.json — main and build script updated
.gitignore — replaced data/, storage/, public/ with build/
- source/server/ — all __dirname paths and library-ts imports updated
+ source/server/ — all __dirname paths and library-ts imports updated
+ source/components/*.css — moved from build/app/ into source control
+ source/vendor/ — vendor libs moved from build/app/ into source control
+ source/library-ts/browser/tsconfig.roject.json — outDir fixed in submodule, committed and pushed
+ scripts/copy-pages.js — expanded to copy all non-TS static assets from all frontend source dirs
+ source/server/db.ts, storage.ts — mkdirSync updated to use { recursive: true }
+ /etc/systemd/system/roject.service — new on Server A
+ /etc/nginx/sites-available/roject — new on Server A
Full directory restructure — source/, build/app/, build/data/db/, build/data/storage/, source/pages/ with copy-pages build step.
+Full directory restructure and first production deployment — source/, build/, source/pages/; Roject live at roject.rokojori.com via nginx + systemd.
<confirm-dialog> component replaces browser
confirm() for destructive actions (currently project deletion).
+
+ The app is deployed and publicly accessible at
+ https://roject.rokojori.com on Server A. nginx handles TLS
+ termination and reverse-proxies to the Node.js process managed by a
+ systemd service. Deployment is currently manual
+ (git pull && npm run build && systemctl restart roject);
+ CI automation is the remaining open item.
+
- Deploy the Node.js/Express app to a publicly reachable server and wire up a
- CI pipeline that builds, tests, and deploys automatically on push. The app's
- file-based storage and no-database design make it straightforward to host on
- any VPS: nginx as reverse proxy, PM2 or a systemd service for the Node.js
- process. CI can run as a self-hosted Gitea/Forgejo Actions runner (matching
- the existing self-hosted git remote) or mirror to GitHub Actions. This is
- infrastructure work rather than feature work — it should be done once and early
- because everything else ships faster and more safely once a real deployment
- target and regression-catching pipeline exist.
+ The server is deployed and running at https://roject.rokojori.com
+ (nginx + systemd + Let's Encrypt on Server A). What remains is automating the
+ deploy on push: a Gitea Actions runner installed on Server A registers with the
+ repo on community.rokojori.com and runs a workflow that pulls,
+ builds, and restarts the service on every push to main. This is the last piece
+ that turns the manual deploy into a proper CI/CD pipeline.