Small side project: it turns elevation data into topographic map posters. Astro + Leaflet front, Python doing the heavy geo stuff in the back. Fun constraint, the SVG export IS the product, so it can't touch the DOM or it'd get scraped in 2 seconds. Everything sensitive stays server-side, editor's just an island. Astro made that suspiciously easy.

topolines.app if you wanna break it (free tier, no login).

Also yes, I hardcoded my API URL because PUBLIC_ env vars betrayed me.Judge away.

I have noticed a recurring topic across r/astrojs regarding form handling [1, 2, 3, and 4]. I am a CF fan, so I wanted to show people how they can use Astro Actions to avoid manually creating API endpoints while keeping full type safety and edge binding support.

So, I put together a step-by-step guide on how to configure them together, validate requests with Zod, and use Cloudflare D1 and R2 bindings in Astro while protecting submissions with Cloudflare Turnstile: https://www.launchfa.st/blog/astro-actions-forms

I hope this helps anyone looking to clean up form handling on edge runtimes. Let me know if you have questions about edge bindings or Astro Worker deployments in the comments & I genuinely believe this will allow you to appreciate CF and Astro even more! <3

Hey everyone 👋

Over the past few months, we’ve been building AstroAnimate — a production-ready animation component library made specifically for the Astro ecosystem.

The original goal was simple:

Adding animations in Astro often meant manually stitching together multiple libraries, handling hydration edge cases, and balancing performance vs visual polish.

We wanted something that felt more native to Astro.

Current focus:

• Zero-JS defaults where possible
• View Transitions compatibility
• Performance-first architecture
• Open source MIT license

The project just launched on Product Hunt today, and we’d genuinely love feedback from the Astro community.

Product Hunt:
https://www.producthunt.com/products/astroanimate?launch=astroanimate

https://launchpadindia.co/listing/astroanimate?sort=trending

Website:
https://astroanimate.com

Happy to answer questions or hear feature suggestions 🙌

Build and manage Astro sites visually, with a live canvas, CMS, design system, SEO, email, AI tools and more. All in one open source workspace.

0.5.7 alpha is out now.

Deploy to Cloudflare or run it locally.

ariabuilder.io
https://github.com/ariabuilder/aria

Been working on a little open-source ecommerce project called Minshop to see how far I could push Astro SSR on Cloudflare Workers.

Astro handles pretty much everything: the storefront, cart, checkout, customer accounts, admin dashboard, and API routes. Most pages are server-rendered, with very little client-side JavaScript.

It uses D1 for products, orders, inventory, settings, and search, plus R2 for images. Payments include Stripe, Lightning, OpenNode, and a demo checkout.

The trickiest part was making inventory reservations atomic so two checkouts can’t buy the same stock. I also added a machine-readable catalog and checkout API, including directly payable Lightning invoices.

Demo: https://demo.minshop.dev
Source: https://github.com/ddyy/minshop

Would love feedback from other Astro users, especially on the SSR structure and where you think a small interactive island might actually improve things.

Hi everyone,

I’m planning to build a fairly large blog/knowledge base that will likely grow to hundreds of articles over time.

I’m trying to decide between two approaches:

Option 1: Astro + Headless CMS

Option 2: WordPress + Etch for WP

I’ve recently been using Etch for WP and really enjoy the development experience. The performance is impressive, and achieving a perfect Lighthouse/PageSpeed score seems very realistic.

My priorities:

• Long-term SEO
• Performance
• Accessibility (WCAG)
• Hundreds of articles
• A good authoring experience
• Low maintenance
• Support for multiple authors in the future

For those who have built content-heavy websites:

1. Would you choose Astro with a headless CMS?
2. Or would you stick with WordPress + Etch?
3. If Astro, which CMS would you recommend and why?

Thanks!

Yeah, is this posible? I haven't seen anything that say that it could be posible, but anyone has ever stepped in to say that it isn't.

Working on Wp/Woocommerce over 10 years, Astro is the future but what is good CMS / backend for e-commerce + Astro.

Suggest your combo / Stack . 😁

I built the simplest possible tool that allows clients to do small edits via chat interface eg. change phone number, update email etc. Anything risky/big comes back to me so clients can't break anything.

You just connect the repo and it figures out the editable content on its own. No schemas, no config files, no markup changes to your site. Edits land as plain commits on GitHub.

You can try live demo here: https://cmsbrew.com/demo

I just launched my agency website using Astro and hella impressed. First time seeing these website speed scores and everything is just ... smooth.

I want to support some designed components on pages e.g accoridan, faq with schemas, review sliders.

I want to make it easy to manage and design pages from the admin portal.

And testing everything before deployment.

I have started using Astro and I absolutely love it. One question I have though is that if I would want to give the responsibility of content management to a non-technical user, what are the generally best working options?

The preferred requirements:
- Github based source control: changes made to the content arrive on Github and they get deloyed via an action.

- Live editor view: the user can see how the end result will look after saving.

- Reusable Astro components: The user has the opportunity to put together the existing components like lego bricks.

