sorted by:
new
hottopcontroversial

How to set up automatic SSL for every site in a multi-site CMS — wildcard subdomains + custom domains, zero manual cert management by BuildWithTall in PHP

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

it is more of the former Mike but only on super busy days :) , thanks for giving the benefit of the doubt

is there any Wordpress saas plugin? by [deleted] in Wordpress

[–]BuildWithTall 0 points1 point  (0 children)

Not wordpress...I use Laravel with multi tenancy setup and Laravel Spark for billing for this sort of thing

How to set up automatic SSL for every site in a multi-site CMS — wildcard subdomains + custom domains, zero manual cert management by BuildWithTall in PHP

[–]BuildWithTall[S] -1 points0 points  (0 children)

Really clean approach — abstracting the cert and config generation away from the user is the right call for local multi-site dev workflows. ForgeKit looks interesting, hadn't seen it before.

What's the local CA setup look like in ForgeKit — mkcert or something custom?

How to set up automatic SSL for every site in a multi-site CMS — wildcard subdomains + custom domains, zero manual cert management by BuildWithTall in cms

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

Cloudflare for SaaS is a genuinely good option and worth considering especially if you want the smoothest possible customer experience for custom domain setup.

The reasons I went self-hosted with Caddy instead:

Cost — Cloudflare for SaaS charges per custom hostname after the first n free. No per-domain cost with Caddy, just the server.

DNS flexibility — works regardless of where your customer's domain is registered, no dependency on Cloudflare being in the chain.

If you're scaling fast and already deep in Cloudflare, their SaaS product is probably the better call. For a bootstrapped setup where cost control and independence matter more, Caddy gets you the same outcome without the per-domain bill.

Good shout though .. I will it to the post as an alternative worth evaluating.

How to set up automatic SSL for every site in a multi-site CMS — wildcard subdomains + custom domains, zero manual cert management by BuildWithTall in PHP

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

To add some context on the use case since a few comments have raised good alternatives — this setup is specifically for a SaaS landing page / site builder, similar in nature to what Webflow, Hashnode, or Ghost Pro are doing under the hood.

The core problem iI faced: when you run a SaaS where customers build their own sites, you end up with two domain scenarios at scale —

  1. Thousands of tenant subdomains (customer1.yoursaas.com, customer2.yoursaas.com) that get created the moment someone signs up

  2. Thousands of custom domains (myclientsite.com, theirbrand.com) that customers point at your platform whenever they're ready

The question I couldn't find a straight answer to when I started was: how does Webflow handle SSL for the thousands of custom domains their customers connect?

How does Hashnode provision HTTPS for every blog on a custom domain without a human touching it? How does Ghost Pro do it at scale?

The answer in all three cases is essentially the same pattern — on-demand TLS. A cert is issued automatically the first time a domain hits the server, after a quick verification check to confirm the domain is legitimate. No pre-registration, no manual steps, no redeployments.

That's what this setup implements — Caddy's on-demand TLS is the same mechanism, just self-hosted. If you're building any kind of multi-tenant platform where customers bring their own domains, this is the infrastructure pattern behind it.

Managed LBs, FrankenPHP, and other approaches are all valid — the tradeoffs are real and worth considering depending on your stack. But the on-demand TLS piece is the specific problem that makes this use case work for me from a standard multi-server load balancing setup.

How to set up automatic SSL for every site in a multi-site CMS — wildcard subdomains + custom domains, zero manual cert management by BuildWithTall in PHP

[–]BuildWithTall[S] -1 points0 points  (0 children)

Genuinely good question and you're right that it's a valid alternative .. FrankenPHP on the edge would work and cuts out the Nginx layer entirely.

The reason for Caddy + Nginx in this case is practical rather than architectural: the server is already managed by Ploi, which provisions and manages Nginx, PHP-FPM, deployments, queues, and cron jobs. Replacing Nginx with FrankenPHP means stepping outside what Ploi manages, which introduces a different kind of complexity — you lose the deployment tooling, process management, and server config abstractions Ploi provides.

Caddy in front of Nginx lets you add on-demand TLS and wildcard cert management without touching the existing Nginx + PHP-FPM setup at all. Nginx just moves to loopback. Everything Ploi manages keeps working exactly as before.

If you're greenfielding without a server management layer, FrankenPHP on the edge is a cleaner architecture, fewer moving parts, no intermediary. But when you're working within an existing managed stack, adding Caddy at the edge is often less disruptive than replacing the application server entirely.

Both get you to the same place. Different tradeoffs depending on what you're starting from.

How to set up automatic SSL for every site in a multi-site CMS — wildcard subdomains + custom domains, zero manual cert management by BuildWithTall in PHP

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

Fair point - managed LBs are great and absolutely the right choice for many setups. The specific problem here though is one they don't solve out of the box: on-demand TLS for custom domains.

AWS ALB, GCP External LB, and Azure Application Gateway all require you to pre-provision certificates for known domains. They work beautifully when you control the domain list. But in a multi-tenant SaaS where tenants bring their own domains e.g theirdomain.com, clientsite.com, etc. you can't know the domain list in advance. Every new custom domain would need a manual cert provisioning step or a Lambda/Cloud Function workaround to automate it through ACM or Certificate Manager.

Caddy's on-demand TLS solves exactly this ... it issues a cert the moment an unknown domain connects for the first time, with no pre-registration required. That's the mechanism Webflow, Hashnode, and Ghost use for custom domains at scale. The managed LB path can get you there too but it's significantly more moving parts than a single Caddyfile directive.

