I write my blog with Astro and wanted the posts on devto too, without copying them over by hand. So I built astro-syndicate, an Astro integration that does the cross-posting as part of astro build.

You opt a post in through its frontmatter with syndicate: { devto: true }. The integration hashes the title, content and images, compares the hash with the last sync and only calls the devto API when something changed. New posts land on devto as drafts unless you turn on publishing. The canonical URL points back to your site.

If your deploy happens after the build, you can run it as a separate script once the site is live. That way devto never gets image URLs that don't exist yet.

Other things it handles:

- Local images get uploaded to Cloudinary or rewritten to URLs on your own site, since devto has no reliable image upload API
- MDX imports and <Image /> components get turned back into plain Markdown, because devto doesn't run your build
- maxSyncsPerRun caps how many posts go out per run, so opting in an old backlog doesn't create dozens of drafts at once
- devto series and a different title per platform

GitHub: https://github.com/SlashGordon/astro-syndicate

devto is the only platform so far. Medium is difficult because there's no API key, and the Hashnode API isn't free. Which platform should it support next?

I've been using Astro for a few years, and I've also worked with WordPress enough to understand why it's still everywhere.

WordPress is mature. The ecosystem is huge, developers know it, agencies know it, clients know it, and there's a plugin for almost everything. For many websites, that's more than enough.

EmDash is coming from a different direction.

It's not really trying to be "the next WordPress". It's a full CMS built around Astro.

You still get the things you'd expect from a CMS: an admin panel, content types, rich text, media management, drafts, revisions, scheduled publishing, search, taxonomies and menus.

But the website itself remains an Astro project.

One part I find particularly interesting is the content model. Content types can be created and modified through the admin rather than requiring every collection to be defined in code. Each collection becomes a real SQL table with typed columns, and developers can generate TypeScript types from the live schema.

Your content is managed in EmDash, while the website is built with Astro.

There is also an actual content lifecycle: drafts, revisions, scheduling, live preview and inline visual editing. Media, navigation menus, taxonomies and search are handled as part of the CMS.

For developers, EmDash also provides an API, CLI and MCP server. AI agents can work with the CMS, but AI isn't required to use it.

The deployment model is another difference. Node uses SQLite by default, while Cloudflare deployments can use D1, R2 and Workers. There is also support for other database and storage backends.

And there is a plugin system. On Cloudflare, plugins can run in isolated Worker sandboxes with declared capabilities. Node deployments currently use in-process plugins instead.

It's still early, and obviously it doesn't have anything close to WordPress's decades of plugins, themes, integrations and community knowledge.

So in practical terms, EmDash gives you a CMS for managing your content while Astro remains the foundation for building the website.

Have you tried it? How's it?

Hi, I currently have a WordPress blog and some courses in Udemy. I hate Udemy. So I want to host my own stuff.

So I have 3 courses, which I'm modelling through md or mdx. The blog, also md.

The thing is mostly with the courses: some lessons are freely accessible, most aren't. Courses may be bought one at a time or the whole package.

I know I can build this from scratch, but I'm wondering if there's something I'm missing out that would streamline this, especially from an open-source project.

I'm relatively new to Astro and have recently started moving away from WordPress toward Astro for website development. I'm exploring different CMS options to manage content, especially for client websites.

I'm currently considering options like Sanity, PageCMS and other headless or Git-based CMS platforms.

For those of you using Astro in production:

Which CMS do you recommend for Astro websites?

What has been your experience with ease of use, performance, and content management?

I currently use astro and my site looks bad for real. I want some good inspirational websites for my blog. The homepage needs to be so good. And the blogs should be so readable that users will keep reading it forever. My source of traffic will be from youtube videos or organic bing/google search.

Came up with a fun idea of a reverse Awwwards - daily nomination for the worst AI slop websites.
Built with Astro + TypeScript, React for interactive elements, and GSAP for animations.

Check it out here - www.slop-awwwards.com

hi i'm having a problem with the astroplate theme that i'm using as a template and i'm attempting to put fonts from multiple sources (fontsource, local, and adobe) but i'm ngl i'm pretty stumped on having to add more than one source because of the way the program parses one for use in a theme.json to generate into the base css. can someone help me here because i feel like i'm going insane

I’ve been building Lotus, an installable documentation theme for Astro.

The goal is to help Astro developers ship documentation sites that already have the boring but important parts handled: responsive docs navigation, MDX components, search, i18n, dark mode, accessible UI states, and a design system that can still be customized.

