DEPLOYMENT GUIDE

How to deploy an AI-built internal tool

A working project needs identity, an owner and a place in the company inventory before colleagues can rely on it.

Start with four decisions

Name the person who owns the tool. Choose the Google group that should use it. List the data stores and API keys it needs. Decide where the source code should live.

You can answer those questions before anyone touches deployment settings. They also give IT enough context to review the app without reading the whole codebase.

Deploy from the coding agent

  1. Connect the company Google Workspace once.
  2. Install the aidrop Deploy MCP connector in Claude Code, Cursor or Codex.
  3. Ask the agent to deploy the working project.
  4. Choose a Google group and confirm the owner.
  5. Open the company registry to check the URL, resources and access list.

MCP gives AI clients a standard way to call external tools. The official MCP introduction explains the protocol and the systems it can connect.

Keep access outside the app

Put sign-in in front of the container. The application should receive authenticated requests and no user passwords. Keep API keys in managed secrets rather than source files or deployment prompts.

aidrop Deploy checks source uploads for secrets, attaches the selected Google group and records the owner in the registry.

Catch the common deployment mistakes

A preview URL is easy to share and hard to govern. Before you send a link, confirm that unauthenticated requests stop at the access layer. Open the app in a private browser window and test with an account outside the allowed group.

Check the source for copied credentials and local data files. Replace personal API keys with company-managed secrets. Move persistent data to an attached database or storage service instead of relying on the container filesystem.

Record enough information to operate it

The registry entry should show the owner, repository, access group, attached resources and last deployment. Add a short description of the job the tool performs. A colleague should be able to decide whether the app still belongs in production without asking the original author to reconstruct its history.

Keep the previous deploy available for rollback. A failed health check should stop the new version before it replaces the working one.

Plan the handoff

A small internal tool may stay with its original owner. A tool that handles a critical workflow needs source custody and an engineering owner. Mirror the repository to the company GitHub organization before that handoff becomes urgent.