SSL
Every site is served over HTTPS from the moment it's live — the free subdomain and any custom domain, both issued and renewed the same automatic way, at no extra cost.
A certificate is a small file that lets a browser confirm two things: that it's actually talking to your site, and that whatever passes between them is scrambled before it leaves. Without one, a visitor's connection sends passwords, form entries and page content in plain text — readable by anything sitting between their device and your server. With one, that same traffic is encrypted, and the browser shows a padlock instead of a warning.
On a Lemonade Host site, that certificate covers your free you.lemonadehost.com subdomain automatically, and it covers a custom domain the same way the moment you point one at your site. There's no separate product to buy and no setting that turns it on — HTTPS is just how every site here is served, from the first deploy through Git, a zip upload, the CLI, or an assistant through the MCP server.
By default
There's no setting to find and no box to check during setup. If the site is live, it's already served over HTTPS, on day one and on day one thousand.
A visitor who types the address without the "s", or clicks an old link that dropped it, is sent to the encrypted version automatically — no dead end, no warning page.
Add a custom domain later and its certificate is issued the same way — automatically, and usually within minutes of the DNS resolving.
Search engines and browsers both check for the padlock before they trust a page.
Search ranking has treated HTTPS as a signal for years now, and modern browsers go further — Chrome, Safari and Firefox all flag a plain HTTP page as "Not secure" right in the address bar, which is exactly the kind of warning that makes a visitor leave before they've read a word. None of that makes SSL a checklist item to remember; it's the reason it was never built here as optional in the first place.
Worth understanding
None of this needs your attention, but it helps to know what's actually going on when a site here is "secure."
Deploy a site — by Git, a zip upload, the CLI, or an assistant through the MCP server — and a certificate is requested and installed before the first visitor arrives.
A certificate has a shelf life. Ours are replaced automatically well before that date, so there's nothing to calendar and no reminder email that requires you to click anything.
If your HTML links an image, font or script with http:// instead of https://, some browsers will block that one asset or flag the whole page anyway, even though the page itself is fully encrypted. Write asset links as https:// or as a path starting with /, and this never comes up.
Selling certificates as an add-on means building a checkout step, a renewal-reminder system, and a support queue for the people who missed that reminder — all to sell something that costs us nothing extra to automate. It's simpler, and cheaper for you, to just include it.
Quick answers
No — it's included on every site at every price point on the price list, not sold as an upgrade or an add-on.
Yes. Add a custom domain and its certificate is issued the same automatic way as the free subdomain's, usually within minutes of the domain resolving.
It doesn't — renewal happens automatically well before that could ever occur, and there's no manual step you could forget.
Usually a mixed-content issue — an image, font or script on the page is still linked with http://. Switch that one reference to https:// and the warning clears.
No extra step during a Git deploy or any other method — SSL just comes along, on static hosting or a custom domain alike.