Updated: October 8, 2026

DashApps.app Migration#

Create one Obsidian vault and one Hugo website for all apps. Start with a new DashApps landing page and copies of the GenDash and GPSDash content. Keep both existing websites live throughout the transition.

This is a plan; unchecked tasks have not been completed or verified. Proposed names and paths below can be adjusted before implementation.

1. Confirm the destination and record the starting point#

• 1.1 Confirm the main domain: dashapps.app.
• 1.2 Confirm the existing GenDash domain: gendash.app.
• 1.3 Record the current GenDash and GPSDash setup from the actual systems; the September GPSDash scaffold note may no longer describe everything.
  • 1.3.1 Record each local vault path, current branch, and working-tree status.
  • 1.3.2 Record each vault’s GitHub repository, visibility, and default branch.
  • 1.3.3 Record each HP1Docker site folder and whether it is a Git checkout; record its remote if present.
  • 1.3.4 For each Cloudflare Pages project, record the project name, connected GitHub repository, production branch, build command, and output folder.
  • 1.3.5 For each app, verify the custom domain attached to its Pages project and record the public URL. Record any additional hostname or redirect configuration that affects the site.
  • 1.3.6 Record GenDash’s publishing scripts and schedules on the Mac and HP1Docker, including the times and host timezone.
  • 1.3.7 Record GPSDash’s publishing scripts and schedules on the Mac and HP1Docker; explicitly record when no scheduled job exists.

1.3 Starting-point inventory (checked 2026-10-08)#

Verified from the current local checkouts, publishing scripts, GitHub repository search, and read-only checks on HP1Docker (10.1.2.202):

The user confirmed the Cloudflare project and domain details are recorded and complete. The exact values were not provided in this note.

• 1.4 Back up both local vaults and both server projects, including unpublished work. Save the current deployment settings and a list of public page URLs.
• 1.5 Agree that the old vaults, repositories, Pages projects, domains, and publishing routines stay available during the transition.

2. Chosen structure and publishing routine#

Recommended arrangement:

Recommended routine: edit notes and images in the local Obsidian vault → sync them to the server → convert and build on the server → push the Hugo website source and generated content to GitHub → Cloudflare builds and publishes. The server owns the Hugo project, conversion, and build process; the local vault never contains Hugo files. Keep the vault backup repository separate from the website source repository.

• 2.1 Confirm this routine: the server owns the Hugo source and prepares each website repository update; Cloudflare owns the public deployment; the server also provides the LAN preview.
• 2.2 Keep English at /gendash/ and /gpsdash/; use /fr/gendash/, /es/gendash/, and equivalent GPSDash paths for translations. Add translated DashApps landing pages at /fr/ and /es/.
• 2.3 Use editable notes under Notes/en/gendash/, Notes/en/gpsdash/, and matching fr and es folders. Keep each app’s images under Images/gendash/ or Images/gpsdash/, with shared assets under Images/shared/.
• 2.4 Keep Hugo configuration, layouts, theme, and conversion/build scripts only in the server-side DashApps project and its website source repository. Keep editable notes and images in the local Obsidian vault; generate the Hugo content and image input on the server rather than maintaining two editable copies.

3. Create the local vault and clone the content#

• 3.1 Create /Users/marc/Obsidian/DashApps and open it as an Obsidian vault.
  • 3.1.1 Create /Users/marc/Obsidian/DashApps by cloning the empty GitHub repository.
  • 3.1.2 Verify the local origin fetch and push URLs are git@github.com:marcoue/Obsidian-DashApps.app.git.
  • 3.1.3 Open the folder as an Obsidian vault.
