every.link is in private beta. Request access

Documentation

Publish with every.link

Connect web AI over MCP, equip coding agents with the official skill and CLI, or publish a manual one-off.

The URL model

Every account owns one content host. Sites use short account-level paths:account.every.link/site. Workspaces still organize publishers, permissions, and sites, but remain internal and do not appear in public URLs.

acme.every.link/spring-campaign
acme.every.link/spring-campaign/about.html
acme.every.link/spring-campaign/docs/getting-started.html
ye.every.link/college-dropout

Site slugs are unique within an account. The first site keeps the requested slug. Only when another workspace requests that same slug does every.link append a short random suffix, such as college-dropout-1f09j.

Connect a web-based AI tool — recommended

In an MCP-capable AI tool, add the every.link remote MCP server:

https://app.every.link/mcp

The tool opens every.link for sign-in. Authorize it as yourself, select the account it may access, and approve its requested permissions. Do not paste or share an API token. The resulting connection belongs to your member identity, can be revoked from Connections, and records both you and the connected app in the audit trail.

The MCP server lets an agent find workspaces and sites, create a site, publish Markdown, HTML, or a small folder, inspect deploy history, and roll back. Mutating tools require an idempotency key, so a network retry cannot silently create a duplicate site or deploy.

Publish from a coding agent

Give your coding agent the officialskills/deploy-every-link/SKILL.md workflow, then tell it which workspace and site to use. The skill inspects the publish set, excludes unsafe files, calls the CLI once, and returns the server-issued URL and deploy ID.

Use it for static artifacts only. Server processes, private keys, environment files, and untrusted build steps do not belong in an every.link deploy.

Publish directly from the CLI

Prefer to drive it yourself? The official CLI accepts a single HTML or Markdown file, a ZIP archive, or a directory. A directory is packaged locally before upload.

every-link login
every-link whoami
every-link deploy ./dist \
  --workspace marketing \
  --project spring-campaign

Always select the workspace explicitly. It is the internal deployment target even though it is omitted from the public URL. A successful command returns the account, workspace, and site URL.

CLI credentials are personal to the member who signs in. Admins should use a named service token only for CI or genuinely shared automation—not as a token that several people copy between agent tools.

Deploys are immutable. Publishing creates a new deploy and moves the site pointer to it; rollback moves that pointer to a previous deploy without rewriting history.

Publish manually

For a one-off, use Manual publish in the dashboard. Paste or drop one HTML or Markdown file, upload a ZIP, or drop multiple files or a folder. The dashboard packages multiple files in your browser before uploading them.

Manual publishes use the same immutable deploy history and access rules as the MCP, agent-skill, and CLI workflows. Hidden files, hidden folders, andnode_modules are skipped when the dashboard packages a folder.

Site data and uploads

Pro sites can use JSON collections configured in the dashboard. On a normal account host, the collection endpoint sits beneath the site:

GET    /spring-campaign/_data/leads
POST   /spring-campaign/_data/leads
GET    /spring-campaign/_data/leads/:id
PATCH  /spring-campaign/_data/leads/:id
DELETE /spring-campaign/_data/leads/:id

Reads return { "data": [...], "meta": { "limit": 50 } }. Writes accept a data object, validate it against the dashboard schema, and must originate from the same site. Runtime uploads usePOST /spring-campaign/_upload.

Choose who can view

  • Public: anyone with the URL.
  • Password: one shared site password.
  • Signed in: an authenticated viewer account.
  • Email domain: viewers whose verified email matches an allowlist.
  • SAML: organization identity and group rules on Business.

Viewer access is checked per request. Viewers do not become dashboard members and do not consume publisher seats.