wakqasahmed.eth — Decentralized Portfolio

A personal portfolio site built with Astro, deployed to IPFS, and accessible via an ENS name on Ethereum mainnet — no servers, no gatekeepers.

Overview

This portfolio site is itself a decentralized application — a dog-fooding exercise in the principles it describes. The site has no backend, no database, no server-side rendering, and no dependency on any centralised hosting provider to remain accessible.

Architecture

Static site generator: Astro — generates pure HTML with zero client-side JS by default, minimising the IPFS payload and maximising load speed across gateway nodes
Content layer: All content (experience, education, projects, blog posts) is authored as local Markdown files with typed frontmatter schemas — no CMS, no API calls at runtime
Hosting: Pinned to IPFS — content-addressed and replicated across the network
Domain: Accessible via wakqasahmed.eth (ENS on Ethereum mainnet) and wakqasahmed.eth.limo as a traditional HTTPS fallback via the eth.limo gateway

Why Decentralized?

A centralised portfolio can be taken down, rate-limited, or made inaccessible by a hosting provider, a CDN, or a government firewall. An IPFS-hosted site with an ENS name is censorship-resistant by design: the content is identified by its hash, not by a server’s IP address. As long as any IPFS node holds a copy, the site is reachable.

ENS ↔ IPFS Linking

The ENS name wakqasahmed.eth stores a contenthash record pointing to the IPFS CID of the built site. When the site is updated:

astro build generates a new dist/ directory
The directory is pinned to IPFS (via Fleek or Pinata), returning a new CID
The contenthash record on the ENS name is updated on-chain (one Ethereum transaction)
The new version is globally accessible within seconds via any IPFS gateway

Challenges

Gas costs: Updating the ENS content hash requires an Ethereum transaction. For frequent deploys, this can add up — mitigated by batching content updates.
Gateway fallback: Most users don’t have native IPFS support in their browser. The eth.limo gateway bridges the gap for HTTP clients transparently.
Build determinism: IPFS CIDs are sensitive to file metadata differences. Astro’s build output is deterministic, but CI environments must be pinned to exact Node and dependency versions to avoid CID drift.

Migration from Gatsby + Prismic

The original site (2018) was built on Gatsby v2 with Prismic as a headless CMS. The migration removed all external CMS dependencies, replaced Emotion-styled React components with Astro components and Tailwind CSS, and eliminated the Netlify deployment in favour of IPFS.

The result is a site that is smaller, faster, more maintainable, and owns its own infrastructure.