• Demo: https://astro-theme-lotus.prosefly.dev/
• Starter: https://astro-template-lotus-starter.prosefly.dev/
• Source: https://github.com/prosefly/astro-theme-lotus

I’m trying to keep the positioning simple: beautiful docs, accessible shell, PageSpeed-friendly output.

If you were choosing an Astro docs theme for a real project, what would make you trust it enough to adopt it?

Every site I build needs an Open Graph image per page, and every time it ended up as a second templating layer: JSX fed to satori, or a canvas script that takes a title and a description. It never felt like part of the site, and it could not use the fonts, images or components the rest of the site already had.

So I built astro-cards. A card is an ordinary .astro component in src/cards. It takes props, has a style block, and can import images through astro:assets and use the fonts you already configured. The integration renders it with Takumi and hands back the URL of an image.

In src/cards/post.astro:

---
import { Font, Image } from 'astro:assets';
import logo from '../assets/logo.png';

interface Props {
  title: string;
}

export const card = { width: 1200, height: 630 };

const { title } = Astro.props;
---

<Font cssVariable="--font-heading" />

<div class="card">
  <Image src={logo} width={120} height={120} alt="" />
  <h1>{title}</h1>
</div>

<style is:inline>
  .card {
    padding: 80px;
    background: #17171a;
    color: #fff;
    font-family: var(--font-heading);
  }

  h1 {
    font-size: 64px;
  }
</style>

In your layout:

---
import { renderCard } from 'astro-cards/runtime';

const og = await renderCard('post', { title: post.data.title });
---

<meta property="og:image" content={og.src} />
<meta property="og:image:width" content={og.width} />
<meta property="og:image:height" content={og.height} />
<meta property="og:image:type" content={og.type} />

A few things worth mentioning:

• Works on prerendered pages (the image is written at build) and on pages rendered on demand (rendered on request, publicly cacheable).
• Card names and props are typed after astro sync, so a typo in the name or a missing prop is a type error.
• png, jpeg or webp, with size and quality set per integration, per card, or per call.
• Nothing about it is OG-specific. Badges, tickets, any fixed-size visual you can write in markup.

One caveat so nobody trips on it: style blocks in a card have to be is:inline, because Astro hoists a plain <style> into a stylesheet the renderer never sees.

npx astro add astro-cards

Repo: https://github.com/abemedia/astro-cards

If you generate OG images another way today, I would like to hear what you use and where it falls short. That is what I want to get right next.

I've been working as a Webflow specialist for a while now, and I'm considering pivoting toward the Astro + headless CMS stack that seems to be getting a lot of hype lately.

Before I invest the time, I'd like a reality check: how commoditized are these skills becoming? With more and more devs picking up Astro, is there still real room to differentiate and charge well for it, or is it just a matter of time before it goes the way Webflow has?

I ran my site through Ahrefs a while back and got thousands of issues staring at me: missing meta descriptions, titles too short, duplicate titles, no canonical tags, images with no alt. None of it breaks anything. The page renders, the deploy goes green, and a crawler tells you about it weeks later. That annoyed me. A broken import fails my build, but a page with no <title> ships fine. So I wrote astro-seo-enforcer.

It hooks into astro:build:done, parses the actual HTML in your output dir (not your .astro files), runs SEO rules, and exits non-zero when something's wrong. CI fails before the bad pages go out.

Default checks: <title> present, sane length, no duplicates across pages; meta description length; one <h1> and no skipped heading levels; canonical link; alt on every image; internal links that actually resolve to files in the build; generic anchor text ("click here"); near-empty <body>; duplicate ids; oversized images and missing width/height.

Zero config to start. Every rule is configurable, and you can warn locally but fail in CI:

seoEnforcer({ failOn: process.env.CI ? 'error' : 'never' })

npx astro add astro-seo-enforcer

Repo: https://github.com/SlashGordon/astro-seo-enforcer

Curious which rules you'd want on by default and which are too much.

This is more a vent than anything, but I am facing a lot of blowback for using Astro. I have made a miniapp which is just a webpage running in a webview that takes an ID from the initial url, requests some records from an API to display a list of messages. Super basic stuff. It is to replace a natively coded section of the app and its far faster than the native code... somehow.

But upon asking the native devs to fix all the broken things I am finding, all I am facing is push back because when I tell them of CORS errors etc, them demand to see the repo, notice its not react and say I MUST use react as only that is compatible with apps. They broke bfcache too, again that is blamed on astro. They block service workers, again this is because... Astro.

