VibeHost

Share with clients

Private app + time-bound share link. No sign-up, no friction, automatic revocation.

The pattern: you want non-technical reviewers (clients, prospects, journalists, internal stakeholders outside your VibeHost workspace) to see an app, but you don't want to create accounts for them or leave the URL accessible forever.

Solution: private app + share link with --expires.

The recipe

# 1. Lock the app down
vibehost app visibility client-pitch private

# 2. Mint a time-bound share link
vibehost app share-link create --app client-pitch \
  --label "Acme review — Q2 2026" \
  --expires 14d

Output:

{
  "ok": true,
  "data": {
    "id": "shr_abc123",
    "url": "https://client-pitch-yourws.vibehost.space/_share/vhs_xyzabc",
    "label": "Acme review — Q2 2026",
    "expiresAt": "2026-06-06T08:00:00Z"
  }
}

Send data.url to the reviewer. First click sets a cookie; the cookie satisfies the gate for that browser. After 14 days the link returns 410 and the cookie stops working.

Why this beats password-protection

Password gateShare link
Friction for the reviewerType password (must be communicated separately)One click
Per-recipient controlAll reviewers share one passwordOne link per recipient
Per-recipient revokeRe-set password, re-send to everyone except the one you're cuttingRevoke their link only
Audit trailSingle password eventPer-link timestamp, label, revoke record
Time-boundManual password clear--expires auto-revokes

Use password gates for broad soft-launches (shared password in the announcement). Use share links for per-recipient previews.

# Three reviewers, three separate links
for LABEL in "Acme review" "BetaCorp review" "Gamma Inc review"; do
  vibehost app share-link create \
    --app client-pitch \
    --label "$LABEL" \
    --expires 14d \
    --json | jq -r '.data | "\(.label): \(.url)"'
done

Output:

Acme review: https://client-pitch-yourws.vibehost.space/_share/vhs_abc...
BetaCorp review: https://client-pitch-yourws.vibehost.space/_share/vhs_def...
Gamma Inc review: https://client-pitch-yourws.vibehost.space/_share/vhs_ghi...

Email each link to the right recipient. If Acme forwards their link to someone else, revoke Acme's link only — BetaCorp and Gamma keep working.

vibehost app share-link revoke vhs_abc --app client-pitch   # prefix match works

End-of-project cleanup

# After the project ends, revoke everything in one shot
vibehost app share-link ls --app client-pitch --json | \
  jq -r '.data[] | select(.revokedAt == null) | .id' | \
  xargs -I{} vibehost app share-link revoke {} --app client-pitch --force

Or just delete the app:

vibehost app delete client-pitch --force

Variations

For internal reviewers who are in your VibeHost workspace, you don't need share links at all:

vibehost app visibility internal-review workspace

Every workspace member can view. No invite, no link, no gate.

When you want an audit trail of "who opened this when" (vs. anonymous "anyone with link"):

vibehost app visibility client-pitch private
vibehost app grants add-email sarah@acme.com viewer --app client-pitch
vibehost app grants add-email tom@acme.com viewer --app client-pitch

Reviewers click the regular URL, get bounced to Google sign-in, then in. Each visit logs actor=sarah@acme.com in the audit log.

Trade-off: requires the reviewer to have a Google account (or to sign up with email). Higher friction; better accountability.

Launching publicly but with a soft password gate (anyone can find the URL, but only people with the password can view):

vibehost app visibility soft-launch public
vibehost app password set "shipmate-2026" --app soft-launch

Share URL + password in your launch email / Twitter / Discord.

When you're ready to remove the gate:

vibehost app password clear --app soft-launch

Public, no password, no auth.

Combining gates

Every active gate AND-composes — they stack, not replace. You can combine:

  • visibility: private + share link → reviewer with link gets in (anonymous)
  • visibility: private + email grant → reviewer with Google sign-in gets in (audited)
  • visibility: public + password → anyone who knows the password gets in
  • visibility: public + password + share link → either correct password OR valid share link

The model is additive. Disabling a gate doesn't bypass the others. See grants and visibility for the full matrix.

Common questions

Can the reviewer leave comments on the page?

Not built-in. Send the link with a "comment via email" instruction, or embed a third-party tool (PageProof, MarkUp.io, Pastel) in your app.

What if the reviewer needs the link after expiry?

Mint a new one with a new --label "Extension". The new link works; the old one stays expired.

Can I see if/when the reviewer opened the link?

Not at share-link granularity — share links are anonymous by design. Use email grants instead if you need per-visit audit.

Are share links searchable?

Not really — they're long random tokens. Practical secrecy = "as secret as the email/Slack channel you sent it in." Don't post share links publicly.

See also

On this page