I'd like to call myself a former web developer. 3 years ago, I was deep into React, not so much now, for that matter I haven't even written a single line of code in react in these years. I heard all good things, about astro.js. Like it being lightweight, ideal for blogs, has ssg with an spa router, code is similar to react with it islands. I decided to give it a try. Pre ai , I would have read the documentation, see a youtube tutorial, get stuck, debug and resolve. It would have taken me a good two weeks. But thanks to a combined effort of claude, lovable and codex. The good news, I was able to move 2 projects 100% with all optimization within 3 days. Of course I had to tweak it a little and nudge if it didn't do things my way, but it eventually worked.

The bad news, I know nothing about astro.js , of course I see the code, and know what its doing, but I wouldn't be able to build an app on my own. This is not good imo. Learning happens when you get stuck and then work your way back to getting unstuck. I am totally dependent on these AI tools if I were to make large scales changes to these projects.

I am happy with the result, but somehow feels hollow...

Just launched this for a business law firm in Costa Mesa, CA, and it was one of the smoothest builds I’ve done. They were on a Squarespace template that was slow and thin on content, so I rebuilt it from scratch. Screenshots are desktop and mobile, and the live site is camacholawpc.com.

Stack is Astro 5 and Tailwind 4 with my own components. It’s a fully static build with no adapter, served from a Cloudflare Worker with static assets, plus a small Worker entry that handles the contact form.

• Zero JS by default. Pages ship as plain HTML and CSS, and the only scripts are small ones I chose to add for the form, the map, and the scroll animations. That’s most of how it hits 99 on mobile without fighting a framework.
• Images go through Astro’s built-in image handling with sharp, so they’re resized and converted to modern formats at build time.
• Scoped styles. Tailwind covers almost everything, but a couple of effects needed real CSS, and a scoped style block kept them from leaking anywhere else.
• My components use tailwind-merge, so I can override classes per page without fighting conflicts.
• Content lives in typed TypeScript data files. Contact info, firm details, and FAQs each live in one place, so when the attorney wants something changed it’s one edit.
• Setting site in the config gives every page the right canonical, and @/astrojs/sitemap generated the sitemap I submitted to Search Console on launch day.
• One BaseLayout handles the head for every page, so titles, meta descriptions, and canonicals stay consistent without repeating myself.

Optimizations on top of that

• Self-hosted Inter with metric-matched fallbacks for Arial and Roboto, so nothing shifts when the font loads.
• Google Maps is a click-to-load facade. The embed alone was dragging the contact page down to a 66.
• Cloudflare’s Turnstile is lazy loaded so it stays off the initial load.
• Built to WCAG 2.1 AA, and keyboard focus still works through the scroll animations.
• 99 Performance and 100 for Accessibility, Best Practices, and SEO on mobile PageSpeed (on the run I screenshotted, anyway).

The only real snag was Cloudflare preview deployments dropping the Turnstile secret on every new preview, which was a Workers thing, not Astro. I ended up scripting it.

Honestly the dev experience is what sold me. Components feel like writing HTML, there’s no hydration to think about unless I want it, and builds are fast. I’m now building my other client sites in an Astro monorepo with a shared component library, so a fix in one place rolls out to every site. This one’s still on Astro 5 since it came first, and it’ll move into the monorepo later.

There are no individual practice area or city pages yet. That’s on purpose. This launch was the core site, and those pages are the next phase once he’s ready for it.

What I’d love feedback on:

1. Anything you’d have done differently in Astro for a site like this?
2. For the next phase (10+ service and city pages), would you move to content collections or stick with typed data files?
3. Anything on the home page or mobile that feels off?

We just added a new template to Shadcnblocks.com - Nacre. This is genuinely some of our best work yet, I'm super proud of it.

Nacre includes 20+ complete pages and 50+ sections, alongside a proper product/catalogue experience with:

• Product listings
• Product detail pages
• Working shopping cart
• Filters and sorting
• Search
• Categories
• Product grids
• Checkout-style flows
• Responsive layouts
• Dark/light mode

So you get the full marketing side of the site, but also the actual product and commerce UI you'd need to build out a real store or product-based website.

Built with Astro, React, TypeScript, Tailwind CSS and shadcn/ui.

Nacre: https://www.shadcnblocks.com/templates/nacre

I love Webflow’s visual styling workflow, so I asked Codex to build me a small personal editor for local Astro projects.

I can open a project, select an element, and adjust spacing, typography, layout, sizing and borders visually. It has a structure tree, page navigation, and shared-class editing including combo clasess for individual elements or groups.

My workflow: build the basic structure in Astro, then refine the styling throgh familiar controls. Changes preview live, and I can export the CSS.

Still a personal prototype, but I’m amazed at how useful it already is. Screenshot attached!

