Share a Claude artifact, then deploy it with SpringRoll when your team relies on it

Open the artifact and choose Share. Depending on your plan you can share it with anyone who has the link, invite people by email, or share it inside your Team or Enterprise organization. On Team and Enterprise plans, artifacts stay inside the organization unless an Owner has turned on external sharing.

Artifacts made in Claude Code work the same way. Each one starts private to you at a claude.ai URL, and you share it from the Share control in the page header.

This summarizes Anthropic's sharing documentation as reviewed on 6 November 2026. Plans change, so check the current article before relying on an option.

Scroll sideways to see all columns. With the table focused, use the arrow keys.

• Anthropic: share artifacts →
• Claude Code artifacts documentation →

Anthropic's Claude Code documentation describes an artifact as one self-contained page without a backend, and suggests deploying a hosted internal tool that needs one on your own infrastructure. That is fine for a chart, a review page or a calculator. It becomes a problem when the page turns into a tool people use every day:

• It is a single page, so there are no routes, API endpoints or scheduled jobs.
• It cannot authenticate viewers itself; access is whatever claude.ai sharing allows.
• Network calls are limited to the page's own origin and Google Fonts, so company data arrives only through each viewer's own connectors.
• It belongs to the author's account. There is no release history, named owner or support contact for colleagues.
• Some artifacts keep shared storage everyone can see, which is not a database with per-user permissions.

If two or more of these are true, the artifact has become a team tool and needs what SpringRoll records for every app: an owner, an audience, releases and an audit trail.

• Several people create or change records that everyone else sees.
• It needs company data that viewers' personal connectors cannot or should not reach.
• Different colleagues need different permissions, enforced on a server.
• It needs more than one page, a background job, or an API another system calls.
• The team needs a named owner and support contact after the original author moves on.
• IT has to approve who can open it and which data it reads.

Treat the artifact as a working prototype. Copy or download its HTML or React code into a new folder, open Claude Code there and connect SpringRoll once.

Ask Claude to build a small project around the artifact's code, replace embedded sample data with a real source, and move anything sensitive to the server. Run the production build locally. Then ask Claude to deploy: SpringRoll checks runtime fit, places the app on managed Vercel or Cloudflare, records the release and follows the build to READY. Claude can also attach the conversation that produced the app to its SpringRoll record with springroll.app.record_prompts, so the next maintainer sees how it was built.

Finally, choose who can open it in the app's Access controls and test the link with one colleague in the audience and one outside it. The app then appears in their App Portal.

# in the folder with the artifact's code
claude mcp add --transport http springroll https://springroll.dev/api/mcp

# start Claude Code, run /mcp to sign in, then ask:
# "Prepare this project for SpringRoll. Read the Company Blueprint, inspect my source and discover supported workloads and services. Check the build, workspace, owner and deployment workflow; show the exact deployment proposal for confirmation, then follow the build to its actual result."

• Connect SpringRoll to Claude Code step by step →
• Choose the audience and test the link →
• Check runtime fit →

Keep using artifacts for what they do well. Move a tool to SpringRoll when the right-hand column describes what your team needs.

Scroll sideways to see all columns. With the table focused, use the arrow keys.

• Check the app before you share it →