I'm building a multi-tenant events platform on AWS. The React frontend is stored in S3 and served through CloudFront. Each tenant currently uses a platform subdomain such as tenant.stage.example.com, with a wildcard CloudFront certificate. The frontend reads the hostname and asks the backend which event to display. API requests use a separate fixed domain, so custom domains are only needed for serving the static frontend.
Customers now want to use domains such as portal.clientbrand.com. I need TLS certificates to be issued and renewed automatically without manual work for each customer. I'm considering automating CloudFront distributions and ACM certificates, using CloudFront SaaS Manager, running Caddy with on-demand TLS, or paying for a managed custom-domain service.
The platform will probably grow to a few hundred custom domains rather than several thousand. Has anyone shipped CloudFront SaaS Manager in production, and what issues did you encounter with certificate provisioning, DNS validation, limits, or pricing? Since the custom domain only serves static content and the API remains on a fixed hostname, would Caddy be unnecessary complexity? I'd also appreciate experiences with manually automating CloudFront and ACM, especially from anyone who later wished they had chosen a different design.
4 Answers
Caddy can handle this at surprisingly large scale. One production setup reportedly serves around 2,000 real sites on a small instance with on-demand TLS. The important safeguards are an allowlist or validation endpoint for the on-demand certificate requests, so arbitrary hostnames cannot consume certificate-issuer limits. It also helps to keep the proxy focused on HTML and serve static assets through a proper CDN on a separate hostname. Content can be organized in S3 by domain, allowing new customers to be onboarded without changing the proxy configuration.
Your static-only setup makes the simpler options much more attractive. S3 does not care about the incoming Host header, so serving the frontend through a shared CDN is relatively straightforward. The complexity increases when an origin routes based on Host. For example, forwarding viewer host headers through CloudFront to an API Gateway endpoint can cause the gateway to reject the request because it cannot map that hostname. Keeping the API on its fixed domain avoids that entire class of routing problems, so Caddy may be unnecessary unless you specifically need its certificate or hostname automation.
A managed edge provider with a SaaS custom-hostname product can be a very practical choice here. It handles certificate issuance, renewals, and hostname onboarding, and people have reported running it successfully for years. The tradeoff is ongoing cost and putting another provider in the request path, but that may be worthwhile if avoiding operational work is the priority.
Be careful with apex-domain support when evaluating the CloudFront SaaS approach. If customers need to point the bare domain directly, or automatically redirect it to www, you may need an Anycast IP feature, which can add a substantial fixed monthly cost. Requiring customers to create an ALIAS, ANAME, or equivalent record is cheaper, but support varies by DNS provider and the terminology is inconsistent.
Related Questions
How to Build a Custom GPT Journalist That Posts Directly to WordPress
Cloudflare Origin SSL Certificate Setup Guide
How To Effectively Monetize A Site With Ads