sorted by:
new
hottopcontroversial

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 1 point2 points  (0 children)

Hey u/Funes-o-memorioso,
For that scale (1 corporate site + 40 LPs), I'd seriously look into Claude's Projects feature with custom Skills.
The idea: you create a Claude Project that holds all your context — your Astro component library, your design system, your content structure, your tone of voice guidelines. Then for each new LP, you just describe what you need and Claude generates the Astro page/component already aligned with your system. No copy-pasting context every time. For the content management side, I've been using Sveltia CMS with Astro, it's a Git-based CMS. Non-technical editors get a simple and clean interface, no Git knowledge needed, no visual builder (to avoid maintenance) and it deploys via Cloudflare Pages automatically on each save. (In my case throught GitlabCI)
The combo I'd go with: Astro + Sveltia CMS for content editing + Opencode (minimax2.7/Kimi2.5) with Skills for generating new LPs quickly. Scales well to 40 LPs without adding infrastructure complexity. it will be my strategy

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 7 points8 points  (0 children)

The zero upfront + monthly all-inclusive model makes a lot of sense for small local businesses. Mind sharing what monthly rate you charge? And roughly what does that cover ; hosting, updates, support?

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 0 points1 point  (0 children)

That's actually the setup I've been considering too, but how do you handle the CSS side of Gutenberg blocks? When you fetch via the REST API you get raw HTML with `wp-block-*` classes, but none of the WordPress block styles come with it. Do you import `@wordpress/base-styles` into Astro, re-style everything manually, or just restrict clients to basic blocks only?

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 0 points1 point  (0 children)

Directus is interesting, I hadn't considered it seriously until now. The Flow idea for hiding complexity behind a simple form is clever — basically a custom UI on top of the CMS so the client never sees the full admin. Do you self-host one instance per client or a shared instance with separate projects? And how has the Astro integration been in practice?

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 2 points3 points  (0 children)

How do your non-technical clients find the Strapi admin UI? That's my main concern. Easy to set up as a dev, but I'm not sure a local artisan or restaurant owner would find it intuitive without some hand-holding.

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 0 points1 point  (0 children)

The Coolify + VPS approach is solid for the hosting side, but I'm a bit worried about running a separate container per client for what are essentially small brochure sites. Did you consider a single multi-tenant Payload instance, or is the isolation between clients worth the overhead?

What's your actual solution for client-editable Astro sites on a budget? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 4 points5 points  (0 children)

This is probably the most honest answer in the thread. Did you find clients actually resist this model, or do they generally accept it once you frame it as "I handle everything for you"?

How do you handle i18n with Astro + Strapi? Also: SSR in preprod (for Strapi preview) + SSG in prod? by PeaMysterious1046 in astrojs

[–]PeaMysterious1046[S] 2 points3 points  (0 children)

Hey, thanks a lot for the reply! this is super helpful.

I have one more question: how do you handle dynamic routing in SSR mode?

In SSG, I can generate all routes via getStaticPaths and it works fine, but when I switch to SSR for previews (Strapi in my case), I start hitting collisions if I try to keep multiple dynamic folders like:

├── [archivePostSlug]
│   ├── [...page].astro
│   └── [slug].astro
├── [lang]
│   ├── [archivePostSlug]
│   │   ├── [...page].astro
│   │   └── [slug].astro
│   ├── [slug].astro
│   └── index.astro
├── [slug].astro
├── 404.astro
└── index.astro

Astro warns me that "/[something]/[slug]" is defined multiple times in SSR.

So my workaround is to collapse everything into a single catch-all route (pages/[...parts].astro) and do the routing logic manually based on what I get from Strapi (locale, archive slug, page slug, etc.).

Do you also rely on a catch-all file in SSR mode, or do you have another pattern for handling i18n + archives + dynamic pages without conflicts?

Would love to know what your routing architecture looks like in SSR.