Skip to content

docs: release URLs inherit the deployment's access gate #43

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
acoshift merged 1 commit into from
Jun 22, 2026
Merged

docs: release URLs inherit the deployment's access gate #43

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions content/deployments/static-sites.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -153,9 +153,13 @@ A static deployment is reachable at **two** hostnames:
or to compare two builds side by side.

Both are returned by `deployment.get` (`url` and `releaseUrl`) and shown on the
console's deployment **Details** page. Both are public and content-addressed — a
release URL can only ever serve its own build's files — so treat them as
shareable-but-unlisted, the same as the default URL.
console's deployment **Details** page. A release URL carries the **same access
posture as the default URL**: for a public site it's public (and
content-addressed — it can only ever serve its own build's files — so treat it
as shareable-but-unlisted); for a site with
[access control](/deployments/access/) ("Require Google login") the release URL
is gated by the same login, so a private site is **never** exposed through its
per-release URLs.

{{< callout type="note" >}}
**Release URLs are immutable but not eternal.** A release URL stays live only
Expand Down