Skip to content
aishoo
Go back

Modernizing aishoo.com: A Technical Roadmap from GitHub to Cloudflare

Building aishoo.com required more than just aesthetic choices; it demanded a robust, automated infrastructure. As I shifted from a legacy setup to a modern stack (Astro + Cloudflare Pages), I encountered several technical hurdles that define the current state of professional web development.

This post serves as a guide for my future self and anyone looking to balance “Perfect Logic” in infrastructure with “Beautiful Pathos” in content.

1. Identity Isolation: GitHub Account Setup

To maintain a strict boundary between my corporate responsibilities and my personal brand (aishoo), I established a dedicated GitHub identity.

# Local configuration to ensure correct commit attribution
git config --local user.name "aishoo"
git config --local user.email "admin@aishoo.com"

2. Debugging the Pipeline

The journey from local code to a live site involved solving three specific “boss-level” errors:

A. The Authentication & Buffer Barrier

When pushing the initial project, the volume of assets and the presence of GitHub Actions required adjusting the Git buffer and the Personal Access Token (PAT) scopes.

# Increasing buffer size for large asset pushes
git config --local http.postBuffer 524288000

Key Insight: For repositories containing GitHub Actions, a PAT must have the ‘workflow’ scope, or the push will be rejected by GitHub’s security layer.

B. The “Ghost Route” Conflict

My initial configuration included dynamic redirects within the astro.config.ts. This caused the Astro builder to look for non-existent files, leading to a GetStaticPathsRequired error.

The Fix: I moved the logic out of the Astro config and into a Cloudflare-native _redirects file.

# public/_redirects
/column/* /posts/:splat 301
/finance/* /posts/:splat 301
/outdoor/* /posts/:splat 301

C. Image Resolution in Markdown

Astro’s build engine (Vite) is strict about asset paths. Referencing images as images/sample.jpg leads to broken builds. Prepending a forward slash /assets/images/sample.jpg ensures the engine looks in the public directory correctly.

3. The Result: Automated Resilience

By connecting the GitHub repository to Cloudflare Pages, the workflow is now fully automated. Every git push triggers a global deployment across Cloudflare’s edge network.

This architecture allows me to focus on what truly matters: crafting the narrative of aishoo.


Next Steps for aishoo.com: Currently, I am refining the visual identity and auditory presence (Japanese Phonk) of the site. The infrastructure is now ready to support the weight of the pathos to come.

Building aishoo.com required more than just aesthetic choices; it demanded a robust, automated infrastructure. As I shifted from a legacy setup to a modern stack (Astro + Cloudflare Pages), I encountered several technical hurdles that define the current state of professional web development.

This post serves as a guide for my future self and anyone looking to balance “Perfect Logic” in infrastructure with “Beautiful Pathos” in content.

1. Identity Isolation: GitHub Account Setup

To maintain a strict boundary between my corporate responsibilities and my personal brand (aishoo), I established a dedicated GitHub identity.

# Local configuration to ensure correct commit attribution
git config --local user.name "aishoo"
git config --local user.email "admin@aishoo.com"

2. Debugging the Pipeline

The journey from local code to a live site involved solving three specific “boss-level” errors:

A. The Authentication & Buffer Barrier

When pushing the initial project, the sheer volume of assets and the presence of GitHub Actions required adjusting the Git buffer and the Personal Access Token (PAT) scopes.

# Increasing buffer size for large asset pushes
git config --local http.postBuffer 524288000

Key Insight: For repositories containing GitHub Actions, a PAT must have the ‘workflow’ scope, or the push will be rejected by GitHub’s security layer.

B. The “Ghost Route” Conflict

My initial configuration included dynamic redirects within the astro.config.ts. This caused the Astro builder to attempt to generate paths for non-existent files, leading to a GetStaticPathsRequired error.

The Fix: I moved the logic out of the Astro config and into a Cloudflare-native _redirects file.

# public/_redirects
/column/* /posts/:splat 301
/finance/* /posts/:splat 301
/outdoor/* /posts/:splat 301

C. Image Resolution in Markdown

Astro’s build engine (Vite) is strict about asset paths. Referencing images as images/sample.jpg leads to broken builds. Prepending a forward slash /assets/images/sample.jpg ensures the engine looks in the public directory correctly.

3. The Result: Automated Resilience

By connecting the GitHub repository to Cloudflare Pages, the workflow is now fully automated. Every git push triggers a global deployment across Cloudflare’s edge network.

This architecture allows me to focus on what truly matters: crafting the narrative of aishoo.


Next Steps for aishoo.com: Currently, I am refining the visual identity and auditory presence (Japanese Phonk) of the site. The infrastructure is now ready to support the weight of the pathos to come.


Share this post on:

Next Post
Rebuilding aishoo.com: Why I Migrated from WordPress to Astro in the AI Era