11/10/2026 · HTTPS, Security, Domain

What is HTTPS, why your site needs it, and how BrewInTH sets it up

Cover in Thai and English: "What is HTTPS and why your site needs it", with a padlock icon and a shield icon, and the BrewInTH wizard

What HTTPS and the padlock mean, why every site needs them, how BrewInTH issues certificates for free addresses and your own domain, and four padlock pitfalls.

Have you ever seen your browser write "Not secure" next to a web address? Visitors who see it hesitate to type their phone number, log in or pay, and many simply leave — even when nothing is wrong with the site except that it has no HTTPS.

This article explains, without assuming you are a programmer, what HTTPS is, why every site needs it, what BrewInTH does for you automatically, and the four things in a site's own code that can still make the padlock disappear — with a prompt that has your AI check all four.

In short
🔒 HTTPS encrypts what travels between a visitor and your site; the browser shows it as a padlock
🔒 Every BrewInTH project gets https://your-name.host.brewinth.net with a certificate from the moment it is created — nothing to buy or install
🔒 Anyone who types http:// is sent to https:// automatically
🔒 Your own domain gets HTTPS for free too, issued after its DNS check passes
🔒 A missing padlock is usually the site's own code — an http:// image or a wrong APP_URL — and AI can fix it

What is HTTPS?

When someone opens your site, the data passes through many hands on the way: the café Wi-Fi, the mobile network, internet providers. With plain HTTP it travels as readable text, so anyone in between can read or change it.

HTTPS is HTTP with encryption. The conversation between the browser and your site becomes unreadable to anyone in the middle, and the browser can also check that it is talking to the real site and not an impostor. What makes that check possible is a certificate, issued by an authority the browser trusts.

When everything is right, the browser shows a padlock (or a settings icon) beside the address. When it isn't, it shows "Not secure" or a full red warning page.

Why every site needs HTTPS

Trust. "Not secure" stops people from filling in forms, logging in and paying.
Passwords and personal data. Login forms, phone numbers and delivery addresses must always be encrypted in transit.
Browser features. Camera, location, notifications and installing a site as an app are only available to HTTPS sites.
Other services. LINE webhooks and most payment providers only send data to HTTPS addresses.
Search. Google uses HTTPS as one of its ranking signals.

In practice, a site without HTTPS is hardly usable today, even if it only shows information.

What BrewInTH does for you

What happens when someone opens a site on BrewInTH: 1 the visitor types http or https, 2 the platform sends http to https automatically, 3 the browser checks the certificate and shows the padlock, 4 the platform decrypts and passes the request to the app, saying it came over https, 5 the platform tells the browser to always use https for this site

1. Free addresses have HTTPS from day one

Every project gets its own address, https://your-name.host.brewinth.net. The certificate covers every name under that domain (a wildcard), so it works the moment the project is created, with no wait for a new certificate per site. Before your first release the address shows a "not published yet" page — already over HTTPS.

2. http is sent to https for you

If someone types http:// or clicks an old http link, the platform sends them to the same address over https:// with a permanent (301) redirect. You don't write any redirect rules yourself.

3. Browsers are told to always use HTTPS

Your app's responses on BrewInTH carry a Strict-Transport-Security (HSTS) header valid for one year. A browser that has visited once goes straight to https from then on, even if the user types http.

4. Decrypted for your app, with a note that it came over https

Encryption ends at the BrewInTH platform, which passes the request to your app over the project's private network with an X-Forwarded-Proto: https header. Your app never handles certificates — but it does need to read that header correctly (see the pitfalls below). For PHP sites the platform sets HTTPS=on itself when the request came over https.

5. Certificates renew themselves

