Here Now

here.now

Skill version: 1.31.0

here.now lets agents publish websites and files to live URLs in seconds.

The core primitive is a Site: publish a file or folder and get a live URL at {slug}.here.now or a custom domain. Every Site has access control: public link (default), password, or restricted invite-only access.

here.now also includes workspaces — shared team accounts where Sites belong to the team and serve at {label}.{workspace}.here.now (see "Publish to a workspace" below).

A personal account on a paid plan can turn on a vanity URL: the user's name at {name}.here.now, and from then on every Site they publish (including through you) also serves at a readable {site-name}.{name}.here.now address, named from its title. When a user wants every Site under their own name, PUT /api/v1/vanity-urls/subdomain with {"subdomain": "name"} turns it on; for one Site at one hostname they choose, use a custom domain; for Sites owned by a team, use a workspace. Finalize responses carry primaryUrl and urls[] (best first); mention primaryUrl when it differs from siteUrl. See https://here.now/docs#vanity-urls.

To install or update (recommended): npx skills add heredotnow/skill --skill here-now -g

For repo-pinned/project-local installs, run the same command without -g.

Current docs

Before answering questions about here.now capabilities, features, or workflows, read the current docs:

→ https://here.now/docs

Read the docs:

• at the first here.now-related interaction in a conversation
• any time the user asks how to do something
• any time the user asks what is possible, supported, or recommended
• before telling the user a feature is unsupported

Topics that require current docs (do not rely on local skill text alone):

• Site access control (passwords and restricted access)
• workspaces (team accounts, membership, label URLs)
• Drives and Drive sharing
• custom domains
• vanity URLs ({site-name}.{name}.here.now; see https://here.now/docs#vanity-urls)
• buying a domain (search and quote first; state the price and the renewal price and get the user's explicit yes before calling purchase — purchases are final; see https://here.now/docs#buy-domain)
• Site Data
• public profiles
• proxy routes and service variables
• limits and quotas
• SPA routing
• owner Site search
• Site analytics
• Site version history, previews, and rollback
• error handling and remediation
• feature availability

If docs and live API behavior disagree, trust the live API behavior.

Command-line fetches of https://here.now/docs (curl, WebFetch, etc.) receive a markdown summary, not the full HTML docs: it lists every stable public endpoint with a one-line description, but section anchors in this skill (like /docs#access-control) resolve only in the HTML version, and worked examples live there too. For complete request/response schemas and parameters, fetch https://here.now/openapi.json. Do not conclude an operation is unsupported from the markdown summary alone — check the OpenAPI spec first.

If the docs fetch fails or times out, continue with the local skill and live API/script output. Prefer live API behavior for active operations.

Requirements

• Required binaries: curl, file, jq
• Required network access: https://here.now (API) and https://*.r2.cloudflarestorage.com (file uploads PUT directly to storage; the exact host is in each upload URL). In a sandbox or behind a proxy with an egress allowlist, allow BOTH hosts. With only here.now allowed, the create call succeeds, every upload fails, and finalize reports missing files.
• Optional environment variable: $HERENOW_API_KEY
• Optional Drive token variable: $HERENOW_DRIVE_TOKEN
• Optional credentials file: ~/.herenow/credentials
• Bundled helpers:
• ./scripts/publish.sh for publishing sites
• ./scripts/drive.sh for private Drive storage

If the helper scripts aren't installed

Some environments receive this document without the bundled scripts/ directory (for example, hosted platform integrations that provide only $HERENOW_API_KEY). In that case, either install the full bundle first:

npx skills add heredotnow/skill --skill here-now -g

or call the API directly — every script workflow in this document is a wrapper over the public API. Publishing is a three-step flow: POST /api/v1/publish with a files array ([{path, size}]) returns presigned upload targets, PUT each file's bytes to its returned URL, then POST the returned finalizeUrl. The site is not live until finalize succeeds. Full walkthrough with request/response examples: https://here.now/docs#create (then #upload and #finalize), machine-readable schemas: https://here.now/openapi.json.

Create a site

./scripts/publish.sh {file-or-dir}

Outputs the live URL (e.g. https://bright-canvas-a7k2.here.now/).

Under the hood this is a three-step flow: create/update -> upload files -> finalize. A site is not live until finalize succeeds.

Without an API key this creates an anonymous site that expires in 24 hours. With a saved API key, the site is permanent.

File structure: For HTML sites, place index.html at the root of the directory you publish, not inside a subdirectory. The directory's contents become the site root. For example, publish my-site/ where my-site/index.html exists — don't publish a parent folder that contains my-site/.

You can also publish raw files without any HTML. Single files get a rich auto-viewer (images, PDF, video, audio). Multiple files get an auto-generated directory listing with folder navigation and an image gallery.

Update an existing site

./scripts/publish.sh {file-or-dir} --slug {slug}

The script auto-loads the claimToken from .herenow/state.json when updating anonymous sites. Pass --claim-token {token} to override.

Authenticated updates require a saved API key.

Stale-base protection. The live Site may have changed since your local files were published — the owner can edit it from other tools (another agent, the here.now Editor, a teammate). The script records the live versionId in .herenow/state.json after each publish and sends it as baseVersionId on the next update of the same slug from the same directory; if the live Site moved past it, the update is rejected with code: "version_conflict" naming the live version and what created it. When that happens, relay the message to the user and offer to (a) read the live files with GET /api/v1/publish/{slug}/files (lists them with a url each) and GET /api/v1/publish/{slug}/files/{path} (the bytes; owner API key, works for password-protected and restricted Sites without the visitor password), reconcile them into the local files, and republish, or (b) re-run with --overwrite to replace the live version anyway. Before editing local files for an authenticated Site you haven't touched recently, check for drift first: GET /api/v1/publish/{slug} returns currentVersionId plus currentVersionSource and currentVersionCreatedAt (what changed it and when, e.g. editor) — if the id differs from your state file's versionId, read the live files before editing. The published version is the shared truth; never fetch the public URL to read an owned Site (it is gated for protected Sites) and never ask the user for a visitor password to read their own Site. Anonymous Sites can't call these endpoints; they rely on the saved state and server enforcement. Omitting baseVersionId (or using --overwrite) is an unchecked full replacement — today's default for raw API callers.