Password-protect a static site without .htaccess

The classic way to password-protect a site is a pair of .htaccess and .htpasswd files on an Apache server. It works, but it needs exactly what a static site doesn’t have: your own server, access to its configuration and the know-how to set it up.

If your site lives on a static host, the lock comes from the platform itself.

What’s wrong with .htaccess on static hosting

.htaccess is an Apache configuration file. On static hosting there is no Apache of yours: files are served by the platform’s shared infrastructure, and nobody will let you drop your own config into it. An .htaccess uploaded to the site root just sits there as dead weight, and is sometimes even served to visitors as a regular file.

The second issue people remember too late: HTTP basic authentication shows the browser’s built-in dialog. It looks the same everywhere, it can’t explain where the visitor has landed, there is no way to log out of it, and on a phone it looks alarming. Half of your clients will decide the site has been hacked.

How it works on Tuqo

The lock is turned on in the Visibility tab on the site page and covers every file, not just HTML. This matters: if pages are protected but images aren’t, a direct link to a photo opens for anyone, and those files are usually the reason for the lock in the first place.

Visitors don’t see a browser dialog but your login screen: the logo, title and description you set. They enter the password once and then browse freely: instead of checking the password again, a service cookie scoped strictly to your host does the job, for up to 7 days on that device.

Three more things .htaccess doesn’t give you out of the box:

• Access period. Access until a date or for 1, 3, 7 or 30 days, with a countdown on the login screen. If access is granted for more than two days, you get a reminder a day before it ends; short “for tonight” access doesn’t need one.
• Open limit. After N devices the link stops letting new people in. Handy when access goes to one person rather than a group chat.
• Stats. Sign-ins, login screen views, wrong attempts, last sign-in.

What about search engines

A gated site doesn’t show up in search: it serves crawlers its own robots.txt that blocks crawling, and the login screen itself is marked noindex and returns a 401 status. So neither the content nor the password prompt gets indexed.

How secure is it

The password is checked against an argon2 hash, which can’t be reversed into the password. The check runs once; after that, a signed cookie works strictly on your host. Brute force hits a limit: five wrong attempts from one IP address on one site within 15 minutes, and the form shuts off.

Next to the hash sits a second, encrypted copy of the password, for one reason only: to show it to you in the panel. It’s a deliberate trade-off. You set the site password yourself and send it to clients yourself, and regenerating it because of a lost note means sending access to everyone again. The encryption key is held by the panel but not by the serving layer, so the internet-facing service can’t decrypt passwords.

When a password isn’t enough

A shared password works while there are few recipients and you talk to them directly. When there are dozens and they change, the second mode is more convenient: email code sign-in. The visitor enters their address, gets a six-digit code by email and signs in. Only addresses on your list get in, and the log shows who signed in and when. Remove an address and one person loses access; nobody else notices.

The password is included from the Start plan (or as a 199 ₽/month add-on for one site on the Free plan); the email code from Pro (or as a 299 ₽/month add-on). Approximate dollar and euro prices are on the pricing page.

More: site password, gated access overview and access by email list.