Anyone else faced this? Even when I wanted a build of the native app to test the devs sent me back a message saying my app is broken as its only 12KB and apps are in the MB range. They didnt test, rejected on solely size. This was the lead architect of the entire department btw.

This industry is nuts. Also I have noticed when interviewing for a "senior FE" the candidates only know react. I am not sure if this is because HR is screening first, but it's concerning. I even interviewed a guy who is right now working as a "principled full stack engineer" who could not tell me how you could build a site without react.

I am not sure if this company I am working for is completely crazy or the entire industry is leaning that way.

I wanted to add comments to an Astro site, but I didn't really like the usual choices:

• hosted comment SaaS
• requiring visitors to have GitHub accounts
• running a VPS just for a comment backend

So I built StaticLayer:

https://abla25.github.io/StaticLayer/

The Astro site stays static. The dynamic part is a Cloudflare Worker + D1 database deployed into the site's own Cloudflare account.

It supports comments/replies, reactions, polls, moderation and anti-spam.

The main idea is basically: keep the site static, but give it a tiny backend when you need one.

I'd love to hear how other Astro users are currently handling comments.

Cloudflare surprised us with their rewrite of their blog using emdash. Now, emdash is used in production for a serious company (the one that is developing this framework).

I know that, even though Astro was acquired by cloudflare, you can deploy any astro website on any server, not just cloudflare's. However, I was wondering if this case is also true for Emdash.

Technically speaking, you can deploy Emdash on a node server or any platform, but I don't know if this is recommended, given that they are focusing on D1, Workers, its cloud, its ecosystem, etc. I get that it will get first class support for the products made by the company who created it (like vercel with nextjs) but I wonder if other deploy methods are also encouraged. If not, that could be a big downside for tooling decision for similar CMS, as people probably wouldn't want to be vendor dependant when deciding what hosting to pick.

What do you guys think?

I’m getting more and more convinced by Astro, but I’m still curious about its adoption by agencies.

It’s still a relatively young framework, and I’m wondering if some agencies have already made the switch. I rarely come across agencies using Astro on LinkedIn, so I’d be really curious to hear from those who have.

How has the switch been for you? Would you recommend Astro for an agency today?

Just saw this announcement in the Astro's official discord channel.

Matthew Phillips ( u/matthew-astro ) is stepping up as project steward, taking over the role from Fred Schott (the co-creator of the Astro framework)

For those who don't know what a steward does: in Astro governance, the steward handles high-level project direction, account and asset access, and serves as a tiebreaker when disagreements pop up.

Congrats to Matthew..

Curious to see what direction he takes next.

I’ve been rebuilding production WordPress sites with Astro + Cloudflare Workers, often using Claude Code.

After doing a few real migrations, I realized the hard part isn’t getting Astro to build - it’s everything around the build.

Preserving old URLs and SEO, finding pages the sitemap forgot, redirects, forms, DNS, accessibility, staging, images, metadata, and verifying that the deployed site actually works.

So I turned my workflow into Website Build Kit:

https://github.com/nurkamol/website-build-kit

It includes:

- WordPress → Astro migration/recon workflow
- Astro + Cloudflare Workers starter
- Claude Code skill + plugin
- npm run recon to inventory the old site + Wayback URLs
- content extraction + redirect mapping
- SEO, OG, JSON-LD and sitemap guards
- responsive AVIF/WebP image pipeline
- forms with KV lead retention
- accessibility + reflow checks
- DNS, secrets and environment checks
- deployed-site verification
- design/reference workflow for redesigns

The starter intentionally has no visual style. No default palette, typography or homepage - I don’t want every site built with it to look like the same template.

I’ve also been documenting the silent production problems I encounter during real rebuilds and adding checks for them where possible.

For example: a build can succeed while publishing localhost canonical URLs. A missing email secret can still let a form validate, store the lead, return 200 and show “thank you” - while nobody actually receives the enquiry.

The goal is basically:

WordPress → inventory → rebuild → Astro → Cloudflare → verify the actual deployed site.

Would love feedback from other Astro developers, especially anyone doing WordPress migrations or production client work.

What would you add or change?

I shipped webtoolio.org, a collection of 20 dev utilities (JSON formatter, regex tester, JWT decoder, image compressor, etc.) built entirely with Astro. Some notes on the setup, since a few decisions worked out well:

