Set it up once, then ask Claude to publish.

Choose your setup

Two ways to connect, and the difference that matters is where the connector runs. Both of these run on your own machine, so Claude can publish a file or folder you point it at.

Claude Desktop

1. Download rtfx.dxt.
2. Open the file. Claude Desktop installs the rtfx connector — there is no claude_desktop_config.json to edit.
3. Leave rtfx endpoint as https://rtfx.pro, and leave Expose access-management tool off unless you want Claude changing who can open an artifact.
4. Sign in once. A browser sign-in on this machine is enough — the credential is stored in your home directory and shared with the Claude Code plugin below, so /rtfx:login there also connects Claude Desktop. If you never use a terminal, paste a scoped token from dashboard → Integrations into the extension's API token field instead.
5. Ask Claude to publish. doctor reports which credential it found if anything looks wrong.

Claude Code, in the terminal

Two commands to install, one browser sign-in to connect. Nothing to clone and no package to install — the plugin brings its own dependency-free publisher.

/plugin marketplace add yogevgab/artifacts-server
/plugin install rtfx@rtfx

/rtfx:login       # browser OAuth sign-in; stores a local renewing credential
/rtfx:setup       # confirm your credential reaches your instance
/rtfx:publish     # publish what the session just built
/rtfx:versions    # history · /rtfx:rollback to go back

What to ask Claude

Once either one is connected, publishing is a sentence rather than a command:

• “Publish this page as a private link.”
• “Publish the folder ./out to rtfx as client-demo.”
• “Publish this PDF to rtfx and give me the link.”
• “Publish the updated version to the same link.”
• “Roll client-demo back to version 2.”

Every link starts restricted to you. Deciding who else may open it is a deliberate step you take yourself — see Access & privacy.

What rtfx.pro is

An artifact is one publishable thing: a single HTML page, a PDF, or a folder/zip with its own assets. Publishing gives it a slug, a version and an owner. From then on the artifact has a stable link, a history, and an access list — the three things an unlisted URL on a static host never gives you.

• Private by default. A new artifact is restricted to its owner until they share it.
• Owned. The person who published it manages it; nobody else can, however they were shared with.
• Versioned. Re-publishing creates the next version at the same address.
• Observable. The owner sees every view — person, time, country, version — and is emailed the first time each named recipient opens it.
• Shareable beyond your account list. A link that expires when you say and revokes the moment you want it to, for a recipient who will never sign in.

Who uses it, and for what

Made for the work that comes out of an AI session: a finished page, a dashboard, a prototype, a report — something real, that needs a link today and shouldn't be on the open web.

Publishing

Three ways in, one behaviour. A file, a directory or a zip all work; a bundle keeps its relative paths, so ./assets/app.js resolves the way it did locally.

From the terminal

The CLI ships in the project repository — there is no npm package yet, so you run it from a checkout (or from the Claude Code plugin below, which needs no checkout at all).

$ git clone https://github.com/yogevgab/artifacts-server
$ cd artifacts-server && npm install

$ export ARTIFACTS_URL=https://rtfx.pro
$ export RTFX_API_TOKEN=rtfx_…    # dashboard → Integrations

$ node cli/artifacts.mjs publish ./index.html --slug q3-report --title "Q3 Report"
$ node cli/artifacts.mjs publish ./site --slug q3-report --note "revised charts"   # next version
$ node cli/artifacts.mjs grant q3-report alex@example.com
$ node cli/artifacts.mjs views q3-report
$ node cli/artifacts.mjs list

From the dashboard

Drop a file or zip into the publish panel under Artifacts, set a title, and it's live at its slug. Each artifact then has its own page, holding version history, sharing and the view log.

Over HTTP

The upload field decides how the file is read, not its extension: a zip goes in bundle, a single HTML or PDF document in file. A bundle needs index.html at its root.

$ export RTFX_API_TOKEN=rtfx_…              # dashboard → Integrations

# a zip — zip the folder first over HTTP → bundle
$ curl -X POST https://rtfx.pro/api/machine/artifacts \
    -H "Authorization: Bearer $RTFX_API_TOKEN" \
    -F slug=q3-report -F title="Q3 Report" -F bundle=@./dist.zip

# one HTML document or PDF → file
$ curl -X POST https://rtfx.pro/api/machine/artifacts     -H "Authorization: Bearer ***"     -F slug=q3-report -F title="Q3 Report" -F file=@./index.html

