Preview Homelab and DashApps on HP1Docker without publishing changes to GitHub or triggering Cloudflare Pages. First make the previews work on the LAN; Pangolin hostnames are an optional later enhancement.
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.
The GPSDash Hugo scaffold was created on 2026-09-26 from the reusable GenDash site structure. The configuration title, base URL, and custom CSS namespace were adapted from GenDash to GPSDash.
Hugo v0.166.0 was downloaded from the official release and verified against its published SHA-256 checksum (0e39b901e3f919f1daae05c8ff64f0c14c8a348ef46886d63f8e6d1bb2653885). Blowfish v3.8.0 declares Hugo v0.166.0 as its supported version.
1.1 Define the website’s three purposes: explain GenDash clearly and drive App Store downloads; provide a technical reference; and offer a Quick Start Guide.
1.2 Analyse whether the site is simple, fast, privacy-focused, and easy to maintain through Obsidian and Hugo. Conclusion: simple for visitors and content editing; static and generally fast; privacy-focused for app data; and maintainable, although the publishing infrastructure is more complex than the website itself.
1.3 Analyse whether the existing Hugo publishing workflow and English, French, and Spanish structure should be preserved. Conclusion: preserve the current workflow and language structure; they are clear, working, and the English DEV preview fits naturally within them.
2.1 Analyse whether the homepage explains GenDash clearly within a few seconds.
Finding: Yes. The headline, supporting statement, and dashboard mockup quickly establish that GenDash monitors a generator; the iOS app context arrives later in the third paragraph.
2.2 Analyse whether the hero headline and supporting text communicate the main problem GenDash solves.
Finding: Yes. The Time-to-Empty question makes the outage problem concrete. “Your generator, monitored.” is memorable, but needs the supporting copy to explain the practical benefit.
2.3 Analyse whether the homepage presents the most important product benefits in a concise, scannable way.
Finding: Partly. The benefits are strong, but they sit in two long paragraphs rather than a short scannable list or set of feature highlights.
2.4 Analyse whether support for gas, propane, diesel, battery generators, Home Assistant, and custom telemetry is explained clearly.
Finding: Partly. All of these capabilities are named, but they are compressed into one sentence. Home Assistant and custom telemetry would be easier to understand if separated and briefly explained.
2.5 Analyse whether the App Store download is the primary and most visible call to action.
Finding: Mostly. The App Store badge is the strongest action in the hero and links directly to the correct listing. It appears after three paragraphs and shares its row with About & Contact, so it could be given slightly more prominence.
2.6 Analyse whether the free trial, one-time US$4.99 purchase, and no-subscription model are clear.
Finding: Complete. The pricing card now states the 7-day trial, one-time US$4.99 purchase, local-equivalent clarification, and absence of subscriptions, ads, cloud accounts, and data harvesting.
2.7 Analyse whether the homepage links users effectively to the User Manual, Quick Start Guide, Privacy Policy, and About & Contact pages.
Finding: Partly. All four pages are in the navigation, and About & Contact plus the User Manual are linked in the page body. Quick Start Guide and Privacy Policy have no dedicated homepage links outside the navigation.
2.8 Analyse the homepage typography, spacing, colors, imagery, and overall visual hierarchy.
Finding: Strong overall. The clean typography, orange accent, generous spacing, and dashboard mockup create a calm, credible product page. The long body copy weakens scanning, and the pricing card is visually quieter than its value proposition deserves.
2.9 Analyse the homepage on mobile screens for readability, navigation, image sizing, and tap targets.
Finding: At a 390 px-wide iPhone viewport, there is no horizontal overflow; the mockup scales to 298 px and the App Store link remains available. The navigation collapses to a hamburger control, but its visible icon is only 18 × 18 px and should be made easier to tap.
3.1 Analyse and simplify the Quick Start Guide’s first-run path, including its order, required steps, optional features, and level of detail.
Finding: These concerns form one review rather than three separate tasks. A new user can understand the main path—onboarding, permissions, generator setup, optional integrations, load planning, and starting a run—but the guide is broader than a true start-to-finish quick start. The basic order is logical, yet the separate Home Assistant management flow appears before the first-run section, and advanced estimating and maintenance content follows the core task without a strong separation. The guide communicates valuable benefits, but technical details dilute the essential message: configure a generator, start a run, and know how much runtime remains. The EN, FR, and ES DEV guides now begin with an explicit first-run path and identify advanced topics as optional.
3.2 Analyse the guide’s typography, screenshots, callouts, spacing, and visual hierarchy.
Finding: The published page has a clear heading hierarchy, readable body text, consistent spacing, separators between major topics, and useful bold labels for actions. However, it contains no instructional screenshots or visual callouts, so the reader must translate text into the app interface. The page also renders two table-of-content blocks, which is redundant, and its repeated numbering restarts at 1 in each major topic. Visual hierarchy would improve if the minimum path were visually separated from optional and advanced reference sections.
3.3 Analyse the Quick Start Guide on mobile screens for readability and ease of following instructions.
Finding: At a 390 px-wide mobile viewport, the guide has no horizontal overflow; the article fits within a 334 px content column, headings wrap within the column, and the page remains readable. The main mobile limitation is length and text density rather than broken layout: a new user must scroll through many paragraphs and lists without screenshots or compact step cards. Mobile usability would benefit most from a shorter first-run path, expandable advanced sections, and more visual guidance rather than a major responsive redesign.
3.4 Evaluate whether to capture a small, maintainable set of GenDash screenshots from Xcode and the iOS Simulator, then add them to the shared Images folder and the EN, FR, and ES Quick Start Guides if justified.
4.1 Analyse whether the User Manual is complete, logically organized, and easy to navigate.
Finding: The manual is comprehensive, covering licensing, the product model, onboarding, generator setup, Home Assistant, preferences, environment, notifications, backup, load planning, sessions, history, Live Activities, fleet management, maintenance, reset, FAQs, and real-world examples. Its 19 major sections are broadly logical, but the 10,000-word scope makes it read more like an encyclopedia than a manual for everyday use. The published page also renders two table-of-content blocks, creating redundant navigation. The main opportunity is to preserve the coverage while improving grouping, entry points, and scanning.
4.2 Analyse whether the manual clearly explains GenDash features, supported hardware, integrations, and expected user outcomes.
Finding: Coverage is strong. The manual explains gasoline, propane, natural gas, diesel, and battery systems; the generator library and custom profiles; Home Assistant; appliance loads; estimating; sessions; fleet management; maintenance; backups; and Live Activities. It generally connects each feature to an outcome such as more accurate Time to Empty, safer load planning, or better outage awareness. The volume of detail can obscure the most important outcomes, so each major section would benefit from a short “what this helps you do” introduction.
4.3 Analyse whether technical instructions and terminology are understandable to the intended user.
Finding: Instructions are concrete and often supported by examples, field-by-field explanations, and safety notes. However, the manual assumes a technically confident reader and introduces many terms—TTE, Seed Library, LAN/WAN, Long-Lived Access Token, SwiftData, rated versus surge watts, load curves, and kWh/Wh—across a long document. The intended user can follow it, but first-use definitions or a small glossary would reduce cognitive load. UI labels should also remain consistent with the current app.
4.4 Analyse the manual’s typography, headings, screenshots, spacing, and visual hierarchy.
Finding: The published page has a strong heading hierarchy, bold action labels, useful tables, and safety/privacy callouts. It contains no instructional screenshots or diagrams, so the manual is entirely text-led apart from the site icon. The 19-section length, dense paragraphs, repeated nested headings, and duplicate table of contents make the visual experience heavy. A small number of stable visuals could help, but the maintenance cost should be weighed against the benefit; clearer section summaries and selective callouts are the lower-maintenance improvement.
4.5 Analyse the User Manual on mobile screens for readability, navigation, and image sizing.
Finding: At a 390 px-wide mobile viewport, the page itself has no horizontal overflow; the article fits within a 334 px content column and headings wrap correctly. There are no instructional images to resize. The main mobile weaknesses are the manual’s length, dense text, and large number of links, which make navigation and scanning tiring. The generator model table is slightly wider than its mobile content area and may need a small table-specific overflow check, but no major responsive failure was observed.
5.1 Analyse whether the Privacy Policy clearly explains what GenDash collects, stores, and processes.
Finding: The policy clearly states that GenDash does not collect generator telemetry, financial information, or personal data on its own servers, and that app data is stored locally. It does not yet describe location data used for weather lookups, the Open-Meteo service, exported backup files, or the information submitted through the website contact form. The policy should distinguish app processing from website and support-service processing.
5.2 Analyse whether the policy accurately describes local-only app processing, offline operation, and the absence of user accounts.
Finding: The local-first, offline-ready, and no-account claims are generally clear. The Home Assistant statement is too narrow because the app supports a user-configured remote URL as well as a local-network URL. The policy should explain that Home Assistant data goes to the user’s own configured server, locally or remotely, and that internet access is also used for weather data when automatic location mode is enabled.
5.3 Analyse whether the website’s analytics and external services are addressed accurately.
Finding: No analytics, advertising, or tracking code was found in the site source, but the policy should state whether Cloudflare web analytics and hosting logs are enabled or disabled. The contact page sends form submissions to a Google Apps Script endpoint, which is an external service and is not mentioned. The policy should also identify Apple App Store processing, the Open-Meteo weather API, the user’s Home Assistant server, and the Google contact-form service with appropriate links to their policies where relevant.
5.4 Analyse whether the policy is readable, trustworthy, and appropriate for the intended audience.
Finding: The six short sections are easy to scan and use plain language. Trust would improve with an effective date and last-updated date, a clear description of the developer/data controller, a more precise scope for deletion and retention, and a note that exported backups may contain sensitive generator, history, and Home Assistant configuration data. The EN page uses H3 headings for its main sections while FR and ES use H2 headings; the heading level should be standardized across languages.
5.5 Analyse the Privacy Policy on mobile screens for readability and navigation.
Finding: The page is short, text-based, and unlikely to have a major mobile layout problem. It does not need a table of contents. The main mobile improvements are maintaining comfortable line length, making the support email a clear tap target, and checking that any added service-policy links wrap cleanly without horizontal overflow.
6.1 Analyse whether the About & Contact page explains the motivation behind GenDash clearly and concisely.
Finding: The page explains the motivation well: the creator describes the frustration of estimating generator fuel during outages and the goal of providing a reliable, offline-first tool. The message is credible, but the two paragraphs are longer than necessary and the core purpose could be stated more quickly.
6.2 Analyse whether the page builds trust without becoming unnecessarily personal or lengthy.
Finding: Identifying the independent creator and emphasizing privacy builds trust. The references to “300 hours” and “more than 1000 modifications” are personal and may become outdated; they are optional proof points rather than essential information. The page presents an individual creator but the form says “our support team,” which should be made consistent.
6.3 Analyse whether the support email and Launch Mail App link are easy to find and use.
Finding: The email address is prominent, has a Copy button, and has a separate mailto button. The displayed email itself is not clickable, and the Clipboard API has no fallback if copying is unavailable. The French button text “Lancer l’application” is ambiguous; it should clearly mean opening the mail app. The EN, FR, and ES buttons should use equivalent wording.
6.4 Analyse whether the page communicates how support requests are handled.
Finding: The page says that support will reply by email, but gives no expected response time or guidance about what information to include. The contact form submits through Google Apps Script and uses a no-cors request, so the success message does not fully confirm that the backend accepted the message. The form’s data handling should be consistent with the Privacy Policy.
6.5 Analyse the page’s typography, spacing, links, and visual hierarchy.
Finding: The two-card layout creates a clear split between the creator/contact information and the message form. The orange action button, generous spacing, rounded cards, and dark-mode styles are consistent with the site. The page relies heavily on duplicated inline HTML/CSS across three language files, which increases maintenance cost. The decorative creator emoji is optional and should follow the same restrained visual approach as the rest of the site.
6.6 Analyse the About & Contact page on mobile screens for readability and ease of contact.
Finding: The flex-wrap layout should stack the cards on narrow screens, and the form controls use full width with comfortable padding. The main mobile checks are whether the email row wraps cleanly, whether the mail and submit buttons remain easy to tap, and whether the long creator text pushes the contact form too far down the page. No major responsive failure is apparent from the source structure, but it should be confirmed on an actual phone.
7.1 Compare English, French, and Spanish navigation, structure, and calls to action.
7.2 Verify Hugo front matter, titles, descriptions, dates, and canonical URLs across all pages.
Finding (checks 1–4): All 30 EN, FR, and ES pages—including DEV—now have front-matter titles, descriptions, dates, lastmod values, draft flags, and tags. Localized titles and descriptions are consistent, every page is set to draft: false, the six homepage files now have the title GenDash, the misspelled privaly tag was corrected to privacy, and all lastmod values were aligned with the current metadata update. Canonical URLs still require the local build/render check.
7.3 Check internal links, language links, missing assets, and broken links.
7.4 Check light-mode and dark-mode consistency across all pages.
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.
Homelab: 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.
Used the successful pre-update backup on LXC 102: /home/vps-backup/Backups/2026-10-02_08h27_PangolinBackup.tar.gz; gzip integrity and database/configuration entries were verified.
Updated Pangolin 1.21.1 → 1.22.2 → 1.23.0 → 1.24.0. Each stage passed Compose readiness checks and dashboard HTTP 200; final migrations completed successfully.
Updated Gerbil to 1.5.2, Newt to 1.18.0, Traefik to v3.7.13, and pinned CrowdSec to v1.8.1. Rebuilt the custom GoAccess image from its existing inline Dockerfile with a fresh base image; verified GoAccess 1.12.
Updated Badger to v1.7.0 and the CrowdSec Traefik plugin to v1.7.1 in the active config/traefik/traefik.yaml. Automatic Badger migration skipped the nonstandard filename; the explicit update is present.
Retained docker-compose.yml.before-2026-10-02-update and config/traefik/traefik.yaml.before-2026-10-02-update on the VPS. Database rollback requires the pre-update backup, not just older images.
Verification limitation: Homelab site is online, but RN VPS site is offline. The local Newt connector repeatedly receives HTTP 400 No newt found with that newtId. Testing the original Newt 1.15.0 produced the same rejection; restored 1.18.0. Its registration requires investigation without exposing credentials. No site registrations or credentials were changed. Full routed-resource functionality has not been verified.
Follow-up resolved: after the user restarted using their 1p alias, Newt 1.18.0 logged Websocket connected at 12:45:09 UTC. Both RN VPS and Homelab sites were verified online and approved; all six stack containers were running, Pangolin and CrowdSec were healthy, and the dashboard returned HTTP 200. No credential values were inspected during this follow-up. Individual routed resources remain untested.
