Claude Artifacts alternative: Homespun vs Artifacts

Which of the two you are actually looking for

Searches for an artifacts alternative come from about six places, and four of them have a better answer than switching. Find your row before you read anything else.

If you landed in one of the first four rows, the honest advice is to close this tab and carry on. There is a whole section below on why, and it is the longest one here. If you landed in the last two, the rest of this page is the comparison you came for.

What a published artifact is, in Anthropic's own words

The whole comparison falls out of one sentence in Anthropic's developer documentation, and it is worth reading before any table.

An artifact is a capture of work, not an application.

Share session output as artifacts, Claude Code documentation

That is a design statement, not an apology, and the documented page constraints follow from it directly.

An artifact is a static page. It can't store data submitted through a form or authenticate viewers itself.

Share session output as artifacts, Claude Code documentation

The CSP blocks scripts, stylesheets, fonts, and images loaded from any other host, along with fetch, XHR, and WebSocket calls.

Share session output as artifacts, Claude Code documentation

• One page, no routes. Relative links do not resolve, because nothing is deployed alongside the page.
• Storage exists, on paid plans, with conditions. Persistent storage for artifacts is available on Pro, Max, Team, and Enterprise plans on Claude web and desktop. It is capped at a 20 MB storage limit per artifact, takes text only with no images, files, or binary data, and answers nothing until the artifact is published. The full picture is in what Claude Artifacts can and cannot store.
• No identity. The page cannot authenticate a visitor, so it cannot know which of them is which.

One part of that has changed, and it cuts against the simple version of this story, so it belongs here rather than buried:

Connector calls are the exception: the page hands them to claude.ai, which makes the network call itself.

Share session output as artifacts, Claude Code documentation

An artifact can call MCP connectors when someone views it, so a page really can show live data instead of a snapshot from the session that built it. Two properties decide what that is good for.

calls go through the viewing account's connected tools, so two people opening the same dashboard can see different data depending on what their accounts can access

Share session output as artifacts, Claude Code documentation

An artifact that calls connectors can't be shared to a public link on any plan.

Share session output as artifacts, Claude Code documentation

So a connector-backed artifact is an excellent personal dashboard over data the viewer already has access to, and it is still not a shared application: the data belongs to whoever is looking, and the page cannot be public on any plan. Anyone telling you an artifact can never reach outside data is a version behind, and anyone telling you connectors close the gap has not read the second half.

Homespun and Claude Artifacts side by side

Homespun is where the same agent that built the thing can host it. People sign in with their email, so the app can tell who is who and every row remembers who created it; permissions are set per collection, so some people can approve and others can only submit; and the agent keeps read and write access to the collections it is allowed, so it can keep working on the data instead of handing you a page and walking away. It is free today, and there is no paid plan to buy.

The comparison, with the rows where an artifact wins left in.

The last two rows are a pair, and they are not in our favour. Free is only an advantage while the thing running your data is still there, and an artifact is running on infrastructure somebody is paid to keep up.

The limits, with the actual numbers

Adjectives are useless in a comparison table, so these are the documented figures on both sides rather than "generous" and "flexible".

Two of those rows deserve more than a cell. The 20 MB figure is far more generous than it sounds for text records and completely useless the moment somebody wants to attach a photo of a receipt, which is the practical shape of that ceiling: it is rarely the size that stops people, it is the type. And the last row is not a win so much as a difference in kind, because filters over a collection are a long way short of SQL. If what you actually want is a real database, the honest answer is an MCP server onto one you already own, which is covered in full on the connecting Claude to a database page.

Identity, which is the whole of the difference

Every other row in every table above is downstream of one thing: an artifact has no way to know who is looking at it, and a hosted app does. It is worth being concrete about what that buys, because "user accounts" sounds like paperwork until you need one of these.

The two artifact storage pools are the closest thing available and neither one closes this gap: Personal storage: Each user maintains their own private data, so nobody can see anybody else's, while Shared storage: All users see and interact with the same data, so everybody can see everybody's. What almost every real request needs is the middle, one dataset where the app knows which person is looking, and that middle does not exist. The long version is in whether other people can use your Claude Artifact.

