SSL
Every site is encrypted from the minute it goes live — your own domain and the free address alike, issued and renewed for you. You never buy a certificate, and you never get the email saying one expired.
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 site built here, that certificate covers your free you.lemonhosted.com address automatically, and it covers a domain of your own 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 simply how every site here is served, from the very first publish, whether you pressed the button in the editor or came in through Git, a drag-and-drop upload, the CLI, or an assistant on 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."
Publish a site — from the editor, by Git, a drag-and-drop 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 in the editor, during a Git push, or any other route — the padlock just comes along, on your free address or a domain of your own alike.