How to Share a Local AI App with Your Team

From an AI-built prototype to a private team application

You have used ChatGPT, Claude, Cursor, or another coding assistant to make an application. It works on your computer. The next job is to give colleagues one reliable URL without accidentally publishing the app, its data, or its administration tools to the whole internet. This walkthrough follows the path Tier1 generally uses for a suitable small internal app: prepare the project for Cloudflare, create the customer-owned account, connect an AI coding client to Cloudflare’s official MCP server, deploy to Workers, and then configure Access before treating the URL as ready for the team.

Step 1: Give your AI assistant the production goal

Paste the prompt below into the conversation that created the app, or use it to begin a new project. It tells the assistant that deployment and private access are requirements—not cleanup tasks for later. The assistant should inspect the existing project before changing frameworks. Review every proposed change and keep the project in source control. Do not give an AI assistant unrestricted account permissions or paste long-lived secrets into chat.

Prompt for ChatGPT, Claude, or Cursor

I am building a small internal web application for my team.

The application must:
- run on Cloudflare Workers, using Workers Static Assets where appropriate
- have one documented build and deployment command
- keep secrets out of source code and client-side JavaScript
- fail safely and show useful errors without exposing sensitive details
- use supported Cloudflare storage or bindings only when the app needs them
- be protected with Cloudflare Access before production use
- allow only the staff identities or groups I approve
- include a short README covering local development, deployment, rollback, access, and ownership

If this is an existing project, inspect its framework, dependencies, data flows, environment variables, and runtime assumptions before editing it. Tell me clearly if any dependency or design does not fit Cloudflare Workers.

Do not deploy, create paid resources, change DNS, or weaken an Access policy until you show me the proposed action and I approve it. Never print or commit secret values.

Step 2: Create the Cloudflare account the business owns

Create the account with a business-controlled email address and record who owns billing and recovery. The application, domain, and production resources should not live only inside a developer’s personal account.

1. Open Cloudflare’s Workers sign-up page and create or sign in to the business account
2. Verify the account email and enable multi-factor authentication
3. Invite a second appropriate administrator rather than sharing one login
4. Record the Cloudflare account name and Account ID in the project handover
5. Decide who may approve deployments, DNS changes, and Access policies

Create a Cloudflare account

Step 3: Connect the official Cloudflare MCP server

Cloudflare’s API MCP server gives compatible AI clients tools for the Cloudflare API. Add the remote server to your client, then complete the Cloudflare OAuth screen when the client first connects. Read the requested permissions and grant only what this project needs. For Cursor, add the server through MCP settings or use the project configuration shown below. Other compatible clients have an equivalent remote-MCP URL field. The official endpoint is https://mcp.cloudflare.com/mcp.

1. Open the AI client’s MCP settings
2. Add the Cloudflare API server URL
3. Connect and follow the Cloudflare OAuth redirect
4. Choose the correct business account
5. Review and limit the requested permissions
6. Ask the client to list the account or Workers projects to confirm the connection

.cursor/mcp.json

{
  "mcpServers": {
    "cloudflare-api": {
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

Cursor and Cloudflare setup · Cloudflare MCP server catalogue

Step 4: Prepare the local project for Workers

Before asking the assistant to deploy, make sure another person can reproduce the app locally from the repository. A successful preview on the original computer is not enough.

• Commit the source to a private Git repository owned by the business
• Document the install, development, test, build, and deployment commands
• List environment-variable names in an example file without secret values
• Move server-side secrets out of browser code and local files
• Confirm which data stores and external APIs the app uses
• Run tests and inspect the production build before deployment
• Have the assistant explain any Worker compatibility changes

Step 5: Deploy the app to Cloudflare Workers

Ask the assistant to show the proposed Worker name, configuration, resources, and deployment command before running it. The first deployment normally receives a workers.dev address. A custom domain can be added later when the deployment is stable.

1. Review the generated Wrangler configuration and Worker name
2. Confirm the selected Cloudflare account and any resources that will be created
3. Add required production secrets through an approved secret flow—not the repository
4. Run the project’s tests and production build
5. Approve the deployment and record the resulting workers.dev URL
6. Open the deployed app and test its main path before adding real data

Typical deployment command

npx wrangler deploy

Deploy with Workers Builds

Step 6: Protect the Worker with Access

A successful deployment is not the finish line. A workers.dev URL is reachable on the internet unless you protect it. For an internal application, configure Access before sharing the address or loading real business information. Cloudflare’s current Worker-level Access flow can protect the Worker across its production URL, custom domains, routes, and previews. If the application uses WebSockets, follow Cloudflare’s hostname-based Access guidance instead because Worker-level Access does not currently support WebSocket upgrades.

• In Cloudflare, open Workers & Pages and select the Worker
• Open the Access tab and choose Protect this Worker behind Access
• Choose All traffic so production and previews are covered
• Select or create an Allow policy for named emails, the business email domain, or an approved identity-provider group
• Set an appropriate session duration and apply the policy
• Do not add a Bypass rule just to make testing easier

Cloudflare’s Worker Access guide

Step 7: Prove that private really means private

Test the final URL in a private browser window before calling the app ready. A signed-out visitor should see the Access login page—not the application. An approved staff member should get in, and a different account should be denied.

• Signed-out request is stopped before app content loads
• Approved staff identity can sign in
• Unapproved identity is denied
• Preview URLs are protected as well as production
• Secrets do not appear in browser code, logs, or the repository
• The owner knows how to add and remove access

What to record after the first deployment

Write down the production URL, Worker name, repository, Cloudflare account owner, Access policy owner, identity provider, deployment command, secret names, rollback path, and support contact. Re-test Access after domain, route, identity, or policy changes. If there is no reliable working app yet, the workflow crosses several systems, or the result will make consequential decisions, stop treating this as a simple deployment. Tier1’s AI & Internal Systems service starts with process, data, ownership, and controls before choosing a production platform.

Explore AI & Internal Systems

Sources and further reading

• Static assets on Cloudflare Workers — Cloudflare
• Choose a Cloudflare Access application type — Cloudflare
• Cloudflare Access identity providers — Cloudflare
• Create a Cloudflare account — Cloudflare
• Cloudflare's managed MCP servers — Cloudflare
• Connect Cursor to Cloudflare — Cloudflare
• Deploy Workers from a Git repository — Cloudflare
• Protect a Worker with Cloudflare Access — Cloudflare

Frequently asked questions