# PDF works through the same file= field
$ curl -X POST https://rtfx.pro/api/machine/artifacts     -H "Authorization: Bearer ***"     -F slug=board-pack -F title="Board Pack" -F file=@./board-pack.pdf

One credential. /api/machine is the machine surface: it authenticates the bearer token and nothing else, so the API token you minted in the dashboard is all a script, an agent or a CI job needs. It carries the same rules as the rest of the product — your scopes, your artifacts — and it deliberately does not answer for user management or token issuance, which need a real sign-in. The browser dashboard keeps using /api, where a session identifies you instead.

Self-hosting? An instance that gates every path at the edge with Cloudflare Access can pass a service token through as well, by adding CF-Access-Client-Id and CF-Access-Client-Secret headers; the CLI and the MCP server send them automatically when CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET are set. They get a request past Access and grant nothing inside the app. On rtfx.pro they are not needed.

Connectors: Claude Code, MCP & Hermes

Four ways to connect an agent, and they are not interchangeable: the local surfaces can publish by reading paths beside the client, while the hosted MCP surface publishes only content sent inside the tool call. This is the whole table before the detail:

Agents publish through exactly the same CLI and API a human uses — there is no separate, weaker agent path. The plugin's browser sign-in is the short path; for CI, mint an API token in the dashboard with the read and publish scopes and hand it to the session:

# in a Claude Code session, with the plugin installed
/rtfx:publish ./out client-demo

# or from any shell — Claude Code, Hermes, CI — in a checkout of the project
$ node cli/artifacts.mjs publish ./out --slug client-demo --title "Checkout prototype"

Sharing is deliberately not part of the agent surface: grant needs the manage scope and lives with the rest of access control under Access & privacy. An agent publishes; a person decides who may read.

The Claude Code plugin

The two install commands are in Choose your setup. The plugin ships a skill, seven slash commands and a dependency-free publisher, so after /rtfx:login publish this is an ordinary sentence: the session picks the build output, versions it under a slug and hands back the link.

The plugin's browser login stores a local credential with owner-only permissions and prints only a token id, never the token. For CI and advanced scripts, a scoped RTFX_API_TOKEN from Integrations still works and takes priority over the browser sign-in.

The Claude Desktop extension and local MCP server

For Claude Desktop, the easiest local install is rtfx.dxt: open the Desktop Extension package and Claude Desktop registers the rtfx MCP server for you. The same plugin also ships the native MCP server directly, for manual setup or any other client that speaks MCP. This local server publishes, lists versions and rolls back as tool calls, holding the same scoped token and applying the same credential filters as the CLI. Because it runs on your machine, it can publish local paths and folders. To wire it up by hand instead, point a client at the server file inside the installed plugin (or inside a checkout) — it needs Node and nothing else:

{ "mcpServers": { "rtfx": {
    "command": "node",
    "args": ["/path/to/plugins/rtfx/scripts/rtfx-mcp.mjs"],
    "env": { "RTFX_API_TOKEN": "rtfx_…" } } } }

tools: publish · list_artifacts · get_versions · rollback · doctor

Remote MCP, authorized in the browser

rtfx.pro also runs a hosted MCP endpoint at https://mcp.rtfx.pro/mcp. A compliant client discovers the authorization server from the endpoint's own challenge and takes you through an ordinary browser sign-in and consent screen — authorization code with PKCE, refresh and revocation, and no bearer token to paste anywhere:

$ claude mcp add --transport http rtfx https://mcp.rtfx.pro/mcp
$ claude mcp login rtfx

tools: publish · list_artifacts · artifact_details · artifact_statistics · share_artifact · rollback_artifact · delete_artifact · doctor

It publishes content; it does not read paths. The hosted endpoint exposes publish for bytes sent inside the MCP call — an HTML page as text, a PDF as base64, or a small explicit file list — plus read tools for listing/details/statistics and manage-scoped tools for sharing, rollback and deletion. It deliberately refuses path, folder and similar arguments: a server-side endpoint asked for a path could only ever read the server's disk, not the client's. Large build outputs and local directories still belong to the plugin and the local MCP server.

Access & privacy model

There are two normal identity layers, plus a separate share-link path for recipients who will not sign in.

1. Who may sign in at all. rtfx.pro owns the identity layer. Signup and sign-in are passwordless — a one-time code or magic link by email — and every new workspace starts on the Free plan.
2. Who may open a given artifact. Either restricted (the owner plus the people they name) or everyone signed in. Sharing one artifact never widens who can sign in, and never exposes anything else you own.

