Deploy guide interest check: VibeHost (private-by-default static hosting)

[yvonneyang-dcard]

Hi! Following the third-party guide policy — which asks services that are new or not yet widely adopted to open a discussion rather than send a PR — I'd like to check whether there's interest in a deploy guide for VibeHost.

What it is: VibeHost is a managed hosting platform for static builds, driven from a CLI, from a coding agent over MCP, or from a browser extension.

Being upfront: we're about four months old and not widely adopted yet, so by the policy we're squarely in the "ask first" bucket. I work on VibeHost. I'm not opening a PR.

The one thing that might be relevant to Astro users: a deploy is private by default. The URL a deploy prints is not publicly readable — opening it requires signing in as the workspace owner or as someone explicitly granted access, and that is the default state, not something you configure. Making it public is an explicit second step (vibehost app visibility <app> public). Every other host in the deploy guides is public-by-default, so sharing a work-in-progress Astro build with a client or a reviewer normally means either publishing it or wiring up an auth layer. Here it's the out-of-the-box behaviour.

What I've verified, before asking:

npx astro build
# 2 page(s) built in 256ms

vibehost deploy ./dist --app astro-vibehost-verify
# Deploying from: /private/tmp/vh-astro-test/dist
#             as: astro-vibehost-verify (runtime=static, build=client)
# Deployed. https://astro-vibehost-verify-vibehostnow.vibehost.space
#   visibility: private — only you can see it right now.

with Astro 7.3.4 and VibeHost CLI 4.17.0. An anonymous request to the deployed URL returned 302 to the sign-in page; with access, / and /about/ returned 200 and served the built pages. The test deployment has since been deleted.

What I'm asking:

1. Would a minimal stub page under guides/deploy/ be welcome at this stage, or would you rather we host the guide in our own docs and propose a "Community Resources" link somewhere relevant until there's more adoption?
2. If it's the latter — what evidence of adoption would you want to see before a stub is worth your review time? Number of Astro projects deployed, community-authored posts, requests from Astro users in your issues, something else? I'd rather aim at the actual bar than guess at it.

Happy to wait, and thanks for writing the policy down clearly — it made this easy to get right.