• 3.2 Copy the public EN, FR, and ES GenDash notes into their new app folders. Copy the matching images.
• 3.3 Repeat for GPSDash. Copy from the editable Notes/ and Images/ folders, rather than its generated Hugo content/ copy.
• 3.4 Bring over only useful Obsidian preferences. Do not copy old Git history or remotes, Private/, unrelated working notes, caches, Hugo files, or generated site output into the local DashApps vault. Only alwaysUpdateLinks and useMarkdownLinks were brought over; attachment location remains deferred to 3.8.
• 3.5 Include the existing GenDash and GPSDash DEV sections in the DashApps site. These are app content sections, not temporary staging builds.
• 3.6 Compare the copied files with the originals and record the copy date. Until launch, continue editing the old vaults and deliberately copy any later changes into DashApps.
• 3.7 Copy the five DEV pages for each app in English, French, and Spanish from Notes/<language>/dev/, including the DEV landing page, Quick Start Guide, User Manual, Contact, and Privacy Policy.
• 3.8 Configure the vault’s default attachment location after the content and images have been copied into their app folders.

4. Establish and build the shared Hugo site on the server#

• 4.1 On HP1Docker, create /home/marc/hugo/dashapps as a separate Hugo project, using the working GenDash project at /home/marc/hugo/gendash as the starting point. Reuse the needed Blowfish configuration, layouts, theme, and styling on the server; do not replace or modify either existing app project. Keep all Hugo files on the server and in the server-side website source repository, never in the local Obsidian vault.
• 4.2 Set the site title to DashApps and the production base URL to https://dashapps.app/. Configure English, French, and Spanish using Hugo’s multilingual setup.

5. Prepare the server-side GitHub repository and publishing process#

• 5.1 Create a separate DashApps website-source repository with a fresh history and connect it to /home/marc/hugo/dashapps on HP1Docker. The private marcoue/DashApps.app repository was empty when created; the server project now has a fresh main branch and this repository as origin. Do not connect it to the local Obsidian vault. Leave the existing repositories available.
• 5.2.1 The server-side Hugo scaffold and Blowfish theme are already in /home/marc/hugo/dashapps from 4.1.
• 5.2.2 Add the adapted conversion/build scripts and generated content inputs needed for Cloudflare builds. Exclude private notes, credentials, device-specific settings, logs, caches, and generated site output such as public/. Raw synced inputs are ignored under the server project’s input/; generated app content and images are committed; public/, logs, and Python caches are excluded.
• 5.3 Adapt the server-side Markdown/image conversion process for the combined folder structure. Sync editable notes and images from the local vault to the server, and make links resolve within the correct app and language, including pages with identical names such as “Contact”. The server converter writes language/app-specific content and image paths; content-wide link review remains in 6.3.
• 5.4 Provide a reproducible Hugo build command for Cloudflare to run from a fresh website-source checkout. The server publishing process must generate and include the content and image inputs Cloudflare needs before pushing that source revision. The repository README documents hugo --gc --cleanDestinationDir; Cloudflare is configured with hugo and public and completed a production build from GitHub.
• 5.5 Create one publishing workflow initiated from the Mac that syncs notes and images to the server, converts them, builds or validates the site there, and pushes the website-source repository to GitHub. Make failures stop the process before it publishes incomplete content. Verified with a content change: the Mac script synced, HP1Docker converted and built, and the new commit pushed to main.
• 5.6 Add a pushdash alias on the Mac for the publishing workflow and verify it from a fresh terminal. The Mac-side workflow must not require or contain Hugo files.
• 5.7 Keep pushgen and pushgps available during the transition; their publishing scripts and schedules are recorded in 1.3.
• 5.8 Verify a fresh website-source checkout builds from the documented command without depending on Mac temporary folders or untracked server-only files. Record the server publishing and build instructions in the website-source repository. Cloudflare successfully built the pushed repository revision using the documented Hugo source and generated content.

6. Migrate app content into the shared site#

• 6.1 Turn each copied app homepage into its section landing page. Keep its manual, Quick Start Guide, privacy policy, contact information, and App Store links within that app’s section.
• 6.2 Add basic working navigation between the app sections and languages, plus clear navigation within each app. Add a Home link after creating the DashApps landing page in section 11; defer visual refinement until after launch.
• 6.3 Update copied links, explicit page URLs, aliases, and language links for the new paths. Check raw HTML links as well as Obsidian wikilinks.
• 6.4 Separate image paths by app, such as /images/gendash/ and /images/gpsdash/, and update references. Check for matching filenames, CSS rules, or scripts that could conflict.
• 6.5 Replace GPSDash placeholder text where needed. Review copied contact forms, support details, privacy statements, and external services for accuracy under the shared site.
• 6.6 Preserve and adapt the GPSDash layouts/dev/list.html layout so DEV pages render correctly within the GPSDash section and shared DashApps navigation.
• 6.7 Keep each app’s DEV section under its app path: /gendash/dev/ and /gpsdash/dev/, with corresponding French and Spanish paths, such as /fr/gendash/dev/ and /es/gpsdash/dev/.

