The Nest · guides

How to share an app you built with Claude Code with your team

Max Parry · October 13, 2026 · 10 min read

The quickest way to share an app you built with Claude Code is to publish it to a host that handles sign-in for you, then send your team the link. If the app is for coworkers only, pick a host where you choose exactly who can open it (just you, named people, or your whole company) without writing login code. Sending the code, a screenshot, or a link to localhost:3000 doesn't count as sharing.

That's the short answer. The longer one depends on what you built and who needs it, so this guide walks through five real options, what each one costs, and the mistakes that turn a useful tool into a security problem.

#First, figure out what you actually built

Claude Code will happily build almost anything, but for sharing purposes your app is one of three kinds:

1. A page that only shows things. A calculator, a dashboard over a CSV, a style guide. Everything happens in the browser and nothing needs to be saved.
2. An app that saves things people add. An idea board, a PTO tracker, a request form, a checklist the whole team ticks off. It needs a database, and it needs to know who each person is.
3. An app that needs a server. It takes webhooks, calls an API with a secret key, runs on a schedule, or does work you don't want visible in the browser.

Most internal tools people build in an afternoon are the second kind. That matters, because the second kind is where "just deploy it" stops being simple: you now need sign-in, a database, rules for who can change what, and somewhere safe to keep keys.

#Option 1: Send the code

Push the project to GitHub and tell teammates to clone it and run it themselves.

This works when everyone you're sharing with is a developer and wants to change the code. It doesn't work for the sales team, the finance team, or your manager, who will never run npm install. It also means every person runs their own copy with their own data, so nothing is actually shared. Use it for collaborating on code, not for giving people a tool.

#Option 2: Share it as a Claude artifact

If what you built is a single-page app, Claude can share it as an artifact, and for some teams that's enough.

According to Anthropic's help article on sharing artifacts, on Team and Enterprise plans artifacts stay inside your organization by default, and you can share with specific people in it. Everyone who opens one needs a Claude account, and an owner controls whether anything can be shared outside the organization. When Anthropic launched apps that call Claude from inside an artifact, it noted that each viewer's usage counts against their own subscription, not yours.

Artifacts are a good fit when:

• the app is small and lives in one file,
• everyone who needs it already has a Claude seat in your organization,
• you don't need your own address, your own database rules, or a server.

They're a weaker fit when people outside your Claude workspace need access, when the app has grown into a real project folder in Claude Code, or when you need things like scheduled jobs, webhooks, or API keys kept on a server.

#Option 3: Deploy to a general web host and add login yourself

Vercel, Netlify, Cloudflare Pages and Railway can all put your project on the internet in a few minutes. Claude Code knows how to deploy to each of them. The catch is that a general host gives you a public website by default, and turning it into a company-only tool is your job.

Here's what that looks like on Vercel, the most common choice, using Vercel's own documentation:

• Vercel Authentication is free on every plan, but it only lets in people who are signed in to Vercel and are members of your Vercel team or project, or who you've approved one by one (Vercel Authentication docs). Pro includes free Viewer seats, so it works if every coworker creates a Vercel account and joins your team; for an HR or finance team, that's often a hard sell.
• Password Protection costs $20 a month per protected project on Pro and isn't available on Hobby (Deployment Protection pricing). A shared password is also not the same as knowing who each person is.
• Your own identity provider (Okta, Microsoft Entra ID and so on) in front of a deployment is Vercel Passport, which is an Enterprise feature. SAML SSO for your Vercel team itself is a $300 a month add-on on Pro, per Vercel's pricing page.
• The Hobby plan is for personal, non-commercial use, so an internal tool for your employer belongs on Pro.

The other route is to build sign-in into the app: add an auth provider such as Clerk or Auth0, add a hosted database such as Supabase or Neon, and write the access rules yourself. Claude Code can do all of that. You'll end up with three or four accounts, several API keys, and code that decides who can read which rows. That code is exactly where generated apps tend to go wrong (more on that below).

Pick this option when the app is customer-facing, when you need a framework feature like server-side rendering, or when you have engineers who will own it long term. We compare the two approaches in detail in Crow Nest vs Vercel for internal tools.

#Option 4: Put a sign-in gate in front of it

If your company already uses Cloudflare, Google Cloud or another network that offers an identity-aware proxy, you can host the app anywhere and put a sign-in gate in front of it. Cloudflare Access is the best-known example: it checks each visitor against your identity provider (Google Workspace, Okta, Microsoft Entra ID) before a request reaches the app, and Cloudflare offers a free plan for small teams.

This is a solid, secure pattern, and many IT teams like it. It still leaves you to host the app, set up the identity provider connection, and write policies. It also only answers "who can open the app." It says nothing about who can change which data inside the app, which is the harder question for anything that saves records.

