Editing Openai/693c70a4-9498-8011-87ee-efb5576cc53d (section)

==== The PDF (previous explanation) said: ====
* Repo 1: wsi-website → full source (local)
* Repo 2: caddy-wsi → deployment infra (Caddyfile, docker-compose.yml, site/)
* Missing link: no automated sync from wsi-website → caddy-wsi/site → VPS LOCAL wsi-website folder is com…

Then it proposed two options:
* Option A – Manual deployment
* Option B – CI/CD with GitHub Actions LOCAL wsi-website folder is com…

What we actually did on the VPS today is basically a simplified Option A, but with a slightly different folder name:
* Instead of ~/projects/caddy-wsi on the VPS, we’re using ~/projects/caddy.
* ~/projects/caddy/site is now your deployment folder.
'' You manually copied the built site into it: </code>`<code>bash cp -r ~/projects/caddy-wsi/site/'' ~/projects/caddy/site/ # later simplified to just assets/en/zh/index.html into ~/projects/caddy/site <syntaxhighlight>
So conceptually, nothing has changed from the original idea:

: 

The only differences are:
# The name of the deployment folder on the VPS is now caddy instead of caddy-wsi.
# We chose a pure static Caddy setup instead of running the wsi-website app container on port 8070.

==== Your question: ====

: 

From a professional DevOps perspective:
# Local (Dev) – Safe place to: - edit HTML/Markdown - run npm, Tailwind, MkDocs, etc. - test without breaking production
# GitHub (Repo) – Gives you: - version history (who changed what, when) - rollback (if something breaks, go back one commit) - collaboration (others can contribute safely) - security (no editing random files directly on a live server)
# VPS (Prod) – Only runs: - Caddy container - static built files in /usr/share/caddy - no npm install or Tailwind builds, no editing in the container

This pattern (Dev → Repo → Prod) is standard production practice in industry, especially if you later want:
* multiple environments (staging, production)
* CI/CD (GitHub Actions auto-deploy when you push)
* auditability and compliance

==== Right now the picture is: ====
* LOCAL - ~/projects/wsi-website → Source of truth
* VPS - ~/projects/caddy - Caddyfile, docker-compose.yml, site/ (static) - Container: wsi-caddy (serves /usr/share/caddy)

We manually synced content by copying the site files onto the VPS.

So the previous explanation and the current state are not actually conflicting — we just:
* switched to a simpler static deployment on the VPS, and
* we haven’t yet wired a formal pipeline from wsi-website → VPS.

==== Until we formalize CI/CD, you can think like this: ====
# Edit content only in LOCAL: - ~/projects/wsi-website/en/... - ~/projects/wsi-website/zh/... - assets, etc.
# Commit & push (for safety): </syntaxhighlight>bash cd ~/projects/wsi-website git add . git commit -m "Update homepage text" git push <syntaxhighlight>3. On VPS, sync into Caddy (manual step, which we can standardize later): </syntaxhighlight>bash # Example pattern (you already used similar commands) rsync -av --delete ~/projects/wsi-website/en/ ~/projects/caddy/site/en/ rsync -av --delete ~/projects/wsi-website/zh/ ~/projects/caddy/site/zh/ rsync -av ~/projects/wsi-website/assets/ ~/projects/caddy/site/assets/ cp ~/projects/wsi-website/index.html ~/projects/caddy/site/index.html </code>``
# Caddy doesn’t even need a restart for static files: - Just refresh https://whitestoneintel.com/en/ in your browser.

Later, if you want, we can make step 3 automated with GitHub Actions (Option B from the PDF), but it’s not required to keep the site running.

===== - No, we are not contradicting the previous design. =====
* The architecture is the same: Local source → Git → VPS deploy.
* What changed is just: - which folder on the VPS is used (caddy instead of caddy-wsi), and - we simplified to static Caddy instead of a full app container on port 8070.

If you’d like, next step I can directly write a small, clean “sync script” you run on VPS (e.g. sync-wsi-site.sh) so that your mental model is:

>