AppsMCP

Deployments

Deploy your MCP server from GitHub or a .zip file

Deployments, in the app's MCP menu, is where you ship your server. You can connect a GitHub repository, so every push deploys, or upload your project as a .zip file.

Your codeA GitHub repository or a .zip file
BuildNode.js 20; start command detected
LiveServed at your MCP endpoint
The Deployments page: Connect Repository and Upload Code Package on the left, Deployment history on the right

Deploy from GitHub

Install the GitHub App

Your organization needs the NitroStack GitHub App. Install it once from Integrations.

Pick a repository

Under Connect Repository, search for the repository and select it.

Click Link Repository & Enable Auto-Deploy. NitroCloud deploys the repository, and deploys again on every push.

You can also deploy a linked project straight from NitroStudio.

Upload a .zip file

Under Upload Code Package, drag your project's .zip file onto the drop area, or click it to choose the file. The package must:

  • contain your whole NitroStack project, including package.json and all source files
  • be 100 MB or smaller

TypeScript projects build on the Node.js 20 runtime. nitrostack-cli pack creates a clean archive without node_modules, build output, or .env files.

Python projects

NitroCloud recognizes a Python app when nitrostack is a dependency in pyproject.toml or requirements.txt, or the code imports it. The same packaging rules apply: the archive holds the project root (or the project one folder down), and it's 100 MB or smaller.

The container runs python main.py, with HOST=0.0.0.0, PORT=3000, and MCP_TRANSPORT_TYPE=http already set. You don't need a Dockerfile, and a uv.lock in the archive is used when present. Python builds don't use npm start.

Before you upload, check the project locally:

nitrostack-py validate
MCP_TRANSPORT_TYPE=http nitrostack-py start

See Prepare your project for the full checklist of files.

Start command

NitroCloud detects how your app starts from your code, and shows Auto-detected when it has. If detection fails, click Add Start Command and enter it yourself.

Environment variables

Add your secrets and settings under Environment variables: click Add Variable for one, or Bulk Edit to paste several. Values are encrypted, and they apply to the next deployment, so deploy again after you change them.

Keep secrets here, never in your code or in a committed .env file.

Deployment history

Deployment history lists every deployment, newest first. The one serving traffic is marked Live, with a Production badge; earlier ones are marked Previously live. Each entry shows its version (v6, v5, and so on), how long the build took, how it was deployed, such as a CLI deployment, and when and by whom.

Deployment details

The arrow on an entry opens that deployment. Its page shows:

  • the version, its status (Live, Previously live, or failed), who deployed it, and when
  • where it came from: a GitHub push, a .zip upload, or NitroStudio
  • the build log
  • the environment variables applied to that build, with their values masked
A live deployment: its version and status, the pipeline steps, details about who deployed it and when, and the deployment logs

When a deployment fails

A failed deployment stays in Deployment history and never becomes Live. The previous live deployment keeps serving traffic, so a bad build doesn't take your server down.

Open the failed entry and read its build log.

A deployment marked Cancelled that never became live, with its pipeline steps, details, and deployment logs
The usual causes are:

  • a missing entry file: package.json for TypeScript, or main.py for Python
  • a start command that doesn't listen on port 3000
  • an archive over 100 MB, often because it includes node_modules

Fix the cause and deploy again. Changing an environment variable doesn't affect the running deployment either; add the variable, then deploy again.

Next steps

Watch the video

Check out the video for a walkthrough of everything on this page.

On this page