Deploy an app from Claude Code in one session: connect Fine Structure over MCP or the open source plugin, then ship hosting, a database, auth and a domain.
Builders who work in Claude Code and want the project they just built to be live, with hosting, data and auth handled.
- A working deploy path from Claude Code to a live URL in one session
- A clear picture of what the platform hosts for you: pages, database, auth, domains
- An honest test for when a static host is the better fit
To deploy an app from Claude Code you connect Claude to a runtime that can host it. With Fine Structure there are two ways in: add https://finestructure.ai/api/mcp as a custom connector in claude.ai settings and approve OAuth, or install the open source plugin with /plugin marketplace add finestructure-ai/claude-plugin then /plugin install finestructure@finestructure. Claude then generates a complete app with create_app or ports your existing project into the platform runtime file by file, and the result runs as hosted React pages with a managed database, auth, a custom domain and saved-version rollback. The free tier needs no card: generation spends credits, while edits, publishing and domains are free.
Claude Code is very good at producing an application and completely unable to run one. A session ends with a folder on disk: React components, a data model that took shape while you talked, an auth flow that assumes a server exists. Deploying is where that folder gets a URL, a database, and a login that works for other people.
The usual answer is plumbing: push to a repository, wire up CI, provision a database elsewhere, add an auth service, point DNS, wait for certificates. Every piece is reasonable and the sum is an afternoon. The other answer is to give Claude Code direct access to a runtime that already has those pieces, so deploying is one tool call in the same conversation.
The honest framing: Our platform is not a deploy button bolted onto your existing stack. It is a runtime, and the app moves into it. That is a real trade: you get hosting, the database, auth and domains without assembling them, and you give up control over the server layer.
Two paths, same destination: the same account and the same apps. Pick the connector if most of your work happens in claude.ai. Pick the plugin if you live in the terminal and want deploy commands next to your code.
Path 1: the MCP connector: Open settings in claude.ai, choose Add custom connector, paste https://finestructure.ai/api/mcp as the URL, and approve the OAuth prompt. One click, no API key, no environment variable living in a dotfile. Claude then sees roughly 70 tools: app creation, file writes, entities, publishing, domains and analytics.
Path 2: the open source Claude Code plugin: Run /plugin marketplace add finestructure-ai/claude-plugin, then /plugin install finestructure@finestructure. That adds /deploy, /fs-status and /fs-domain to your session. The source is public, so you can read what it sends before you install it rather than trusting a description.
About directory listings: Our directory submissions are in review. Until that finishes we will not call the connector or the plugin official, verified or listed. Install them because the URL is public and the source is readable, not because of a badge.
There are two deploy modes. One starts from a sentence: create_app takes a prompt and produces a complete application with pages, entity schemas, auth wiring and a working URL. This is the fast path when the idea is still soft and the quickest way to understand it is to look at it. Generation spends credits, and it is the one metered part of the flow.
The second mode ports a project you already have. Claude reads your files and rewrites them into the platform runtime one at a time: pages become platform pages, the data model becomes entities, auth calls become platform auth. It is a port, not a blind upload. Any file that assumed a server you controlled gets rewritten against the runtime, which is where Claude Code earns its place.
What a realistic first session looks like: Ask Claude to create the app, open the preview, then keep editing files in the same conversation until the pages match what you meant. File edits and publishing do not spend credits, so the loop after generation is free. When it looks right, publish, attach a domain, and let TLS resolve itself.
Static hosts are very good at what they do. If your output is a frontend bundle and nothing else, they will serve it faster, cheaper and with a larger ecosystem than we will. The comparison gets interesting once the app needs state, users, and a way back.
What the app needs | Fine Structure | Static deploy target
Hosting | Hosted React pages from the platform runtime | Best raw frontend speed, widest ecosystem
Database | Managed entities, ready before the first deploy | Bring your own, provisioned separately
Auth | Built in, with sessions and per app users | Bring your own auth service or provider
Domains | Custom domain with automatic TLS | Custom domain with automatic TLS, mature flow
Rollback | Restore a saved version of the app | Redeploy an earlier build or revert the commit
Agents | AI agents that keep working on a schedule | Not included, run them somewhere else
When we are the wrong choice: Three cases where something else is the better tool, and we will say so. A custom server runtime that has to be yours, such as a Go binary or a Python worker with specific system libraries. A monorepo with its own backend you will not rewrite. Pure static hosting at scale, where a CDN with no database wins.
Deploy is not the end of the work. It is where the app starts producing facts instead of opinions. Four things become available, and none of them require leaving the conversation.
The agents are the part that surprises people. An agent here is not a chat widget stuck on a page. It is a worker attached to the app that keeps running on a schedule after you close the laptop, reads the app's own data, and can message its verified owner on WhatsApp or by email. The app tells you something happened instead of waiting to be checked.
Everything after generation stays in the same Claude session: change a file, publish, check the domain, read the analytics, adjust an agent. The free tier does not ask for a card, so the honest way to evaluate this is to point Claude at one small real app and see how far it gets.
Not on its own. Claude Code writes and edits files and needs a target that can host them. Add our MCP connector or install the plugin and deploying becomes a tool call: create the app, write files, publish, attach a domain.
https://finestructure.ai/api/mcp. In claude.ai, open settings, choose Add custom connector, paste that URL and approve the OAuth prompt. No API key to copy, and Claude then sees roughly 70 tools.
Run /plugin marketplace add finestructure-ai/claude-plugin, then /plugin install finestructure@finestructure. You get /deploy, /fs-status and /fs-domain. The plugin is open source, and our directory submissions are in review, so we do not claim official status.
There is a free tier and it does not ask for a card. Generating an app spends credits. File edits, publishing and custom domains do not.
Yes. Claude ports it into the platform runtime file by file: pages become platform pages, the data model becomes entities, auth calls are rewritten. It is a port, not an upload, so expect files to change shape.
Yes. Add a custom domain and TLS is issued automatically. Use /fs-domain from the terminal, or ask Claude over the MCP connector.
Restore a saved version. Rollback returns the app to an earlier saved state, which is usually faster than diagnosing a change in production and gives you a working baseline.
When you need a custom server runtime that has to be yours, such as a Go binary or a Python worker with specific system libraries. When a monorepo keeps its own backend. Or when you want pure static hosting at scale, where a CDN with no database wins.