My Digital Legacy Architecture: A Personal Manifesto for Weathering Technological Tides

Posted at # Architecture # Philosophy of Technology # Jamstack

When I first wondered whether I should move my blog’s backend from Netlify Functions to Supabase, a seemingly simple technology choice triggered a full review of my ten-year “digital-nomad” journey. I realized this was no longer just a move from A to B; it was a loop of tech waves, platform shifts, and personal energy drain.

So this is not a tech-selection guide. It is a self-dialogue, a retrospective on the past decade, and—most importantly—a manifesto for my next few decades of digital life.

The final blueprint is a personal digital-legacy architecture consisting of four independent layers, built on “composability” and “replaceability”:

  1. Content Bedrock Markdown + Git as the eternal source of truth, keeping all content in plain text under my complete control.
  2. Media Warehouse An independent, S3-compatible object store (e.g., Cloudflare R2) for all binary files, exposing absolute URLs to decouple storage from presentation.
  3. Logic Brain A platform-agnostic functions service (e.g., Cloudflare Workers) that handles dynamic logic, ensuring the core remains portable.
  4. Presentation Skin Any modern static-site generator (e.g., Astro) plus a static-hosting platform (e.g., Netlify) as the most easily swapped “skin.”
Personal Digital-Legacy Architecture

This architecture was born from a set of core principles—and many lessons learned in practice.

1. First-Principles Architecture: Embrace Composability, Abandon Silver Bullets

Tired of endless migrations, I stepped back from individual tools and asked what first principles a long-lived architecture should follow.

I distilled four key principles:

Principle 1: Separate Content from Presentation

The most basic–and most important–rule.

  • Content is my ideas, words, data: assets that must endure.
  • Presentation is the theme, layout, CSS: a skin that changes with fashion.

Any tech that forcibly bundles the two (e.g., early WYSIWYG editors or some CMS theme systems) must be rejected.

Principle 2: Open & Plain-Text First

Core content must live in the most open, universal, durable format. Today, Markdown + Git best embody this.

  • Markdown is human-readable and free of proprietary ties; fifty years from now it will still be parsable.
  • Git offers distributed, verifiable history—my “safe-deposit box” and “time machine.”

Principle 3: Data Ownership & Control

All data—Markdown files, images—must reside in places I directly own and control.

  • “Control” means I hold the keys: free to read, write, delete, or migrate.
  • Relying on an app’s own database (WordPress, Notion) cedes power.
  • Storing in a Git repo or S3-compatible object storage enforces ownership.

Principle 4: Composable & Replaceable Architecture

Pushing decoupling further: the system shouldn’t be a giant monolith, but a set of independent services, each doing one thing well, swappable at will.

  • Composable Services communicate via stable, public APIs (HTTP), Lego-style.
  • Replaceable If one service (say, my functions platform) ceases to fit, I swap it by rewriting only a thin adapter—nothing else breaks.

Stop chasing a single “cure-all” platform and build a flexible “specialist team.”

2. The Pain of Migration: A Decade of Digital Nomadism

To see why a “simple” tech choice matters, rewind the story—filled with tinkering and compromise.

Phase 1: Raw HTML & WYSIWYG. Early on I used rich-text editors that spat out inline-styled HTML. Any style tweak meant mass search-and-replace: content and style entangled and messy.

Phase 2: WordPress’s Golden Age. I dove into WordPress, seduced by its all-in-one power. Plugins and themes were abundant, publishing was easy—until performance hits, security holes, plugin clashes, and that unwieldy database surfaced. Moving felt like prying possessions out of concrete.

Phase 3: The SSG Renaissance. Fed up, I switched to Jekyll, Hugo, etc. Markdown returned, Git versioned everything, performance and security soared. I deployed on GitHub Pages, later Netlify, enjoying push-to-deploy bliss.

Phase 4: The “Publish-Anything” Efficiency Trap. With Obsidian and Notion came one-click publish plugins. Efficiency nirvana—until my workflow hinged on a plugin or API. Stop maintenance? API change? Total breakdown.

Across ten years and many moves, even with data ownership I still faced:

  • Broken links when paths changed.
  • Logic rewrites (comments, search) per platform.
  • Format conversions (WordPress SQL → Markdown) that were pure pain.
  • Scattered focus: time lost to migrations, not creation.

Lesson learned: tech “convenience” is often a poisonous lure—immediate ease traded for future freedom.

3. North Star & Crossroads: A Decision Framework Emerges

One longstanding habit came to mind:

I never use relative paths for images in my articles.

Instead, every image or PDF lives in an object store (S3, now Cloudflare R2) and is referenced by an absolute URL. Simple motive: fear of migration.

Absolute URLs solved the issue once and for all—the address never changes. Years later, that single decision saved untold hours and embodied the power of decoupling.

Decoupling’s essence: split a big system into subsystems that talk only through clear, stable interfaces (APIs).

It became my “North Star” question for every tech choice:

Does this decision make components tighter or looser?

Option 1: Stay (or double down) in Netlify’s ecosystem

  • Pros – Simple, convenient, integrated.
  • Cons – Classic tight coupling: backend logic and data life cycles bound to Netlify. Same old WordPress-style trap.
  • Verdict – Comfortable yet fragile; violates my North Star.

