How to put a login in front of an HTML page

A lot of what a coding agent makes is not an app. It is one file: a quarterly report with charts, a dashboard of numbers that were true on Tuesday, a clickable prototype of a screen. You open it in your browser and it looks finished, because it is.

Then you need the finance team to see it, and only the finance team. The file holds revenue by region, or salaries, or a customer list, so "anyone with the link" is not an option.

This article is about putting a login in front of that file. We make Spryloom, and the last option below is it. The others are real choices, described as fairly as we can.

A password in the page is not a login

The first thing people try, or ask the agent to add, is a password check inside the page: a box that asks for a password, and some JavaScript that shows the content if it matches.

This protects nothing. The browser has already downloaded the whole file before the box appears, so the content is sitting there for anyone who presses "View source". It makes no difference whether the password is stored plainly or hashed, because the thing you are protecting is in the file next to it.

A real login has three properties, and they are worth checking any option against:

1. The check happens before the file is sent. Somebody who fails it receives nothing, not a page with a curtain over it.
2. People are identified by something they own, like their work email, not by a password you shared in Slack that can be forwarded.
3. You can take access away from one person without changing it for everyone else.

Option 1: send the file

Attach it to an email, or drop it in Slack. The six people open it on their own computers.

For a one-off, this is fine, and nothing is simpler. The limits show up on day two: each person has a copy you can't take back, you'll send a new copy for every change, and if it was forwarded you'll never know. There is no door at all, just a small audience.

Option 2: your host's own protection

If the file is already on a static host such as Netlify, Vercel or Cloudflare Pages, each has a protection feature of some kind. Read the fine print, because they differ. Some offer one shared password for the whole site, which fails the second property above: a password that's shared is a password that's forwarded. Others let in only members of your account on that host, which means a seat for every viewer. Most of these are on paid plans.

If your team already has accounts on the host, this can be a good answer.

Option 3: an access product in front

Cloudflare Access, and products like it, put a sign-in page in front of any site. Visitors enter their email, get a code, and are let in if their address is on your list. The file itself is untouched.

This passes all three properties, and it is free for small teams. What it needs is some setup: your domain on Cloudflare, the site hosted somewhere, and a policy written for who is allowed. For one file that can be a lot of configuration, but once it is done it covers every file you put behind it.

Option 4: publish the file as a page

This is what Spryloom's pages are for. The file is published as it is, behind a sign-in that happens before anything is served, and you invite people by email.

npm install -g spryloom
spry login --email you@yourcompany.com
spry publish q3-report.html

Publishing Q3 report

  ✓ Live in 3s
  ✓ a page: no server, no database

https://q3-report.yourcompany-com.spryloom.app

  version   1

Nothing is written next to your file, and nothing runs: the page is stored and served when somebody opens it. A new page opens only for you, which is the shut position.

To let the finance team in, say who the page is for when you publish it, then invite them:

spry publish q3-report.html --visibility invited

spry invite q3-report --email emily@yourcompany.com

Emily gets an email saying who invited her and what the page is. She clicks, receives a sign-in link of her own, and is in. There is no password for her to choose or for you to share. Anyone who isn't invited gets the sign-in page and then a refusal, and the file is never sent to them.

To update it, publish again; the address stays the same. To remove someone, remove their invitation.

If you built the file in Claude Code, you don't have to type any of this. With Spryloom connected, "publish this report for the finance team" does the same thing, including the invitations.

What it doesn't do

• A page can't save anything. Its scripts can talk only to the page itself. A report with a form that submits, or a prototype that keeps what you type, needs an app. Publishing the folder again with a package.json and a start script turns the page into one at the same address.
• Libraries come from a short list. A page may load scripts and styles from cdnjs, jsDelivr and unpkg, and fonts from Google Fonts. Anything else has to be saved into the folder.
• Everything in the file is visible to everyone you invite. It is a login, not a redaction. Don't put in the file what some of the viewers shouldn't see.

The three properties, side by side

	Send the file	Host's protection	Access product	Spryloom page
Checked before the file is sent	No check	Yes	Yes	Yes
People identified by their email	No	Depends on the host	Yes	Yes
Access taken away per person	Copies are out	Depends on the host	Yes	Yes
Setup for one file	None	Paid plan, host settings	Domain, host, policy	One command

Which one to pick

Whichever you pick, test the door the same way as for an app: open the address in a private browser window, where you're signed in to nothing. If the report appears, so will it for anyone who gets the link.