caddydemo.final-v2.xyz Open in urlscan Pro
138.68.4.62  Public Scan

Submitted URL: http://caddydemo.final-v2.xyz/
Effective URL: https://caddydemo.final-v2.xyz/
Submission: On July 17 via api from US — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

A ZeroSSL Project Store Forum GitHub Theme: system
 * Documentation
 * Features
 * Account
 * Support

Download Sponsor


YOU JUST GOT SERVED
... A DYNAMICALLY-PROVISIONED TLS CERTIFICATE BY CADDY!


WHAT HAPPENED?

Caddy automatically obtained a certificate for your domain,
caddydemo.final-v2.xyz, without any change to the server's configuration. We
call this technology On-Demand TLS, and it's an exclusive feature of Caddy.

With On-Demand TLS, no config changes are required to serve more domains over
HTTPS. This is perfect for servers hosting content or APIs for customer-owned
domains because your HTTPS deployment scales as tall and wide as your business
does.

Caddy's technology is the secret sauce of many SaaS products that offer custom
domains. It generates hundreds of thousands of dollars in revenue every year
while saving businesses tens of thousands of dollars in development and
maintenance costs.

Fun fact: this feature earned standing ovations at more than one tech demo back
in 2015 and 2016 when it was first introduced.


EASY, SELF-HOSTED HTTPS FOR CUSTOMER DOMAINS

Use On-Demand TLS to grow your custom-domain SaaS business in a matter of
minutes. A minimal config looks like this:


1. PREVENT ABUSE

First, you'll configure an internal endpoint that Caddy can "ask" if a
certificate should be allowed for a domain. This endpoint usually looks up the
domain in a list or database and returns HTTP 200 if it's allowed. Make sure to
reject domains you don't recognize. (This implies that customers have to tell
your app what their domain is first.)


2. ENABLE ON-DEMAND TLS

To finish, enable On-Demand TLS for a catch-all site.

{
	on_demand_tls {
		ask http://localhost:9123/check
	}
}

https:// {
	tls {
		on_demand
	}
	# reverse_proxy, etc...
}

# other sites...


Actual production configs typically have more, but this is the minimal
configuration needed to serve domain names that aren't in your control. All
that's left is for the domain owner to set their DNS records (described below).


BRILLIANT CUSTOMER EXPERIENCE

For domain owners, the flow is even simpler: set DNS records. The first visit to
their site will provision a TLS certificate. Works like magic!


1. POINT DNS RECORDS

The customer sets either a CNAME record or A/AAAA records on a domain or
subdomain they control, so that their domain resolves to your server's IP
address.

# Customer's DNS (example domains) your-app.customer.com CNAME -> your-app.com #
Your DNS (example IPs) your-app.com A -> 198.51.100.1 your-app.com AAAA ->
2001:db8::

There is no step 2. Caddy will obtain and serve a certificate for their domain
as soon as a connection is made to it. Caddy keeps the certificates renewed as
long as connections keep coming in. Once they stop, Caddy will let the
certificate expire and then delete it automatically.

And that is how you save tens of thousands of dollars in development and
infrastructure costs every year.

A free open source project that relies on sponsors.

Privacy-respecting analytics by Fathom


© 2024 ZeroSSL. All rights reserved.

Project
Features Download Documentation
Business services
Support Sponsorships
Community
Forum GitHub Twitter / X Research

Caddy supports an open Web that promotes privacy, preserves data ownership,
fosters innovation, freely allows varieties of client software, and safeguards
human sanctity.