Option 2: Move to Supabase—into a bigger “garden”

  • Pros – Some decoupling; powerful features.
  • Cons – Merely swaps a small walled garden for a bigger, shinier one. Logic, data, auth all lock to Supabase.
  • Verdict – Solves today, seeds tomorrow’s lock-in. Pseudo-decoupling.

Option 3: Go back to basics—temptation of a VPS

  • Pros – Maximum freedom and control.
  • Cons – I remember: low maintenance is also a core goal. I’m not a full-time sysadmin.
  • Verdict – Power at the cost of burden; not aligned.

Option 4: Modern PaaS—a middle ground

Platforms like Fly.io, Railway, Render balance freedom and ease. Containers boost portability, but I’d still manage a full server app—extra “application layer” overhead compared with serverless functions.

4. Fatal Coupling: A Next.js Case Study

A real incident involving Next.js and Vercel cemented my stance.

Here’s the story:

Next.js is currently the most popular React framework, developed and heavily promoted by Vercel. This relationship exemplifies “platform tight coupling.” To boost performance, Vercel implemented a “magic” optimization for Next.js applications on its platform: it automatically deploys user-written Next.js middleware to its global edge network (Vercel Edge) for execution.

This optimization itself created problems. In certain scenarios, user requests would cause middleware to execute in infinite recursion. To solve this issue, Vercel engineers added a “patch” to Next.js framework’s core code: each time middleware executes, it adds a special marker x-middleware-subrequest to the request header. If this marker is detected in subsequent execution, the system assumes recursion has occurred and halts execution immediately.

Here’s the problem: HTTP request headers can be forged by clients (users).

This means a malicious attacker can craft an HTTP request and pre-populate the header with that special marker. When this request reaches the server, Next.js middleware sees the marker, assumes recursion has happened, and directly aborts its own execution.

What’s the consequence? The attacker successfully and completely bypasses the entire middleware!

If your middleware handles user authentication, attackers can exploit this vulnerability to directly access all protected, login-required sensitive pages. This is a catastrophic security vulnerability with a CVSS score of 9.1 (out of 10).

Takeaways:

  1. Coupling fragility—a platform “optimization” became a security disaster.
  2. Open-source neutrality broken—a risky patch for a platform-specific issue polluted a supposedly neutral framework.
  3. Trust collapse—handing my fate to a company that’s both “player” (framework) and “referee” (platform) is dangerous.

From then on: my architecture must eradicate such fatal coupling.

5. A Blueprint for Decades Ahead: My Personal Digital-Legacy Architecture

Guided by the above, I designed a long-term maintainable stack:

Layer 1: The Content Bedrock

  • Stack Markdown + Git repo (hosted on GitHub).
  • Role The immutable source of truth. All writing lives as .md plain text. Git tracks history; GitHub offers distributed backup. I write locally in Obsidian, sync with Git—100% data ownership.

Layer 2: The Media Warehouse

  • Stack Cloudflare R2.
  • Role Pure S3-compatible object store for images, PDFs, video. One job: store files and serve them at stable URLs. Fully decoupled from both content and presentation layers.

Layer 3: The Logic Brain

  • Stack Cloudflare Workers.

  • Role Dynamic logic (full-text search, API endpoints).

    • Independence Runs standalone, not tied to any frontend or host.
    • Standardized Uses Web standard APIs (Fetch, Streams); highly portable.
    • Ecosystem synergy Co-located with R2, enjoying minimal latency and zero egress fees—key practical win.
    • Data flow Search indexes are generated in CI/CD from the Git repo, uploaded to R2, and read by Workers—clear, controllable, automated.

Layer 4: The Presentation Skin

  • Stack Astro (SSG) + Netlify (static hosting).

  • Role The “skin” that presents content beautifully.

    • Swap-ability The least critical layer. I chose Astro for performance and components today; tomorrow I could switch tools or move from Netlify to Vercel/Cloudflare Pages with a few config tweaks.

A Gradual-Migration Strategy

I won’t flip everything overnight. Steps:

  1. Ensure all new data (e.g., search index) lands in R2.
  2. Move search to the first Cloudflare Worker; update frontend calls.
  3. Gradually migrate other APIs.
  4. Once stable, safely decommission old Netlify Functions.

Low-risk, controlled, smooth.

Epilogue: Simplicity Is the Ultimate Sophistication

Leonardo da Vinci said: “Simplicity is the ultimate sophistication.”

After a decade of migrations, I sought a way to focus on creation. All-in-one platforms looked ideal—until their hidden complexity and fragility surfaced.

Today’s choice involves more services (Git, R2, Workers, Astro, Netlify), which seems more complex.

Yet its structure is unprecedentedly simple:

Each component does one thing well. They converse via the oldest, most stable protocol—HTTP. Any piece can be replaced without toppling the whole.

That structural simplicity is hard-won.

This architecture isn’t chasing trendy tech—it is built to resist trends. It is a sturdy, tranquil shelter entirely my own, granting a peace born of control, not convenience—

A peace that comes from laying foundations on bedrock, not shifting sand.