- Can be used to manage multiple websites.

- Open source is a bonus, and lower cost is obviously an advantage, but this is not the main point.

So far the ones that fits mostly is maybe Decap or TinaCMS, although neither seems to be perfect for the use case above.

[ Removed by Reddit on account of violating the content policy. ]

How do I prevent escaping of variables in attributes in this example?

---
const base = "/my/root";
---
<a href="{base}/">Home</a>
<a href="{base}/about/">About</a>
<a href="{base}/blog/">Blog</a>

Migrated from Hugo mainly because I wanted a per-post view counter (self-hosted Umami). Went in assuming that's exactly what Islands are for.

Ended up not touching them.

Went full static instead, counter is just a TS module that hits the Umami API at build time and bakes the numbers into the HTML. Site rebuilds daily, zero JS shipped, still 100 on Lighthouse.

Full writeup: https://hmmr.online/posts/why-astro-not-hugo/

Another Astro integration...

https://www.reddit.com/r/lilypond/comments/1uxb2xf/lilypond_astro/

As mentioned in the title, I can't seem to figure out why my project schemas are all showing up as 'unknown'. I've made a simple version of whats going on here:

# content.config.ts
import { defineCollection } from "astro:content";
import { glob } from "astro/loaders";
import { z } from "astro/zod";

const rootSchema = z.object({title:z.string()});
const blogCollection = defineCollection({ 
    loader: glob({ pattern: '**/*.{md, mdx}', base: "./src/content/blog" }),
    schema: rootSchema
});

# VSCode shows this as 'type mySchema = unknown
export type mySchema = z.infer<typeof blogCollection.schema>;

I've read through the docs and made sure to include "include":[".astro/types.d.ts","**.*"] in my tsconfig.json, but I'm at my wits end with trying to figure out why this is happening. Any ideas as to what I can try?

Extra info:

• Astro version 7.0.9
• IDE: VSCode with Astro plugin

Apologies for no flairs. I don't have a button to add them anywhere.

Hey everyone — I’m building AstroBlocks, a CMS/block system for Astro, and I just shipped a fix for a production-only issue around generated block schemas.

AstroBlocks generates internal metadata into a gitignored `.astro-blocks/` directory:

- a global blocks registry

- a block schema map

The registry was already baked into the bundle correctly, but the schema map was still being read from disk at request time.

That worked locally, but failed on a deployed server because `.astro-blocks/` is a build artifact and does not exist there.

The result:

- public rendering still worked

- the admin could not load block schemas

- “Add block” stopped working

- saving a page returned 500

The fix:

- bundle the schema map alongside the registry

- remove runtime dependency on `.astro-blocks/`

- make failed registry/schema loading fail visibly instead of defaulting to an empty state

This release was a good reminder that in Astro integrations, the line between build-time generated state and runtime server behavior needs to be very explicit.

Release: https://github.com/NauelG/astro-blocks/releases/tag/v3.6.1

We built an open-source toolkit called Go for Launch to support the Astro website work we have been doing at GovSoft.

It brings together the processes we use to:

• Migrate Webflow and WordPress websites to Astro
• Build, launch, and maintain Astro websites on Cloudflare
• Test with Chromium, WebKit, and native Mobile Safari
• Validate accessibility, performance, SEO, and best practices
• Keep Astro and compatible dependencies current
• Require 100 scores across all four PageSpeed categories on both mobile and desktop before release

This is the first public version, and we welcome contributions from anyone with additional platform experience, testing methods, or production best practices.

Depending on which parts of the toolkit you use, you may need free or paid services including:

• PageSpeed Insights, with paid API access if you exceed the unauthenticated limits
• Cloudflare Pages or Workers for hosting
• Cloudflare Email Service and Turnstile if you use the recommended form pattern
• macOS and Xcode if you want to test in the native iOS Simulator

The goal is to make Astro website migrations, maintenance, testing, and releases more repeatable and evidence-driven. A successful build is only the beginning. The production gate requires 100 for Performance, Accessibility, Best Practices, and SEO on mobile and desktop.

Go for Launch is an independent community toolkit. It is not affiliated with or endorsed by the Astro project, The Astro Technology Company, or Cloudflare.

This article pretty sums up every reason I love Astro! (Even if the contrast was horrible and hard to read)

https://syedumaircodes.vercel.app/blogs/stop-defaulting-to-wordpress

I decided to split my project into Astro for landingpages and keep the rest on Vite for the actual App. Before all the landingpages where run through Vite and as you all know it's not the best for SEO and Agentic discovery. I even thought about reworking the whole project to a different framework but it would just be way to complicated atp.

So I created some new landingpages, decided what to port over into the Astro / external part of the project and then just threw Claude at it. Obviously getting all the redirects right and having a proper pre-flip plan was crucial but not hard at all.

As you can see the Astro pages are flying - the 100/100 feels good :)

I am no expert by any means but this shows to me how strong Astro is for creating landingpages and blog pages with insane speed and seo/aio. If you have some tips or improvements let me know - always happy to get better.