7. Verify the server build and preview setup#

• 7.1 Verify the existing server-side /home/marc/hugo/dashapps project is connected to the new website-source repository and that the local Obsidian vault remains separate.
• 7.2 Build DashApps on HP1Docker into its own output directory and start a LAN preview on an unused port. Record the preview address.
• 7.3 Verify HP1Docker has everything required by the server publishing workflow. If changes to installed software are needed, handle those separately. The workflow ran with the installed Hugo Extended version and Python conversion script.
• 7.4 Finish the safe preview/publishing setup. The server routine syncs from the vault, converts, validates a Hugo build, commits, and pushes to GitHub; its successful run printed the pushed revision. Still set up the separate LAN preview and ensure its previous output remains available during updates (see 7.2).
• 7.5 Use one server update schedule if desired. Avoid a second routine that independently commits or publishes the same DashApps site.
• 7.6 Confirm the existing GenDash, GPSDash, and other Hugo sites still work.

8. Create the Cloudflare Pages project#

• 8.1 Create a new Pages project connected to the DashApps website-source repository, with main as the production branch. Follow Cloudflare’s Hugo guide. The dashapps-app Pages project is connected to marcoue/DashApps.app on main.
• 8.2 At Cloudflare setup time, record and match the tested Hugo and Blowfish versions. HP1Docker currently verifies Hugo v0.166.0 Extended and the DashApps copy of Blowfish v3.8.0 (commit 51a361e068b9975c7f1df8e2bb223db03fe49c2b). Pin HUGO_VERSION=0.166.0 for production and preview builds, confirm the Extended build is available, and verify a Cloudflare build with this pair. Do not change version settings for existing sites. HUGO_VERSION=0.166.0 was added, and Cloudflare’s production build succeeded.
• 8.3 Set the Hugo build command and output directory (public) for the website-source repository. Note conversion happens on the server before the repository revision is pushed. Cloudflare is configured with build command hugo and output directory public.
• 8.4 Configure production builds for https://dashapps.app/ and preview builds for their preview address. Check that links and images work in both. Production is active at dashapps.app; the pages.dev deployment succeeded. Preview behavior and links/images still need review.
• 8.5 Use a development branch and Pages preview deployments for review. Keep unfinished content out of production and verify previews are not indexed.
• 8.6 Prepare dashapps.app in the correct Cloudflare account and zone. Preserve any existing DNS/email records; confirm Cloudflare nameservers where needed for the apex domain. Cloudflare activated the apex domain for Pages; verify the existing DNS/email records as part of review.
• 8.7 After the review passes, attach dashapps.app through Pages custom domains. Confirm HTTPS works; add www only if wanted, with one preferred hostname. dashapps.app is active on the Pages project and SSL is enabled.
• 8.8 Keep the old domains attached to their existing sites during the transition. No old Pages projects or custom domains were changed.

9. Review before launch#

• 9.1 Compare every public page and asset with the original sites; confirm nothing was missed in any language.
• 9.2 Test both app sections, manuals, Quick Start Guides, privacy/contact pages, downloads, forms, and App Store links.
• 9.3 Test language switching from inside an app page, search, mobile navigation, light/dark mode, and the 404 page. Ensure search results clearly identify the app.
• 9.4 Check for broken links, missing images, placeholder text, unwanted DEV/private content, and build warnings.
• 9.5 Check page titles, descriptions, canonical URLs, language equivalents, sitemap, and robots settings. Decide how duplicate pages on the old and new sites will identify the preferred URL once DashApps launches.
• 9.6 Create an old-to-new URL list for every page and language. For example, an old French GenDash manual should lead to its matching /fr/gendash/… page, not the English homepage.
• 9.7 Record a rollback procedure: restore the previous DashApps deployment or Git revision, and continue using the unchanged old sites if a launch issue appears.
• 9.8 Build and review the GenDash and GPSDash DEV landing pages and all translated DEV pages at their new paths. Confirm they are included in the site and remain separate from the regular app pages.