Sharing: who can open it, and what it costs them

This is the axis where an artifact wins outright, and it is worth quoting rather than conceding vaguely.

share a link that anyone on the internet can open, with no claude.ai sign-in required

Share session output as artifacts, Claude Code documentation

View and interact with any published artifact without signing up. Try all basic functionality without a Claude account.

Publish and share artifacts, Claude Help Center

Worth being precise about that third row, because it is the one place the two products nearly meet. A Homespun app set to link or public can let signed-out visitors in, and each one gets a stable identity tied to their browser rather than to an account, which is enough to give a visitor their own rows in a shared collection. It is not enough to know that the person is Priya, and it does not survive a different device. So it narrows the gap for a one-off public form and does not close it for anything that has to recognise a person.

Two things about the last row trip people up in opposite directions. The help centre states the restriction flatly:

Artifacts created on Team or Enterprise accounts can only be shared within your organization

Publish and share artifacts, Claude Help Center

while the developer documentation describes the switch that lifts it:

On Team and Enterprise plans, public sharing is off until an Owner enables it for the organization.

Share session output as artifacts, Claude Code documentation

Both are current. The practical reading is that on a work account you cannot assume you can publish to the open web, and whether you can is your administrator's decision rather than a setting on the artifact. On a personal Pro or Max account it is simply yours. More on the mechanics in how to share a Claude Artifact with other people.

What happens when you want to take it down

This is the axis people do not think about until it is too late to think about it, and it is the sharpest single difference on the page.

Unpublishing also permanently deletes all associated storage data (both personal and shared) if the artifact used persistent storage.

Publish and share artifacts, Claude Help Center

Once you unpublish an artifact, you cannot publish that same artifact again.

Publish and share artifacts, Claude Help Center

Two of those rows are ours to own. There is no export button on a Homespun app: getting your data out means reading the collections through the API, the CLI or an agent, which is a complete export but not a packaged one. And there is no rollback, only redeploying forward. What sits in its place is a compatibility check that refuses a redeploy which would strand rows you already have, so the usual reason to want a rollback does not arise, but if you wanted one it is not there.

Read fairly, the artifact behaviour has a real virtue that we do not match: when you unpublish, the data is actually gone, with no forgotten copy on a host you stopped paying attention to. If you are taking something down because it should never have been up, that is exactly the tool you want. It is only the wrong property for the thing fifteen people use every week. The detail, including how to export before you press it, is in what happens when you unpublish a Claude Artifact.

What the agent can do once the thing exists

This is the difference nobody puts in a feature table and it changes what the tool is for. When Claude finishes an artifact, the conversation is where the relationship ends: the page holds data the model cannot see, and the only way to bring any of it back is to paste it.

That last row matters more than the ones above it. An agent with unconditional access to everything an app holds is a liability rather than a feature, so what a Homespun agent may read and write is declared in the app's manifest per collection, and a collection that is not named is not reachable. Related reading on the general problem: how to connect Claude to a database, which covers the third option, an MCP server onto a database you already own.

When to keep using Artifacts and ignore this page

This is the section a comparison page normally leaves out, which is why it is the longest one here. There is a large class of things where an artifact is not a compromise you make until you can afford a real app. It is the better product, and moving to a hosted app would make the result worse.

• Anything short lived. Something you need for a weekend, a workshop, one sprint, one meeting. There is nothing to provision, nothing to bill, nothing to remember to shut down, and nobody to tell when you are finished with it.
• Anything where the state belongs to one person. A calculator that remembers your inputs, a practice drill, a reading tracker, a form that survives a refresh. Personal storage is exactly this shape and it costs nothing to set up.
• Anything genuinely public. A vote tally, a guestbook, an idea board, a collaborative list. If it would be fine written on a whiteboard in a corridor, an anonymous shared pool is fine, and the anonymity is a feature rather than a gap.
• Anything whose job is to be looked at. A chart, a report, an annotated diff, four layout options side by side. Anthropic's framing is right: it is a capture of work, and this is the work.
• Anything for people you cannot ask to sign up. Customers, a mailing list, a conference room, a forum thread. Asking two hundred strangers to sign in to use a calculator is a mistake, and it is a mistake we would be selling you.
• Anything that should read your own connected tools. A connector-backed artifact pulls live data through the viewer's own connections, which is something a hosted app with its own database simply does not do.