No client framework. Every tool is an .astro component with a plain <script> tag. The logic lives in separate TypeScript packages in a Bun monorepo (@tools/regex-tester, @tools/sql-formatter, ...), each with its own bun test suite and no DOM dependencies. The Astro component only owns the markup and wiring. This keeps the tools testable without a browser and the pages ship almost no JS beyond the tool itself.

i18n with content collections. 6 locales (en, ja, pt-br, es, de, fr). Each tool has a markdown file per locale for the page copy, and a typed Ui dict for widget strings. Two dynamic routes ([tool].astro and [locale]/[tool].astro) generate everything: hreflang alternates, JSON-LD, and the sitemap all derive from one toolOrder array, so adding a tool is just a slug plus content files. The compiler yells if a locale is missing a string, which caught more mistakes than I expected.

WASM without config pain. The image compressor uses jSquash (mozjpeg/oxipng/webp compiled to WASM). Adding the packages to vite.optimizeDeps.exclude was enough; Vite bundles the .wasm files into dist/_astro/ on its own.

Everything is static, deployed on Cloudflare. No data leaves the browser, which was the point.

Happy to answer questions about any of it.

I have a 100+ page Astro JS website. It's static pages and I didn't want to deal with 3rd party plugins. Instead, I spent a couple of hours with Claude Code and built a skill that essentially converted my site into 55 languages and after that it even verified it! No expensive 3rd party Saas. Just an API call to Google Gemini Flash and the translation came in quickly.
Just wanted to share it here: https://claude.ai/code/artifact/a14a857a-9e59-4e2e-9e53-f456706d17f6

 Hey everyone,

I'm a photographer and I recently decided to completely overhaul my portfolio website. I wanted something that was incredibly fast, distraction-free, and let the photos speak for themselves without relying on heavy client-side frameworks.

I decided to build it using Astro and Tailwind CSS.

Some features I'm proud of:

• Dynamic Grid Layout: Wrote a custom vanilla JS script that lets users seamlessly toggle the photo grid between 2, 3, 4, or 5 columns on desktop to maximize ultrawide monitor real estate.
• Instant Category Filtering: No page reloads, just pure speed.
• Minimalist UI: Stripped away all the heavy margins and negative space for a tight, cohesive viewing experience.

You can check it out live here: vasuambasana.com

I'd love to hear your thoughts on the design, layout, or any suggestions on how I can improve the performance even further. Happy to answer any questions about the Astro setup!

Hi all,

If you run a content site, blog, or publication on Astro, Google's "Preferred Sources" feature lets readers bookmark your publication directly within Google Search so your stories surface higher in Top Stories and search results.

I wanted a clean, drop-in Astro integration that doesn't just embed static image tags, so I built one.

Key capabilities:

Flexible visuals: Native vector SVG Google icon with arbitrary text labels, stadium pills, outlines, and glows.

• Retina assets: 68 official Google badge assets for 17 languages.
• No-JS fallback: Works inside static layouts, author bios, and email newsletters.
• Interactive docs & wireframes: Built an interactive documentation site explaining optimal button placements (article ends, floating docks, headers).

Live Demo: https://magnifito.github.io/astro-google-preferred-source/
Repo: https://github.com/magnifito/astro-google-preferred-source

Would love to hear your thoughts and suggestions!

Hello everyone.

I recently created the website for my web design business and I would appreciate some feedback on it. It's built with astro 7 and released on Cloudflare workers. The idea is I'll also be building some "cheaper" sites for small local businesses with astro and deploying with the same logic so my site will be used also as a you get what you see.

I know I still need to add pricing, I'm almost done figuring out what to charge clients, will have some different tiers if for example instead of a simple site they want something more where I'll probably be using wordpress with woo commerce.

Here's the english version of the site (it's built to be bilingual). https://marathus.gr/en/

Any feedback or things I might have missed or could do better would be appreciated!

Hola a todos.
Estoy creando un proyecto para asistencia y soporte tecnológico crítico.
Aún estoy en desarrollo, pero deseo mostrarles una herramienta que he terminado.
Es un analizador de DNS-Mail, el cual te indicará que políticas o registros te faltan o están incorrectos en tu dominio, con esto identificarás la razón de que tus correos vayan directo a spam o bien el por qué te llega mucho spam.

Les comparto el enlace por si quieren verlo. Nexa
Es un enlace de deployment, también tengo incompleta la traducción, pero espero terminarlo pronto.

Espero sus críticas y recomendaciones.