Protect your site with a password
Not everything on your site is meant for the public. A work-in-progress redesign, a private staging environment, a pitch deck for a specific client, an internal tool for your team — all of these are valid reasons to lock your Flexweg site behind a login and password.
When protection is enabled, anyone visiting your URL is prompted for credentials before seeing any page. Only people you've shared the login and password with get through.
When to use it
- Sites in construction — you're still designing, and you don't want visitors (or search engines) stumbling on the half-finished version.
- Staging / preview — share a link with a client or a teammate before going public, without exposing the site to the world.
- Private content — a portfolio you only want to show during interviews, a memo for a small group, a product spec for early testers.
- Internal tools — a dashboard, a link directory, a wiki that only your team should see.
- Soft launches — announce a URL privately, then lift the lock on launch day without changing a single file.
How to enable it
All the configuration happens in your Flexweg account — no code, no file change, no redeploy.
- Open Account → My sites.
- Find the card of the site you want to protect.
- Check the Password protection option.
- Choose a username and a password that you'll share with the people allowed to access the site.
- Click Apply.
That's it. Within a few minutes, visiting your site prompts for credentials before any page loads.
Once you apply the restriction, it can take a few minutes to become effective in production — the change has to propagate across Flexweg's infrastructure. Test after a short wait and you should see the login prompt.
Turning protection on and off
You can toggle the protection at any time from the same screen:
- Disable it when you're ready to go public — uncheck the box and click Apply. Your site becomes accessible to everyone again, no credentials needed. Same few-minute propagation delay.
- Re-enable it later if you need to lock it down again. Your previously configured username and password are kept ready.
- Change the credentials by updating the username and/or password, then clicking Apply. The old credentials stop working immediately; share the new ones with your authorized visitors.
What visitors see
Visitors who don't have the credentials see a native browser authentication prompt — the same standard dialog used across the web for protected resources. They type the username and password, hit OK, and the site loads normally.
Browsers typically remember the credentials for the rest of the session, so your authorized visitors only type them once per browser tab.
Password protection prevents unauthorized visitors from loading your site. The files themselves are not encrypted — anyone with the username and password has full read access to everything served from the site. Don't use password protection for content that requires stronger confidentiality (financial records, personal data, etc.).
Tips
- Pick a strong password — especially for sites that handle sensitive internal info. The login prompt offers no rate limiting that you configure; a weak password can be brute-forced.
- Rotate credentials when people leave — if you shared the password with a contractor or a former teammate, change it when they no longer need access.
- Don't mix public and private content — password protection is site-wide. Either the whole site requires a login, or none of it does. If you need only part of your site to be private, move that part to a separate Flexweg site.
- Search engines are blocked automatically — crawlers don't guess passwords, so a protected site won't get indexed while the lock is on. You don't need to add
robots.txtornoindextags during a construction phase. - Share credentials through a secure channel — don't email passwords in plain text. Use a password manager, a Signal message, or any channel you already trust for secrets.
Related
- Publish your first page — set up your site before deciding what to protect.
- Deploy from Git — password protection is independent from your CI/CD; your GitHub Actions workflow keeps deploying normally while the site is locked.