This project is a lightweight n8n automation that keeps already-published digital assets permanently up to date. Instead of re-editing emails, forms, and templates after they ship, it gives an image a fixed hosting URL and a link a fixed redirect alias, then refreshes what each one points to on a schedule. A daily job repoints the link to current content, while an hourly job regenerates the image and commits it over the same GitHub path. The same stable addresses can be embedded in workflow stickers, n8n forms, or HTML emails — and updated years later without touching the originals.
Keep already-distributed images and links permanently up to date by making their content swappable without changing the asset itself.
The brief: assets that stay fresh long after you publish them.
When you publish a workflow template, build a registration form, or send a marketing email, those assets stop being yours the moment they go out. They keep living in inboxes, browser tabs, and template galleries — and people keep finding them long after creation. The problem is that everything embedded in them is frozen: the banner image shows last season's promotion, the link points to an offer that ended months ago. The naive fix is to maintain and re-edit the entire content library, which is impractical and, for assets already sitting in someone else's inbox, impossible.
This project solves that with a deliberately lightweight pattern: make the asset's address permanent, but its content dynamic. An image lives at a fixed URL and a link lives at a fixed alias, but what they actually resolve to can be updated on a schedule, forever. Distribute the stable address once, and you can change the message behind it years later — no need to touch the original email, form, or template ever again.
The build is compact — just 19 nodes in n8n — and splits cleanly into a one-time setup and two recurring update loops.
One-time setup (run once). Three nodes establish the permanent assets. First, a call to a URL-shortening and redirect service creates an initial short link alias — the stable address you'll hand out. Second, a GitHub node commits an initial image file to a public repository, giving the image a permanent raw-content URL. Third, a follow-up GitHub read fetches that file's downloadable URL so it can be embedded anywhere. After this runs once, the two public addresses never change again.
Update loop 1 — the dynamic link (daily). A schedule trigger fires once a day and issues a PUT to the redirect service, repointing the same alias to a new destination. In the reference implementation the alias always resolves to the current day's Wikipedia "on this day" article, so a single unchanging link delivers fresh, date-relevant content every day. Swap that logic for your own and the same link can rotate through seasonal promotions, your latest blog post, or whatever offer is live right now.
Update loop 2 — the dynamic image (hourly). A second schedule trigger fires hourly. An image-editing node generates a fresh PNG on the fly — drawing a background, borders, and live text such as the current date and time — and a GitHub node commits it over the existing file at the same path. Because the file path is unchanged, every email, form, and template that references that image URL instantly shows the updated graphic the next time it loads. The cadence is fully tunable; hourly is simply the default.
Three ways to use it. The workflow ships with three demonstrations of the pattern in the wild. The first embeds the dynamic, clickable image directly inside n8n workflow stickers, so anyone opening the template sees current content. The second places it inside an n8n form via a custom HTML element with CSS to size the image correctly — turning a static registration form into a live billboard. The third drops it into an HTML email as a clickable banner or footer, letting an email sent today carry a message you write next month.
Why this design works. It is intentionally minimal and dependency-light. The two external services — a redirect/URL-shortening provider and GitHub for image hosting — both have free tiers, and the pattern is explicitly built to be swappable: any URL-redirect service works in place of the first, and an S3 bucket (or any static host) works in place of GitHub. There are no AI models, no databases, and no fragile state to manage — just two public addresses and two scheduled jobs keeping them current. The result is a "set it once" mechanism that quietly future-proofs an entire library of distributed assets, letting you stay in contact with an audience that hasn't even arrived yet.
A free 20-minute call. Bring the messy, ambitious, “is this even possible” version, and I’ll tell you if it’s buildable and roughly how.