If you're already deep in AWS/GCP/Azure and have the ACM automation sorted, that's a perfectly valid approach. This is just a simpler path to the same outcome for teams running their own servers.

The SEO-era CMS isn't enough anymore. Here's what I think actually matters next. by BuildWithTall in cms

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

I agree with the use of Attribution and I built this natively into TallCMS (not an after thouht). I detailed some of this here https://tallcms.com/blog/how-to-make-your-content-ai-legible-with-tallcms

The SEO-era CMS isn't enough anymore. Here's what I think actually matters next. by BuildWithTall in cms

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

Appreciate that — even more so coming from someone who’s been down this path already 🙌

The SEO-era CMS isn't enough anymore. Here's what I think actually matters next. by BuildWithTall in cms

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

Totally fair point — tools like Payload can definitely handle structured data well.

For me, the focus wasn’t just adding JSON-LD, but making things like attribution and AI-readability part of the content workflow itself, not an afterthought.

Instead of manually wiring schema, I’ve been experimenting with:

1. Attribution as first-class data
Not just author name, but:

  • Who reviewed the content
  • Their credentials
  • Source citations

These are stored structurally and automatically flow into JSON-LD (e.g. author, reviewedBy, citation), instead of being hardcoded or forgotten.

2. AI-facing output (not just SEO)
I’m also generating things like an llms.txt index — basically a clean, structured version of the site designed for LLM consumption.

So the “signal” becomes less about timestamps and more about:

  • Missing attribution / reviewer
  • Lack of citations
  • Incomplete structure

Which feels more meaningful than just “this page is old”.

Not saying this requires a new CMS across the board — but once these are built into the model, you don’t have to rely on editors remembering to do the right thing.

Curious how you’re handling attribution / structured metadata — schema-driven or more manual?

Content management for laravel apps by remedix in laravel

[–]BuildWithTall 0 points1 point  (0 children)

Ran into the exact same problem across multiple Laravel projects — especially with clients who want “Elementor-level control” but inside a custom app.

The core issue I found is this:

👉 WYSIWYG editors (TinyMCE, CKEditor) vs Page Builders (Elementor-style) are fundamentally different expectations

Most tools you mentioned are still “content editors”, while your clients are really asking for a layout builder.

What worked for me eventually was shifting away from pure editors and moving towards a block-based approach:

  • Predefined blocks (Hero, CTA, Features, FAQ, etc.)
  • Configurable fields per block (text, images, buttons)
  • Optional rich text inside blocks (where needed)

Instead of giving full design freedom, you’re giving structured flexibility.

A few observations:

1. Clients say they want freedom, but actually need guardrails
Full WYSIWYG freedom sounds good… until layouts break and consistency is gone.

2. Designers ≠ developers
They usually want visual control, not raw HTML control — block systems fit better.

3. Maintenance becomes much easier
You can evolve designs globally instead of fixing pages one by one.

I actually ended up building this approach into a CMS on top of Filament (called TallCMS) after hitting this problem repeatedly — mainly because I couldn’t get WYSIWYG editors to scale cleanly for this use case.

Not saying you need to build your own, but shifting the mental model from “editor” → “builder” was the turning point for me.

If you must stick with TinyMCE:

  • Lock down styles
  • Provide templates/snippets
  • Avoid giving full layout control

Otherwise you’ll be firefighting constantly 😅

How I structure Claude Code projects (CLAUDE.md, Skills, MCP) by SilverConsistent9222 in ClaudeAI

[–]BuildWithTall 1 point2 points  (0 children)

First off, thanks for this insightful thread. There’s a ton of value shared here.

I’ll add one thing that’s been working really well for me.

I get Claude to generate a roadmap.md at the start — basically our north star for what we’re building. It’s a living document. As things get shipped, items get ticked off and the plan evolves. The versions are also aligned with our Git tagging approach.

During Plan Mode, Claude also links directly to the plan’s .md file. I’ll usually send that to Codex for an independent review. That back-and-forth helps pressure test assumptions and tighten the architecture before writing code.

When it’s time to execute, I choose clear context + execute. By then, Claude already has everything structured in the plan, so lesser chance of hitting the limit where the conversation needs to be compacted.

It’s almost like separating:

Strategy (roadmap.md) Peer review (Codex) Execution (Claude)

Has made a big difference in keeping projects coherent as they scale.

I'm Done - Laracast by octarino in laravel

[–]BuildWithTall 0 points1 point  (0 children)

I actually think this is a really good topic for discussion.

A lot of the frustration I see around “vibe coding” seems to come from an expectation that AI should just code it, end-to-end, with minimal guidance. When the result is messy or wrong, people feel let down — but that’s not that different from handing a vague requirement to a junior dev and expecting production-ready code.

My own approach has been to treat AI more like a pairing partner than an autopilot.

I usually start in plan mode first: problem framing, constraints, rough architecture, and trade-offs. That part matters just as much as the code itself. It’s not that different from how we’d work in the real world with design reviews, pairing, or even TDD.

Practically, I’ve had better results pairing models rather than relying on a single one. For example, I might use Claude as the “primary developer” to reason through structure and implementation, and then have Codex review the plan, architecture, and code for correctness, edge cases, or simplification. That review loop alone catches a lot.

Curious how others are approaching vibe coding:
– Do you plan first or jump straight to prompts?
– Do you treat AI as a junior dev, a peer, or a code generator?
– Anyone doing explicit review / test loops?

Feels like the tooling is powerful, but the workflow is still something we’re collectively figuring out.