An unauthorized request and a request for something that doesn't exist get the identical 404, so a link can't be used to confirm that a page exists. Artifact content is served from a dedicated origin that hosts files only — never the dashboard or the API — so uploaded HTML can't reach the app it was published from.

Share links, for recipients with no account

Naming a person is the default and the stronger option: they sign in as themselves, the view log names them, and revoking them is one action. But some recipients will never have an account — a client's legal team, a reviewer you met once — and for those there is a share link: a capability URL that opens exactly one artifact for whoever holds it, with no sign-in.

• It expires, if you want it to. Never, in 7 days, in 30 days, or any number of days up to 365. Expiry is enforced when the link is redeemed, not by a cleanup job.
• It revokes immediately. One action in the share panel, and the next request with that link — including one already inside the artifact — gets the same 404 as a stranger.
• Only a hash of it is stored. The URL is shown once, when it is created, and cannot be redisplayed. A database dump does not contain a working link.
• It is scoped to one artifact. Holding a link for one thing never opens another, and it grants no management rights.
• It carries no password. The URL is the whole credential — that is what makes expiry and revocation the controls that matter, and why a link you can't take back would be the wrong design.

The trade is attribution. A share-link visitor holds no identity, so their view is not attributed to anybody in the view log — the link records when it was last used, and that is all. If you need to know exactly who read something, grant access by email instead.

Worth being precise about what the content origin does and doesn't do: it separates published content from rtfx.pro, and all artifacts share it. It is not a per-artifact browser sandbox, so two pages published by people who don't trust each other are kept apart by the access list — who may open what — rather than by the browser's origin boundary. Publish only what you're willing to run in the same origin as your other artifacts.

None of it is crawlable: artifacts, the dashboard and the API are excluded in robots.txt, marked noindex, and served with an X-Robots-Tag: noindex header. The only indexable pages are this one, the landing page, the sign-in page and the two legal pages.

What rtfx.pro itself stores about you — and the fact that it runs no analytics, advertising or third-party tracking — is set out in the privacy policy. What you agree to by publishing here is in the terms of use.

Versions & view logs

Every publish to a slug creates the next immutable version. The public link always points at the current one; each older version keeps its own preview URL for whoever manages the artifact, and rollback is a single action. Nothing is overwritten, so a bad revision is a click to undo rather than a re-run of whatever produced it.

The view log answers the question client work always ends with: who opened it, when, from where, and which version they saw. Views are recorded for signed-in people opening a page — not for asset requests or machine tokens.

The artifact's page in the dashboard reads that log three ways, because "has the client seen it?" and "can I safely roll back?" are different questions: Views is the raw event list, Viewers is one row per person with how often they came back and which version they last saw, and Views by version shows which versions people are still opening.

Read receipts. You do not have to go and look. The first time each person you granted access to opens an artifact, rtfx.pro emails you — once per person, never for your own views, and never for a share-link visitor, who has no identity to name. It is on by default; switching it off for one artifact is an API call today (PUT /api/artifacts/:slug/receipts) rather than a control in the dashboard.

Why rtfx.pro

Several tools now host the page an AI session just produced, and they mostly agree on the basics. So the useful question is not "does it host HTML" — it is what happens on the second day, when the link is out, the client asks who has seen it, and a revision lands badly. Here is the split, written so you can decide in one screen.

Table stakes

Present here, and expected of anything in this category. Nobody should pick a tool for these.

• Publishing with no build step. A single HTML file, a PDF, a folder or a zip goes up as it is; relative paths keep working.
• A stable link. One slug, one URL, for as long as the artifact exists.
• Re-publishing to the same address. The link you already sent keeps working after an update.
• A dashboard. Drag-and-drop publishing, an inventory, and the state of each artifact in one place.
• Some idea of who looked. Counts at minimum.

What actually makes it different

These are the reasons to choose rtfx.pro over a general "share your AI output" tool.