The certificates the platform issues (through Let's Encrypt) renew automatically. There are no expiry dates to remember and no files to upload.

Does my own domain get HTTPS?

Yes, for free. When you connect your own domain such as www.myshop.com (on a package that includes custom domains), you add the domain, create two DNS records and press Verify DNS. Once that passes, the status shows Issuing TLS while the platform requests a certificate for that name, then turns Ready.

Your own domain and HTTPS: add the domain, create a TXT and an A record, press Verify DNS; the status goes from Awaiting DNS to Issuing TLS to Ready, then press Use as the main link; on Cloudflare set the A record to DNS only

Two things worth knowing:

The Use as the main link button only appears once the domain is active and its HTTPS is ready, so customers are never sent to an address without a padlock. Meanwhile your host.brewinth.net address keeps working.
If your DNS is on Cloudflare, set the A record to DNS only (grey cloud).

The full steps with the DNS values are in the custom domain article linked at the end.

Four things that remove the padlock (and how AI fixes them)

BrewInTH takes care of the certificate, but if the site's own code still talks about http://, the browser can still complain. These are the usual causes:

Four things that remove the padlock: images or scripts still loaded over http, called mixed content; APP_URL still http or localhost, which breaks links and redirects; an app that ignores X-Forwarded-Proto and redirects in a loop; a login cookie without the Secure flag

Images, scripts or fonts still on http:// (mixed content). The page is https but loads some files over http, so the browser blocks them or drops the padlock. Common with sites moved from an old host, or code where AI wrote full image addresses.
APP_URL (or whatever your app calls its own address) is still http:// or localhost. Links in emails, password-reset links and post-login redirects go to the wrong place. Set it to the site's https address in App settings, then release again.
An endless redirect loop. Some apps have a rule "if not https, redirect to https" but don't trust X-Forwarded-Proto, so every request looks like http and the redirect never ends. Have the app trust one proxy hop — Express app.set('trust proxy', 1), Django SECURE_PROXY_SSL_HEADER, Laravel trusted proxies — or simply remove the redirect rule, since the platform already does it.
A login cookie without Secure. Users get logged out often, or the session cookie is sent insecurely. Once the app trusts the proxy correctly, most frameworks set Secure on their own.

A prompt to check all four

This site runs on BrewInTH at https://your-name.host.brewinth.net.
BrewInTH already provides HTTPS and forwards requests to the app through one
proxy hop with X-Forwarded-Proto: https. Please check and fix:
1. Every http:// in the HTML, CSS, JS and in data stored in the database —
   change it to https:// or a relative path (/images/a.png).
2. Set the site's own address (e.g. APP_URL) to the https address above
   through the project's secrets, not in code.
3. Make the app trust one proxy hop, and remove any http → https redirect
   rule in the code if it causes a loop.
4. Mark the session cookie Secure and HttpOnly.
Release again, then use site_check on the home page and the login page to
confirm there is no redirect loop.

No coding agent? Open the site in Chrome, press F12 and look at the Console tab. "Mixed Content" warnings name every file still loaded over http; copy them into your AI chat and ask for a fix.

FAQ

Do I need to buy an SSL certificate?

No. The free host.brewinth.net address, short addresses you buy and your own connected domains all get certificates from the platform at no extra cost.

Can I upload my own certificate?

Not at the moment. The platform issues and renews certificates for every domain automatically.

Why does my new domain still say "Issuing TLS"?

The platform is requesting its certificate, which usually takes a few minutes. If it takes unusually long, check that the A record points to the IP shown on the domain card and, on Cloudflare, that it is DNS only. Your site's existing address keeps working meanwhile.

Does HTTPS mean my site is 100% secure?

No. HTTPS protects data in transit and proves the site is genuine, but it does not fix holes in the site's code, such as forms that don't validate input or passwords stored in plain text. Read the security checklist for AI-built sites as well.

Does my app need to listen on port 443?

No. Your app listens on the port the platform gives it through PORT as usual; encryption and port 443 are the platform's job.

Summary

HTTPS is what makes visitors trust your site. On BrewInTH the certificate, the http → https redirect, telling browsers to always use https and renewing certificates are all handled by the platform — for free addresses and your own domains alike. What's left is your site's own code, and your AI can check the four points above in a single pass.

Start your first project for free →