https://vanityurls.link/en/tags/upgrades/Recent content in Upgrades on vanityURLsHugoen-CASun, 31 May 2026 20:04:27 -0400https://vanityurls.link/en/blog/keeping-vanityurls-upgradable-with-custom-overrides/Fri, 22 May 2026 00:00:00 +0000https://vanityurls.link/en/blog/keeping-vanityurls-upgradable-with-custom-overrides/<p>The fastest way to ruin a small self-hosted tool is to edit upstream files in place.</p> <p>It works once. Then the next upgrade asks a dull question with expensive consequences: which files are product defaults, which files are local decisions, and which files are generated output?</p> <p>vanityURLs avoids that by keeping three layers:</p> <table> <thead> <tr> <th>Layer</th> <th>Owner</th> <th>Rule</th> </tr> </thead> <tbody> <tr> <td><code>defaults/</code> and <code>scripts/</code></td> <td>product</td> <td>refresh from upstream</td> </tr> <tr> <td><code>custom/</code></td> <td>instance</td> <td>review and preserve</td> </tr> <tr> <td><code>build/</code> and generated <code>src/</code></td> <td>build</td> <td>replace freely</td> </tr> </tbody> </table> <p>That boundary is not bureaucracy. It is what keeps upgrades from becoming archaeology.</p>https://vanityurls.link/en/blog/upgrading-without-restarting-from-scratch/Fri, 22 May 2026 00:00:00 +0000https://vanityurls.link/en/blog/upgrading-without-restarting-from-scratch/<p>When a tool is still moving quickly, the tempting but exhausting instinct is to start over each time the installer improves. Delete the instance, clone again, answer the questions again, copy custom files back, hope nothing subtle was lost.</p> <p>That is not the intended vanityURLs workflow.</p> <p>An instance is designed to keep its local identity while the product layer improves around it. Your links, schedules, policies, branding, legal pages, Cloudflare settings, and helper configuration live in the instance layer. The upstream product files live in <code>defaults/</code> and <code>scripts/</code>. The generated output can be rebuilt.</p>