Updated: October 8, 2026

Sections 1–3 describe GenDash and pushgen. Section 4 describes DashApps and pushdash. For DashApps page content, edit /Users/marc/Obsidian/DashApps/Notes (or Images) as the source of truth. pushdash syncs that local copy over the server’s staging inputs; its default run also publishes the website source. For local-only edits, do not run pushdash.

Hugo file GenDash: Obsidian to Hugo Automated Publishing Guide

This guide outlines the infrastructure and configuration required to sync an Obsidian vault across multiple devices and automate the publishing process to a Hugo website via Cloudflare Pages.

1. Multi-Device Sync (The Git & Web Layer)#

To sync your notes between computers and view them on mobile devices without the overhead of real-time database sync engines:

1.1. Between Computers (Mac Studio & MacBook Pro/Air)#

We use the Obsidian Git plugin to synchronize GenDash vaults directly via GitHub.

• Repository: git@github.com:marcoue/GenDash.git
• Shortcuts:
  • Cmd + S: Commit & Push local changes to GitHub.
  • Cmd + Shift + S: Pull remote changes from GitHub.

1.2. On Mobile Devices (iPhone & iPad)#

To avoid complex sync engines and conflict loops, Obsidian is not installed on mobile. Instead, notes are accessed via the browser using the self-hosted Hugo GenDash website:

• Read Access: Simply browse your local Hugo GenDash web server instance. It provides instant, formatted, searchable access to all your notes with zero configuration, zero battery drain, and zero storage overhead on your phone/tablet.

2. The Content Bridge & Git Publisher (Mac to Web)#

The publishing pipeline is consolidated into a single master script run from your Mac Studio. It handles preprocessing multilingual notes (converting Wikilinks and processing images), syncing them to the Proxmox VM, triggering the Hugo build/deployment, and backing up your GenDash vault to GitHub.

Location: /Users/marc/Scripts/MacOS/sync-obsidian-gendash-hugo.sh

A mirror copy of the script is also maintained at /Volumes/Software/Software/Scripts/MacOS/

2.1. Script Execution Workflow#

Running the script executes the following sequential steps:

1. Processes Markdown: Parses local en, fr, and es notes into /tmp/gendash_sync to convert Obsidian wikilinks [Page Name](/posts/page-name/) and ![Image.png](/images/Image.png) into standard Hugo relative markdown links and image paths.
2. Syncs Content: Runs rsync to mirror the processed notes and images to the Proxmox Hugo VM.
3. Triggers Deploy: SSHs into the VM and runs the remote publication script (publish-hugo-gendash.sh), pushing built site changes to GitHub to trigger Cloudflare Pages.
4. Backs Up Vault: Git commits and pushes your local GenDash vault to GitHub (GenDash repository).

If any step in the pipeline fails, the script aborts immediately to prevent desynchronization.

2.2. Command Usage#

• Full Sync, Publish & Vault Backup (Default):

  pushgen
  # (Alias for: bash /Users/marc/Scripts/MacOS/sync-obsidian-gendash-hugo.sh)

• Sync-Only (No Build / No Git Backup):

  pushgen --sync-only
  # or: pushgen -s

2.3. Configuration & Alias Setup#

To configure the pushgen alias on your Mac Studio:

# Add alias to ~/.zshrc
echo "alias pushgen='bash /Users/marc/Scripts/MacOS/sync-obsidian-gendash-hugo.sh'" >> ~/.zshrc
source ~/.zshrc

2.4. Mac Studio Cron Schedule#

If you want automatic syncing and deployment on a schedule:

crontab -e

# Full publish & backup at 12:10 PM and 8:10 PM daily
10 12 * * * bash /Users/marc/Scripts/MacOS/sync-obsidian-gendash-hugo.sh > /dev/null 2>&1
10 20 * * * bash /Users/marc/Scripts/MacOS/sync-obsidian-gendash-hugo.sh > /dev/null 2>&1

3. The Remote Build Script (Linux VM)#

The remote Proxmox VM hosts the source files and publishes changes to the GitHub GenDash repo.

Location: /mnt/Software/Software/Scripts/Linux/publish-hugo-gendash.sh

You do not need to SSH to run this script manually anymore, as the Mac pushgen script triggers it over SSH automatically. However, the VM cron schedule still runs independently as a backup.

3.1. Article Date Display#