• Agent-native publishing, not an upload form with an API bolted on. Claude Code, a native MCP server, a Hermes run, the CLI and the HTTP API all take the same path a human takes — there is no separate, weaker agent route. Connecting Claude Code is a browser sign-in rather than a token you copy between two windows, and what it leaves behind is still a scoped, owner-bound, revocable credential: an agent can publish as you and can never become you.
• Identity-first access, with bounded share links for exceptions. Every artifact is restricted until you name someone, or create a share link for somebody who will not sign in. Unauthorized and non-existent requests return the identical 404, so a random link can't even confirm the page is real. Named sharing is revocable per artifact and never widens who can sign in.
• Immutable versions with one-click rollback. Every publish is a new version with its own preview URL. Nothing you have already shared is overwritten, so a bad revision is an undo rather than a re-run of whatever produced it.
• A view log that names a person and a version. Not a hit counter: who opened it, when, from which country, and which version they saw — the question every client project ends with. And you are emailed the first time each named recipient opens it, so the answer arrives without you asking for it.
• Share links that expire and revoke, for people with no account. When the recipient will never sign in, a capability URL opens exactly one artifact — with an expiry you choose (never, 7 days, 30 days, up to 365) and immediate revocation. Only a hash of it is stored, so it cannot be redisplayed or dumped. It is deliberately not a password: the URL is the whole credential, which is exactly why being able to expire and revoke it is the control that matters.
• Workspace governance. Artifacts belong to a workspace, not to one shared login. Members carry a role — owner, admin, member or viewer — and instance privilege is re-derived from configuration on every request, so no database write can escalate anyone.
• A branded address for the workspace, on a URL you can read out loud. A paid workspace can claim an address — yogev, maya, your company — and every artifact in it answers at rtfx.pro/yogev/q3-board-report and rtfx.pro/maya/client-proposal as well as at its original URL. Both keep working, forever: the branded link is a second way in, never a move. It is a path on rtfx.pro, not a custom domain of your own — those are still not built, and are listed below.
• Uploaded HTML runs somewhere it can't reach us. Artifact files are served from a dedicated content origin that hosts files and nothing else — no dashboard, no API, no admin — so a page you publish can never touch the app that published it. Artifacts share that one content origin, so it isolates published content from rtfx.pro rather than artifacts from each other.
• Nothing watches the visitor. No analytics, advertising or third-party tracking anywhere on this site, and none injected into what you publish. The view log is ours to show you, not a product we resell.

Not here yet

Listed so you know they are deliberate gaps rather than things you failed to find. If a project needs one of these today, this is the honest place to find that out.

• Per-link secrets. Not built A shared password on the link itself, separate from the recipient's email identity. What exists instead is an identity-backed access list, and a share link you can give an expiry date and revoke at any moment — see Access & privacy. Neither of those is a password, and this page will not call them one.
• Custom domains. Not built Serving artifacts from your own hostname — docs.yourcompany.com. What is built is the branded workspace address above, which is a path on rtfx.pro; the two are not the same thing and this page will not blur them. Content already runs on its own origin, which is the hard part.
• Editing a published page in place. Not built Fixing a number or a sentence from the dashboard without going back to the session that made it. Today a change is a re-publish, which is a new version at the same link — cheap when Claude is still open, and a detour when it isn't.
• Approvals, polls and review workflows. Not built rtfx.pro can show view evidence and access requests, but it is not a review workflow system around the artifact — there are no comments or annotations on a page you published.

Why not a generic static host?

You could put this on any bucket or edge host. Here's what you'd then have to build yourself.

API

Authenticate with Authorization: Bearer <token> and nothing else. Every endpoint is scoped to what the token's owner may see; an admin sees everything they administer. See Publishing for a runnable call.

• GET /api/machine/artifacts — list artifacts you can manage.
• POST /api/machine/artifacts — publish (multipart: title, slug, and either file for one .html document or bundle for a .zip).
• GET /api/machine/artifacts/:slug/versions — version history.
• POST /api/machine/artifacts/:slug/current — make an earlier version live again (JSON: {"version": 1}).
• GET /api/machine/artifacts/:slug/views — the view log.
• PUT /api/machine/artifacts/:slug/access — set visibility and the share list (JSON: visibility, emails).
• DELETE /api/machine/artifacts/:slug — delete an artifact and its versions.

The dashboard share panel uses the same authenticated API surface with the same scope rules as the rest of artifact management: GET /api/artifacts/:slug/links lists links for callers with read, POST /api/artifacts/:slug/links and DELETE /api/artifacts/:slug/links/:id create and revoke links for callers with manage ({"expires_in_days": 30}, 1–365, omit for a link that never expires — the URL comes back once and is never stored), and GET/PUT /api/artifacts/:slug/receipts reads and sets the read-receipt switch for one artifact.

read covers the listings, publish covers publishing and rollback, manage covers sharing and deletion — a token holds only the scopes you gave it. Managing people or minting tokens is not on this surface at all: those need a signed-in session, so a leaked token can never widen its own reach.

The artifacts themselves live behind sign-in; these paths are documented here but the data is not public. Full request/response detail ships with the CLI (node cli/artifacts.mjs --help in a checkout) and in the dashboard once you have access.

Frequently asked