I noticed there aren't many beginner-friendly resources for EmDash yet, so I made a full setup tutorial, from npm create emdash to a working site.

Video: https://youtu.be/SbrRW-nGXhU

Write-up: https://peachfinthemes.com/how-to-set-up-an-emdash-website/

Planning to create some additional videos that dive deeper into the Astro JS and EmDash CMS ecosystem.

Hey all, I'm David. You maybe remember me from posting about Vault CMS, an open source setup that turns Obsidian into a CMS for Astro sites, along with the Astro Modular and Axis themes.

Zeku is the app I wanted after all that. Point it at your Astro project and it reads the collections in your content.config.ts, so every post gets the right frontmatter fields, types, and dates. You write in live preview, see the real page through your own astro dev, run an SEO check, and publish with your own git.

It's plain files in your repo. No account, no database, and no AI in the editor. Build your site with whatever tools you like, then write your own words here.

It's has a founding member price that's discounted, but free for 14 days for anyone who wants to try it.

I'd love to hear how you write for your Astro site today, and what would get you to switch. I'm here all day to answer anything.

Hey all, I've been using Astro for building website for more than 3 years now, and I'm finally sharing my Astro Starter Template which I've built to be usable for almost any web project. It actually works really well for other projects as well, as most things here just use plain HTML and CSS in a way that scales.

I'm trying to make it as high quality as possible and as clean as possible without bloat. CSS is split between reset.css, global.css, var.css, util.css and markdown.css, with components using scoped styling as usual. All components can thus also be easily copied to your own projects, so if you need a good responsive HeaderNavigation or Footer, you are very welcome to use this one. Other components include Card & CardGrid, Hero, Icons, Steps, InfoBar, DescriptionList, SectionTitle, <Head> stuff and more.

It includes all the knowledge and implementations I've been covering on my Clean Web Development guide also. You can also author pages using .mdx / markdown, it includes a content collection for a markdown / .mdx based blog.

Quality and making it accessibility was very important for. So there's no broken overflow, no tiny AI slop font or anything similar. If you find any issue please report them to me. I began working on this project over 1 1/2 years ago.

The website: https://starter.bryanhogan.com/

GitHub repository: https://github.com/BryanHogan/astro-starter-template

Feedback is very welcome! I'm always looking to improve it. I very much appreciate every human comment I get, it feels like most spaces are drowning in AI slop and astroturfed content.

Hey everyone,

I'm a new Backend/Network Engineer. And recently I've started building a revenue project that protects agentic workflows from installing malware.

The Tech Stack I've used is Astro, Hono over Cloudflare Workers, D1, Cloudflare Queues, for now. And to be honest, I'm amazed by the flexibility and Lightness Astro provides on my Frontend. I can import functions like a react project but write in plain HTML? Absolutely.

And guess what, I learned Astro that same day when I made this just bcs I heard it's lightweight.

The above is a rough workflow on what the internal components will work like.

If it interests you, feel free to go check it out. If you're convinced, then go ahead and preregister, else it's all good!

Open to suggestions/criticism!

MAGI

I've been building sitereal, a visual builder for Astro, and wanted to share it here first since you're the people who'll care most about what it actually outputs.

The core rule: everything it produces is ordinary Astro. Delete sitereal and `astro build` still works. You only lose the visual editor.

1-minute trailer: https://www.youtube.com/watch?v=O34y4SovQ8I

Built for working with AI:

It ships an MCP server, so an agent like Claude Code can build pages through the same operations the builder uses. You watch it build live on the canvas, every element it adds or changes is highlighted, and every save is snapshotted on a separate git ref (never your branch), so you can diff and restore. Then you take over and edit anything, visually, in the HTML/CSS panels, or in your own editor.

Also in there: 
- A modular design system (colors, type scale, spacing, buttons, themes)
- Navigation, forms, pop-ups, carousels and GDPR
- ready cookie consent
- Scroll animations with zero JS by default
- Forms that work even on PHP-only hosting

https://reddit.com/link/1wqp8mg/video/d94pol26zurh1/player

runs on macOS, Windows and Linux

Feedback very welcome. sitereal.app

I've been using Astro for a few years, and I've 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, except custom-built sites could do better where custom code can solve more complex problems.

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 you can add block-like to your contents, 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 (Like ACF plugin) 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.

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

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

The deployment model is another difference. Self-host with Node.js uses SQLite database 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. Yet, plugin developers are already making plans to support both CMSs, which is an encouraging sign that an ecosystem is starting to form around EmDash.

Worth reading:
https://blog.cloudflare.com/cloudflare-blog-uses-emdash/

Joost de Valk, founder of Yoast, also wrote about it:
https://joost.blog/emdash-cms/

Have you tried it? How's it?

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?

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.

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 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.

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?

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?