deploy

Deploy a folder and print its URL once it is live.

The tool of basemodo deploy, on the local MCP and the remote one. It changes things, so an agent's client may ask you before it runs.

Packs the folder (leaving out .git, what its .gitignore, .ignore, .basemodoignore and .dockerignore exclude, what the .gitignore and .ignore above it in its git repository exclude, and its .env files but .env.example unless --include-env), uploads it, and Basemodo detects how to build and run it (or reads basemodo.toml), builds it and starts it; the command waits until the App answers HTTP at its URL. The App is created the first time. A Deploy that fails leaves the previous one live. With --repository there is no folder: the App is linked to that GitHub repository and its branch's latest commit is deployed. With --template app|site there is none either: an App with no Deploy yet starts from a Template Basemodo serves.

Arguments

• path (text): The folder to deploy. Default: the current one.
• name (text): The App to deploy to. Default: name in basemodo.toml, else the folder's name (with --repository, the repository's name).
• repository (text): A GitHub repository to deploy instead of a folder, as owner/repo: the App is linked to it and its branch's latest commit is deployed now, and again on every push. Basemodo's GitHub App must be able to read it.
• template (text): A Template to start the App from instead of a folder, app or site, as Basemodo serves it. Only an App with no Deploy yet starts from one.
• branch (text): With --repository: the branch to deploy. Default: the one the App is linked to, else the repository's default branch.
• subdir (text): With --repository: the folder of the repository that holds the App (apps/web). Default: the one the App is linked to, else the whole repository.
• workspace (text): The Workspace whose App this is, by name: deploy to its App of that name, creating it the first time (which takes an Admin of the Workspace). Default: your own App of that name, else the one App of that name a Workspace of yours owns, else a new App of your own.
• link (flag): In a clone of a GitHub repository: link the App to it (this branch and folder) without asking, so every push deploys it.
• no_link (flag): Do not offer to link the App to the folder's GitHub repository.
• approval (text): The Charge Approval an Admin approves on basemodo.com, as a refused deploy gave it, when the new App goes beyond the Apps the Workspace pays for (an Additional App) or its workers beyond the Always On Apps (an Always On App): wait until it is approved, then create or deploy with it.
• allow_public (flag): Open the paths this Deploy adds to (or widens in) public_paths or [callers] paths beyond the live Deploy's: anyone reaches a Public Path, and the App's Callers their paths, past sign-in with no role checked. Only the Owner (an Admin, for a Workspace's App) may, and an agent asks the person first. Without it, such a Deploy is refused naming the paths.
• description (text): What this Deploy changes, in one line of at most 200 characters: kept as its commit's message in the App's history. A push's Deploy says its commit message's first line instead.
• include_env (flag): Upload the folder's .env files too, which deploy leaves out (all but .env.example) whatever the ignore files say: they hold secrets, which go in with basemodo env set, never in the App's code, where every Editor reads them.
• replace (flag): In a folder that came from Basemodo, deploy it even though the App's code changed since (a Change from a chat, another folder's Deploy): the folder as it is replaces those changes, which stay in the App's history. Without it, such a folder is refused, to bring the changes in first with basemodo pull.

On the remote MCP

The remote MCP has no folder of yours, so there the tool works this way.

Start an App from a Template, or deploy a GitHub repository, and print its URL once it is live.

With template (app or site), the App named name (created the first time) starts from that Template as Basemodo serves it; only an App with no Deploy yet starts from one (app_has_deploys otherwise). With repository, the App (named name, default the repository's name; created the first time) is linked to the repository, its branch (default the default branch, or the one it is linked to) and folder (subdir), and the branch's latest commit is deployed now, as every later push is. Basemodo detects how to build and run it (or reads basemodo.toml), builds it and starts it; the call waits until the App answers HTTP at its URL, for 45 seconds at most: a Deploy still going then answers with its deploy (its status: queued, building or starting) and next, which says to call status until its latest_deploy is live or failed. A Deploy that fails leaves the previous one live. A commit whose basemodo.toml opens paths past sign-in beyond the live Deploy (public_paths, [callers] paths) is refused allow_public_required, naming them: call again with allow_public only once the person agrees to open them. Basemodo's GitHub App must be able to read the repository: when it cannot, the error's fix is where the person installs it. When the App goes beyond what its Workspace pays for, the call answers charge_required with the Charge Approval an Admin approves on basemodo.com (approval: its url, id and expires_at): give the person the link, and call again with approval set to its id once they approved.

Its arguments there:

• name (text): The App to deploy to. Default: name in basemodo.toml, else the folder's name (with --repository, the repository's name).
• repository (text): A GitHub repository to deploy instead of a folder, as owner/repo: the App is linked to it and its branch's latest commit is deployed now, and again on every push. Basemodo's GitHub App must be able to read it.
• template (text): A Template to start the App from instead of a folder, app or site, as Basemodo serves it. Only an App with no Deploy yet starts from one.
• branch (text): With --repository: the branch to deploy. Default: the one the App is linked to, else the repository's default branch.
• subdir (text): With --repository: the folder of the repository that holds the App (apps/web). Default: the one the App is linked to, else the whole repository.
• workspace (text): The Workspace whose App this is, by name: deploy to its App of that name, creating it the first time (which takes an Admin of the Workspace). Default: your own App of that name, else the one App of that name a Workspace of yours owns, else a new App of your own.
• approval (text): The Charge Approval an Admin approves on basemodo.com, as a refused deploy gave it, when the new App goes beyond the Apps the Workspace pays for (an Additional App) or its workers beyond the Always On Apps (an Always On App): wait until it is approved, then create or deploy with it.
• allow_public (flag): Open the paths this Deploy adds to (or widens in) public_paths or [callers] paths beyond the live Deploy's: anyone reaches a Public Path, and the App's Callers their paths, past sign-in with no role checked. Only the Owner (an Admin, for a Workspace's App) may, and an agent asks the person first. Without it, such a Deploy is refused naming the paths.
• description (text): What this Deploy changes, in one line of at most 200 characters: kept as its commit's message in the App's history. A push's Deploy says its commit message's first line instead.

It does not take path, link, no_link, include_env, replace.

Answer

It answers {"url", "app", "deploy"}, the live Deploy with what was detected, and "left_out": {"files", "why"} when it left .env files out; progress events on stderr (upload, detect, queued, build_turn, build, start, ready). A failed Deploy is an error with "deploy" and the build "log". Run by an agent (an MCP tool), it waits for the Deploy at most 45 seconds: one still queued, building or starting then is a result, not an error, with its "deploy" (and "status") and "next", which says to call status until its latest_deploy is live or failed. A new App, or workers, beyond what its Workspace pays for asks an Admin for a Charge Approval, approved on basemodo.com in their own browser: in a terminal it opens the approval's page and waits for it; with --json or no terminal, an error with code charge_required, its "charges" (each "item": additional or always_on, "monthly_cents", "currency", "next_invoice_on") and its "approval" ("id", "url", "expires_at"): nothing was created or deployed. --approval waits until it is approved, then goes on; a new App and its workers each ask for their own. Only an Admin approves one, an Editor's Deploy included (its link goes to the Admins); a push from GitHub never charges: always_on_not_reserved.