Publishing blog content to a static site shouldn't require a developer. But for most teams running Astro, it does — every new post means a code deployment. We built a way to change that: write and manage content in RequestDesk, click publish, and your static site rebuilds automatically. No git commits. No developer handoff. No waiting.

We wanted something better. Write content in RequestDesk, click a button, and the static site rebuilds with the new post. No git commits for content. No developer handoff required.

Three Approaches We Considered

Option A: Git Push. Generate a markdown file, commit it to the repo via GitHub API, and let the CI/CD pipeline handle the rest. This works, but it clutters the repo with generated files and makes RequestDesk responsible for git operations. Rollbacks get complicated.

Option B: Build-Time Fetch. The static site calls the RequestDesk API during its build step. Astro's getStaticPaths() fetches all posts and generates a static HTML page for each one. A webhook triggers the rebuild when content changes.

Option C: Export and Deploy. Generate the entire site as a zip file and push it to hosting. This skips the build entirely but loses all the benefits of Astro's component system and optimizations.

We went with Option B.

How It Works

When you click 'Publish to Astro' in RequestDesk, three things happen automatically: your content is served from the RequestDesk API, your Astro site fetches it during a fresh build, and AWS Amplify handles the rebuild trigger. From your side, it's one button. Behind it, your site rebuilds with the latest content and stays fully static.

The API Layer

RequestDesk already has an astro-proxy API that serves blog posts. We added a site field to posts so content can be scoped per site. When brent.run builds, it only fetches posts tagged with its site name.

Move API endpoint details to technical documentation. In the blog post, describe the outcome: 'The API delivers everything your Astro site needs for each post — title, content, slug, excerpt, featured image, SEO fields, and publication dates — scoped to your specific site so multiple sites can share one RequestDesk instance without mixing content.'

The response includes everything Astro needs: title, content, slug, excerpt, featured image, SEO fields, and publication dates.

The Astro Side

The key change is replacing SSR with getStaticPaths(). Instead of fetching content per request, Astro fetches all posts once during the build and generates static HTML.

export async function getStaticPaths() {
  const API_URL = import.meta.env.BACKEND_URL;
  const API_KEY = import.meta.env.AGENT_API_KEY;

  let allPosts = [];
  let page = 1;
  let hasMore = true;

  while (hasMore) {
    const response = await fetch(
      `${API_URL}/api/astro-proxy/blog-posts?per_page=50&page=${page}`,
      { headers: { Authorization: `Bearer ${API_KEY}` } }
    );
    const data = await response.json();
    allPosts = [...allPosts, ...data.posts];
    hasMore = data.posts.length === 50;
    page++;
  }

  return allPosts.map(post => ({
    params: { slug: post.slug },
    props: { post }
  }));
}

Each post's data is passed as props, so no additional API calls happen at runtime. The result is pure static HTML.

One detail that catches people: Astro static builds use import.meta.env instead of process.env. Environment variables need to be available at build time, not runtime.

The Publish Button

In RequestDesk, the post editor now has an orange "Publish to Astro" button alongside the existing WordPress (blue) and Shopify (green) buttons. Clicking it:

1. Validates the post status is "published"
2. Lets you select which Astro site to target
3. Calls the Amplify webhook to trigger a rebuild
4. Tracks sync status (syncing, synced, failed)

The webhook is a simple POST request to an Amplify URL. Amplify pulls the latest code, runs the Astro build, and the build fetches fresh content from the API.

Multi-Site Support

We built this with multiple sites in mind. Each site has its own configuration in RequestDesk — domain, build settings, and content scope — so your team always publishes to the right place. If you manage content for multiple Astro sites, each one stays separate: its own content, its own publish workflow, its own build pipeline.

Posts get a site field that links them to a specific site. When you publish to Astro, you pick the target site from a dropdown. The API filters content by site during the build.

This means one RequestDesk instance can manage blog content for multiple static Astro sites. Each site gets its own content, its own webhook, and its own build pipeline.

The Proof of Concept

Replace with a customer-outcome framing: 'We've already rolled this out on a live site — moving from server-side rendering to a fully static build, cutting hosting costs, and keeping all content managed through RequestDesk. The content workflow didn't change. The infrastructure got simpler.' It already fetched content from the RequestDesk API, but it ran on ECS with server-side rendering. Moving to Amplify with static builds cuts hosting costs and simplifies the infrastructure.

The content stays in RequestDesk. The Astro site pulls it at build time. No markdown files in the repo. No server to maintain.

What This Means for You

If your team is managing blog content for a static Astro site and you want to remove the developer from the publishing workflow, RequestDesk's Astro integration is ready. You write and publish in one place. Your site stays fast and static. We're in public beta — if you want to try it, we'd love the feedback. The API delivers content at build time, a webhook triggers rebuilds on publish, and your site stays fully static.

Either remove the specific site reference or frame it as a customer win with proper context: 'We're rolling this out to more e-commerce sites next — if you're managing blog content for a static Astro site and want to remove the developer dependency from your publishing workflow, the integration is ready.' If you want to connect your Astro site to RequestDesk for content management, the astro-proxy API is ready.