And one advantage that sits above all of those, because it is structural rather than situational: an artifact is the only option in this comparison that can be produced entirely inside a conversation, in seconds, with no deploy step at all. You ask, it exists, you look at it, you ask for a change, it changes. Nothing is provisioned. No second product is involved. No account is created anywhere. That loop is genuinely faster than ours and it will stay faster, because we have a deploy in the middle of ours and they do not.

The rule of thumb that survives all of this: an artifact is superb at a thing to look at or try, and unable to be a thing a group uses together. If what you have is the first, you are already done.

Moving an artifact to a real app, without losing the data

If you have decided to move, the order matters, because the two rules that govern artifact storage work against a careless migration: writes only answer on a published artifact, and unpublishing destroys everything.

Persistent storage is only available for published artifacts. During development and testing, storage operations will not succeed until the artifact is published.

Persistent storage for artifacts, Claude Help Center

• Do it while the artifact is still published. An export control added and tested in the preview pane reads back nothing and will convince you the data is already gone. It is not. It is unreachable until you publish.
• Ask Claude to add an export control. In the same conversation, ask for a button that reads every key out of both personal and shared storage and dumps the result as JSON into a textarea on the page.
• Republish, then open the published link. Not the preview. Click the button and copy the JSON out.
• Accept that personal storage is only yours. Each viewer's personal pool is private to them, so your export sees the whole shared pool and your own personal rows and nothing else. Other people's private data cannot be exported by you, and unpublishing destroys it.
• Keep the source. The artifact's code is in the conversation. Rebuilding from the code is far better than rebuilding from a description.
• Rebuild it, then load the data. Give the agent the artifact code and the exported JSON and ask for the same app with real accounts. The collections it needs are created as part of the deploy.
• Only then decide about unpublishing. There is no rush and no undo, and leaving the old artifact published costs you nothing.

What the two halves look like on the other side, so you know what you are rebuilding into:

The practical step is connecting the agent you already use, which takes a couple of minutes and no install: see how to connect Homespun to your AI chat.

What this page is not claiming

We host apps that agents build, so we have an obvious interest in the moment somebody outgrows an artifact. Here is what that interest would tempt us to leave out.

• Signing in is a real cost. Every person who opens a Homespun app has to have an email address and click a link the first time. For ten colleagues that is nothing. For an audience it is a tax, and it is a tax an artifact does not charge.
• There is a deploy step. It is one call the agent makes and you do not have to do anything, and it is still a step an artifact does not have.
• We are free today with no paid plan, which is not the same as safe. A product with no revenue is a product that has not yet proved it can pay for itself. That is a fair thing to weigh against a feature that ships inside a plan you already buy.
• There are no push notifications. Not to a phone, not to a browser. An app can be set up to email its owner and members when a row changes, but nothing pushes, and none of the built-in templates emails anybody until you ask for it.
• There is no export button. Your data is readable in full, at any time, through the API, the command line or your agent. It is not a file you can download in one click, and calling that an export is a stretch.
• There is no rollback. Every deploy is a numbered version and the history is kept, but nothing puts an older one back. You fix things by deploying forward.
• It is not a database you can point anything at. There is no SQL, no connection string, and no third-party tool that can read it. Queries are filters over one collection at a time. If what you want is a real database, an MCP server onto Postgres is the better answer and we say so on the connecting Claude to a database page.
• An artifact does one thing we do not. It reads the viewer's own connected tools live. If that is the requirement, an artifact wins and there is no version of this where it does not.

If any of the Anthropic facts on this page no longer match the help centre, the help centre is right and we would rather fix the page than keep the advantage. Every quote above is linked to the page it came from so you can check it in about a minute.

Questions people ask next

Primary sources

Every claim about Claude on this page comes from Anthropic's own documentation, quoted rather than summarised so you can check it yourself.

• Share session output as artifacts, Claude Code documentation
• Persistent storage for artifacts, Claude Help Center
• Publish and share artifacts, Claude Help Center