Private sites and client previews, enforced at the server
Plenty of sites are meant for a client, a department or a few named people rather than the open web. On VibeDeploy each site carries an access setting that the server applies before a single file leaves it: one shared password, team sign-in, personal email invitations or a network allowlist, on the platform address and your own domain alike, from infrastructure in Belgium.
Six access settings per site
One setting is active per site at any moment, and you can change it whenever you like:
Everyone
Open to the whole web and visible to search engines; this is how every site starts.
With a password
A single shared password guards every page; once entered, it unlocks that browser for a day.
Only me, My team
Viewing requires a VibeDeploy sign-in by someone on your team, which on a solo account means only you.
Invite only
Listed email addresses each receive their own access link; anyone not on the list is turned away.
Specific networks
Access is limited to the IP addresses and ranges you enter, typically an office or a VPN.
All five protected settings, the password included, come with Maker (€15 a month) and every plan above it. Plan details
Protecting a static site or one HTML file
Publish the files first, by upload, through your assistant or from GitHub. In the site's settings, pick With a password, enter it and save. From that moment the server vets each request, and markup, images and scripts are released only after a correct password; there is no client-side overlay to bypass from the page source. Protection applies to the whole site, so a single page that needs its own password belongs on a site of its own.
Sharing privately with a client
A shared password is quickest when a single contact reviews. Where several people review, or a password should not travel by email, Invite only (Maker and above) is cleaner: list their addresses, and each person receives a personal access link. Taking someone off the list ends their access.
Preview links for clients
A preview link is just the site's address, either the platform subdomain or the client's own domain once it points here (confirm the unlock works on that domain before sending it). Keep the site gated for the review and open it to Everyone on launch day without changing the address. When a live site gets a redesign, put the new version on a separate, protected site and deploy it to production once approved. Studios handling whole client rosters this way will find more on the agency page.
The same rules on a custom domain
Access follows the site, not the address it answers on. The identical password, invitation or network rule applies on your own domain and on the platform subdomain; add the domain in the site settings and the certificate issues automatically while the rules stay in force. Confirm that visitors can get past the gate at your domain before any review link points there.
Internal tools for a team
A surprising share of internal tooling is static at heart: the team handbook, an onboarding guide, a reference of exported figures, a members page for a club. Set such a site to My team and every colleague who signs in can read it while it stays invisible to the public web; Invite only extends that to named people outside the team.
Network allowlists
From Maker upward, Specific networks admits only the IP addresses and ranges on your list, which makes it the setting for an intranet page opened at the office or through a VPN. Organisations on Business can also fence off the dashboard: a second allowlist decides from which networks anyone may sign in to manage sites; the Business page lists the full governance set.
Netlify and Vercel, for comparison
Fair is fair: both are excellent developer platforms. According to Netlify's documentation, a site-wide password comes only with Pro and Enterprise, never with Free or Personal, while Vercel charges $20 a month for each protected project on Pro, includes it with Enterprise and leaves Hobby without it. Here, Maker at €15 a month carries the password together with the sign-in, invitation and network settings. The detailed match-ups are in VibeDeploy vs Netlify and VibeDeploy vs Vercel.
Frequently asked questions
Does the server enforce the password?
It does. Before any file leaves the server, the request is checked against the site's access setting, so markup, images and scripts stay locked until the correct password arrives. No script inside the page performs the check, which means there is nothing to disable or read around.
Which subscription covers these settings?
Passwords, sign-in, invitations and network allowlists all come with Maker (€15 a month, 3 sites) and every plan above it. New accounts open with a 14-day trial that asks for no card.
Can a client review without sharing a password?
Yes, through Invite only, available from Maker. Put the client's address on the list and a personal access link reaches them by email; taking the address off the list ends that access. People who are not listed cannot obtain a link.
Can the staging copy have a password of its own?
Not at present. Staging, part of Studio and Business, puts a copy of the site on a second address where changes are checked before promotion, and that address has no separate password. Client previews therefore belong in a site of their own, protected with its own setting.
Do the settings apply on a custom domain?
They are enforced there too. Access belongs to the site, not to the address it is reached on, so the same rule holds on your own domain and on the platform subdomain, and adding a domain with its automatic certificate leaves the protection in place. Before reviewers are sent to your domain, confirm that unlocking works at that address.
Is a shared password suitable for sensitive material?
It decides who may view a site and is enforced server-side, which suits previews, internal pages and anything simply kept off the public web. For regulated or genuinely sensitive material, prefer Invite only or My team so each viewer is identified, and apply your own judgment about what belongs on a website at all.
What about a site that runs a container app?
Passwords, sign-ins and invitations are enforced by the web server in front of the static files, and a public container service would bypass that gate. While one of those three modes is on, the container is therefore withdrawn from the public address, and it stays off until the site leaves those modes. Specific networks is the setting that works together with container apps.
Put your next site behind a gate
Deploy a site, choose its access setting, add your domain. Infrastructure in Belgium, 14-day trial, no card required.