#Option 5: Publish it to Crow Nest from inside Claude Code

Crow Nest is built for exactly this situation: someone built a useful tool with AI and needs their team to use it, behind sign-in, without becoming a part-time DevOps engineer. You publish from the same Claude Code session you built in.

1. Connect Crow Nest once. In your terminal:

claude mcp add --transport http -s user crow-nest https://crow-nest.com/mcp

Then type /mcp in Claude Code, pick crow-nest, and choose Authenticate. A browser window opens so you can sign in with Google, Microsoft or an email code. Or just paste this into Claude Code and it will set itself up:

Connect Crow Nest: https://crow-nest.com/mcp, then tell me what I can do with it.

The same server works in Claude, ChatGPT, Codex and Cursor. Steps for each are in Connecting your AI.

2. Ask Claude to publish. Say "publish this to Crow Nest." Claude builds the project and uploads the result (the dist or build folder, not your source). Crow Nest asks you two things: a name, which becomes the address (pto-tracker.crow-nest.com), and who can see it.

3. Choose who can open it. Crow Nest never picks for you. The choices, from the sharing docs:

Your teammates don't need a developer account, a Claude seat or a password you made up. They sign in with their work Google or Microsoft account, or an email code, and land in the app. Change your mind later by asking Claude to "share it with sam@example.com" or "make it private," and the change reaches everyone within a minute.

4. Give it a memory if it needs one. If your app saves things, tell Claude to use crow.db. Each app gets its own database with rules for who can read and write each collection (for example, everyone can read requests but only the person who made one can edit it), enforced on the server rather than in the browser. The data docs cover it. Uploads, live updates, calls to outside APIs with secret keys, and server code for webhooks and schedules work the same way, all declared in one crow.json file.

5. Change it and publish again. Every publish is a new version at the same address, and older versions are kept, so a bad change is one "roll back" away.

On cost: publishing and hosting are free. You add a card at sign-up; on Pay as you go nothing is charged until your apps use paid services like storage and server code, and the first $1 of usage each month is free. Crow Nest Personal is a flat $7 a month, and companies we set up pay $5 per person per month. The details are on the pricing page.

#Before you share any AI-built app, check these five things

Whichever option you pick, generated apps fail in predictable ways. Spend ten minutes on these before you send the link:

1. Look for secrets in the page. Search your build output for anything that looks like a key (sk-, key=, token). If it's in the browser, anyone who opens the app can read it. Keys belong on a server or in a secrets store. (Crow Nest refuses to publish files that contain keys for this reason.)
2. Check who can change what, not just who can sign in. Sign-in answers "is this person allowed in." It doesn't answer "can this person edit someone else's record." Broken access control is number one on the OWASP Top 10, and it's the most common gap in generated code.
3. Open it signed out and as a second person. Use a private window, then a teammate's account. Try to see and edit things you shouldn't.
4. Know where the data lives and how to export it. If the tool becomes important, you'll want a copy.
5. Decide who owns it. Tools built by one person become orphans when that person changes teams. Put it somewhere your company can see, so it doesn't become an island only you understand.

#Which option should you pick?

If you're a builder with a working tool and a team waiting for it, start with the option that gets it behind sign-in today. You can always move a tool that outgrows it.

#Frequently asked questions

#Can I share a Claude Code app without making it public?

Yes. Publish it to a host that supports private sharing and choose who can open it. On Crow Nest you can keep an app to yourself, share it with specific email addresses, share it with anyone who has the link and signs in, or open it to your whole organization. None of those make it public, and public apps are hidden from search engines unless you turn that on.

#Do my teammates need a Claude account to use the app?

Not if you publish it as a regular web app. A Claude artifact needs every viewer to have a Claude account, but an app on a web host only needs whatever sign-in the host uses. On Crow Nest, teammates sign in with their work Google or Microsoft account or an email code, and don't need Claude at all.

#Is it safe to share an app Claude Code wrote?

It can be, if you check the usual weak spots. Make sure no API keys are in the browser code, that people can only change their own records, and that the app works correctly when you open it signed out or as someone else. Hosting it behind sign-in, with data rules enforced on the server, removes the biggest risks.

#How much does it cost to host an internal tool built with AI?

It ranges from free to a few hundred dollars a month. A static page can be free on most hosts. Company-only access usually costs extra: on Vercel, Password Protection is $20 per project a month on Pro and SAML SSO is $300 a month. On Crow Nest, hosting and sign-in are included; you pay only for what apps store and run.

#Can I keep building the app after I share it?

Yes. Keep working in Claude Code and publish again when you're happy. On Crow Nest each publish is a new version at the same address, so your team always opens the latest one, and you can roll back to an earlier version if something breaks.