Blog · October 19, 2026 · Rich Chetwynd
How to share an internal tool without a public URL
Share an internal tool without a public URL: host it on Croft as a private team deploy, not a public PaaS link, a tunnel, or emailed HTML.
Quick answer
To share an internal tool without a public URL, host it on a private team host colleagues can open, not a default-public PaaS link. Croft is that host: one lasting private URL, a database with the deploy, and everyone signs in with the company login, while you keep building in Cursor, Claude, or another assistant. That is how you privately deploy an AI internal tool, host a vibe-coded app behind company login, and share a Cursor app with the team privately, without a tunnel from a laptop or becoming ops for a public PaaS.
This post is the share decision: how the team opens the tool without putting it on the open web. Adjacent hosting choices: Where to host a Cursor vibe-coded app for your team and How to do a private full-stack deploy with a database.
You built the tool. Sharing it should not mean going public.
Cursor, Claude, and similar assistants make it easy to ship a useful internal tool: an ops panel, an approvals queue, an admin UI, a tracker. It runs for you. Then you need teammates to open it.
What people try first, and why it falls short for a team:
- A public PaaS URL. Railway, Render, Vercel and similar give you a live link fast. The default posture is internet-facing. Privacy and who can open it are extra work you own.
- A password or an obscure link. A secret path or a shared password still sits on a public host. Passwords get forwarded. Obscurity is not access control when the URL can leak in Slack, a screenshot, or search.
- A tunnel or ngrok link from a laptop. Fine for a five-minute demo. The tool dies when the laptop sleeps, the URL changes, and you are the server.
- Emailing HTML or a zip. Each person has a snapshot. Nothing is shared, saved together, or updated in one place.
- A DIY VPS with nginx. You can harden it. You also own SSL, auth, backups, and every next internal tool.
Developers hit this after vibe-coding something the company actually needs. They pick a private team host when they do not want public-PaaS ops for a staff-only app. Non-developers hit the same cliff when the assistant built something useful and there is no lasting place for colleagues to open it.
Broader context: Where to host a vibe-coded app privately, Where to host an app I built with AI, Croft vs Railway, and the rest of alternatives.
What sharing without a public URL should mean
For an AI-built internal tool, “share it” is not “any live link.” It means:
- A lasting private URL colleagues can bookmark and reopen
- Private by default, not a public URL you lock down later
- Team sign-in, so only your people open it (company login as the access benefit)
- Shared saved data so everyone works against the same app, not emailed copies
- Room to keep iterating in Cursor or Claude and redeploy without babysitting nginx or a tunnel
Related: artifacts to apps, for developers, host a Cursor app, deploy with an AI agent.
Public PaaS vs tunnel vs DIY VPS vs Croft
| Need | Public PaaS | Tunnel (ngrok and similar) | DIY VPS + nginx | Croft private team host |
|---|---|---|---|---|
| Default posture | Public / preview by default | Your laptop is the server | You harden it | Private by default |
| Who can open it | Anyone with the URL unless you lock it down | Whoever has the live tunnel link | Whoever you expose | People you invite |
| Setup | Fast public URL; privacy extra | One command, then it is your uptime | nginx, SSL, auth, backups | Connect the assistant, deploy |
| Upkeep for a team tool | You own auth, privacy, often a DB | Laptop must stay on; the link changes | You own the box | Low: backups and rollback included |
This is posture, not a peer feature checklist. Public PaaS hosts shine when the app faces the internet. Tunnels are for a demo on your machine. A VPS is for when you want full ops control. Croft is a private team host: you bring the AI-built app; the team gets one place to open it. See Croft vs Railway and alternatives.
When a public URL (or a tunnel) is right
Pick a public PaaS when:
- The app is meant for customers or the public internet
- You want preview deploys and classic product hosting
- You are happy operating privacy, auth, and data yourself as it grows
Use a tunnel when you only need a short live demo from your laptop.
That is a strong job. It is the wrong default when you need to share an internal tool without a public URL and only your company should use it.
When Croft is right
Pick Croft when:
- You built an internal tool with AI and the team needs to open it
- You want to host and share it privately, not publish a public URL
- You do not want a tunnel, emailed files, or a DIY nginx box
- You would rather connect Cursor or connect Claude and deploy than stand up a public PaaS for a staff-only app
Croft uses SQLite per app with shared workspace data. Expect a private place for team apps, optional connectors, templates, and a path to keep shipping from your assistant. Optional in-product AI chat: Ask Croft. Croft has no CLI. Deploys go through the Croft MCP connector from the assistant.
Short path: internal tool → private team host
- Start a free trial and get a croft (private server for your workspace).
- Connect your assistant: Cursor, Claude, or another supported path via agents.
- Ask it to deploy the app to your croft (not a public host, not a tunnel). Optional browser path: Ask Croft.
- Invite colleagues. They open a normal URL, sign in with company login, and use the tool.
More on turning builds into hosted apps: artifacts to apps. Cursor-focused landings: host a Cursor app and Deploy a Cursor app for your company. If the next question is the database rather than the URL, see private full-stack deploy with a database.
FAQ
How do I share an internal tool without a public URL?
Host it on a private team host, then invite colleagues. Croft is built for that: lasting private URL, shared data, team sign-in, backups, while you keep building in Cursor or Claude. See for developers.
How do I privately deploy an AI internal tool?
Connect Cursor or Claude to Croft over MCP, ask the assistant to deploy to your croft, and invite the people who should open it. That is a private deploy of an AI internal tool, not a public PaaS URL. Details: agents and connect Cursor.
How do I host a vibe-coded app behind company login?
Deploy it to Croft. Company login sits in front of the app; everyone signs in with the company login, then uses the tool. Hosting choice: Where to host a Cursor vibe-coded app for your team.
How do I share a Cursor app with my team privately?
Connect Cursor, deploy to your croft, send the URL. Teammates open it behind company login. Landing: host a Cursor app.
Why not a password-protected or obscure public link?
It is still a public URL. Passwords get forwarded. Obscure paths leak. For a team tool, grant access to people, do not hide a public host.
Why not ngrok or another tunnel from my laptop?
A tunnel is a demo, not a place the team can rely on. The link depends on your machine staying awake, and it is still not a private team host with shared data and backups.
Is Croft the same as Railway, Render, or Vercel?
No. Those are public PaaS options for internet-facing services. Croft is a private team host for AI-built internal apps. See Croft vs Railway.
Do only non-developers use Croft?
No. Developers use Croft for small private team projects when they do not want Railway/Render/Vercel-style infra. Non-developers use it when the assistant built the app and they need a private place the team can open. See Croft for developers.
How much does Croft cost?
Solo from $24/month on annual billing, Team $99/month on annual. 7-day free trial, no card to start. See pricing.
Start free trial → · For developers → · Host a Cursor app → · Ask Croft → · Pricing →
Start your free trial.
Your team's first app could be live before lunch.
No card. 7 days. Cancel anytime.