The GenDash Hugo project uses the Blowfish theme. Its article configuration enables showDateUpdated in /home/marc/hugo/gendash/config/_default/params.toml, so pages display their lastmod date in addition to the original publication date. The publish script stages this configuration file so the setting is included in GitHub/Cloudflare deployments.

3.2. Proxmox VM Cron Schedule#

# HP1Docker cron job
crontab -e

# Build and publish Hugo site at 12:15 PM and 8:15 PM daily
15 12 * * * bash /mnt/Software/Software/Scripts/Linux/publish-hugo-gendash.sh
15 20 * * * bash /mnt/Software/Software/Scripts/Linux/publish-hugo-gendash.sh

4. DashApps.app: source of truth, sync, and publishing#

DashApps has a separate workflow from the GenDash pushgen process above. pushgen publishes GenDash only. pushdash syncs and publishes DashApps only.

4.1 What pushdash does#

The Mac vault is the durable source for editable page content and images. On the server, input/Notes and input/Images are synced staging copies, not independent sources of truth. The converter regenerates tracked Hugo content/ and image files from those inputs; direct edits to generated content can be overwritten on the next conversion.

The default pushdash workflow:

1. Syncs the local DashApps Notes/ and Images/ into the server’s ignored input/ folders, replacing their current contents.
2. Converts the synced notes and images into the Hugo website’s generated content.
3. Builds and validates the Hugo site on HP1Docker.
4. Commits and pushes the website source to marcoue/DashApps.app; Cloudflare Pages then deploys that revision.
5. Backs up the local vault’s notes and images to marcoue/Obsidian-DashApps.app.

Options still sync from the Mac first:

• pushdash --sync-only transfers the local notes and images to the server without building or publishing. It still replaces the server’s synced inputs.
• pushdash --build-only syncs, converts, and builds, but does not commit or push either repository. It still replaces the server’s synced inputs.

4.2 Choose where to edit before making changes#

• Local-only content edit: edit the DashApps vault’s Notes/ or Images/. Do not run pushdash; the change stays local and is not published.
• Publish local content: run pushdash only when the local vault is the version intended for publication. Its default action pushes the website source to GitHub and backs up the vault.
• Server-only Hugo code edit: edit layouts, configuration, or build scripts in /home/marc/hugo/dashapps. Use the server’s scripts/publish-dashapps.sh --build-only to convert/build without committing or pushing. A normal run commits and pushes the website source.
• Server-only note edit: treat files in input/Notes as temporary. A later pushdash will replace them with the Mac vault copy. Copy any server-only content you need back into the local vault before running pushdash.
• Generated content/ edit: do not use this as the durable content edit. The conversion step rewrites it from input/Notes.

Before running pushdash, check that the local vault contains every content change you want to keep. If the goal is local-only work, make the edits in the vault and stop there.

4.3 DashApps LAN preview on HP1Docker#

The DashApps Hugo project has a persistent preview service on HP1Docker (10.1.2.202). It starts at boot and serves http://10.1.2.202:1314. The service reads /home/marc/hugo/dashapps and runs as marc.

Service file: /etc/systemd/system/hugo-dashapps-preview.service.

StateDirectory=hugo-dashapps-preview
StateDirectoryMode=0750
Environment=HUGO_RESOURCEDIR=/var/lib/hugo-dashapps-preview/resources
ExecStart=/usr/local/bin/hugo server --bind 0.0.0.0 --baseURL http://10.1.2.202 --buildDrafts --disableFastRender --ignoreCache --noHTTPCache --gc --destination /var/lib/hugo-dashapps-preview/public --port 1314

Systemd creates /var/lib/hugo-dashapps-preview/ for this service’s generated preview output and asset resources. This keeps preview writes separate from the existing DashApps public/ and resources/ directories. The service retries failed starts after 5 seconds, with a per-service limit of 3 attempts in 60 seconds.

Check or manage the preview service on HP1Docker:

systemctl status hugo-dashapps-preview.service
journalctl -u hugo-dashapps-preview.service
sudo systemctl stop hugo-dashapps-preview.service
sudo systemctl start hugo-dashapps-preview.service

If the service reaches its retry limit, fix the logged cause, then clear its failed state before starting it:

sudo systemctl reset-failed hugo-dashapps-preview.service
sudo systemctl start hugo-dashapps-preview.service

See DashApps.app Migration for the broader migration record and architecture.