10. Launch while keeping the old sites live#

• 10.1 Copy any content changes made since the first clone, then run the final review again.
• 10.2 Publish the reviewed version to DashApps and confirm the domain, HTTPS, canonical URLs, sitemap, and all app/language paths.
• 10.3 Declare the DashApps vault the primary editing source from this point. Keep the old sites live, but avoid independent content edits; deliberately mirror essential updates until redirects are enabled.
• 10.4 Add a simple “Our apps now live at DashApps” link on the old sites while their content remains accessible.
• 10.5 Update App Store website, support, and privacy URLs for each app when ready. Update links inside the apps, support materials, and other public profiles as appropriate.
• 10.6 Add the new site and sitemap to the search tools already used, and review broken links, contact delivery, and deployment failures during the transition.
• 10.7 Save a working launch revision and update the related Hugo notes with the final paths, repositories, domains, and publishing routine.

11. After launch: refine the DashApps presentation#

Start these design tasks after the content migration is complete and DashApps is live. Launch the migrated app sections first; create the DashApps landing page and visual identity in this phase.

• 11.1 Create the DashApps landing page with an introduction and one designed card per app, including its icon, description, and link. Translate it into French and Spanish.
• 11.2 Create a DashApps logo and favicon while retaining each app’s identity within its section.
• 11.3 Refine shared navigation and the visual presentation of each app section.

12. Later: finish the transition#

Only start this phase after DashApps is stable. The intended end state is to keep the old domains and their redirects, while removing the old vaults, repositories, Pages projects, and server site files.

• 12.1 Choose the redirect date after checking that important links and app releases point to the new site.
• 12.2 Configure permanent redirects so gendash.app points to https://dashapps.app/gendash/ and gpsdash.app points to https://dashapps.app/gpsdash/. Preserve matching deep paths where possible, using the reviewed URL list.
• 12.3 Test homepages, deep links, language paths, images, and query strings. Avoid redirect loops and sending every old page to the main landing page.
• 12.4 Move each redirect to a Cloudflare rule that continues working without the old Pages project. Verify both domains redirect correctly over HTTPS, including deep links.
• 12.5 Save final backups of the old vaults, repositories, server folders, and Cloudflare settings. Confirm the backups can be opened and identify where they are stored.
• 12.6 Disable the old content-publishing schedules and confirm they no longer run.
• 12.7 Remove the pushgen, pullgen, pushgps, and pullgps aliases and their local scripts. The Mac Studio GenDash cron entries were removed on 2026-10-09; no backup was retained.
• 12.8 Turn off auto-renew for the two old GenDash and GPSDash Cloudflare Pages projects, if enabled. Keep the domains registered and the redirect rules active.
• 12.9 Delete the local /Users/marc/Obsidian/GenDash and /Users/marc/Obsidian/GPSDash vault folders after the new DashApps vault contains the content and the final backups are verified.
• 12.10 Delete the old GenDash and GPSDash GitHub repositories after confirming the DashApps repository contains the published source and the final backups are verified.
• 12.11 Remove the old GenDash and GPSDash custom domains from their Pages projects, then delete those two Pages projects. Keep the domains registered, their DNS zones, and the working redirect rules.
• 12.12 Delete only the old GenDash and GPSDash Hugo project folders and generated site files on HP1Docker (10.1.2.202). Verify the exact paths first; keep /home/marc/hugo/dashapps and every unrelated site intact.
• 12.13 Confirm both old domains still redirect and the DashApps site still builds after cleanup. Retain the final backups for rollback or reference.
• 12.14 Document how to add the next app: create its language folders and images, add its landing-page card, review, and publish through the same routine.

Related notes#

• GenDash and Hugo setup on Mac
• GenDash Site Improvements
• GPSDash Hugo Scaffold
• Hugo and Blowfish Update - HP1Docker