---
name: deploy-app
description: Use when working in a TeamClu app checkout, changing its build or start declaration, or preparing to publish an app.
---

# Deploy a TeamClu app

The checkout declares the desired build and start behavior. The live deployment and regional capabilities are separate facts. Resolve both before making a deployment decision.

1. Call `manage_app status` for the selected app workspace. Read the current checkout declaration, live deployment, code revision, and source status. Treat the session snapshot as a hint only.
2. Call `manage_app runtime_info` filtered to the app's language. Use the returned regional versions, image observations, layer availability, verification status, and source errors. For a new app, select a TeamClu-deployable candidate from current facts and write every required startup field explicitly. Provider availability alone does not establish TeamClu compatibility. Do not guess a version, path, layer, or compatibility from a template or another region. If discovery times out or is incomplete, keep that uncertainty visible; it does not authorize silently switching to a familiar runtime. A routine redeploy may retain a verified, pinned live configuration when catalog discovery is unavailable and there is no provider drift.
3. Preserve the successful deployment's FC runtime, interpreter command and version, args, layers, and port for an ordinary redeploy. A runtime, interpreter, or layer change is a migration: explain the exact fields and reason, obtain explicit migration intent, and use the preflight preview and native approval. Entry and port changes must also be visible in that preview. Never rewrite the checkout to a known-good version merely because discovery failed.
4. Check the **selected build machine** and its tools. The build command runs there, possibly on Windows, while the function runs on `linux/x86_64`. Verify the declared output and entry exist, and that native dependencies target Linux/x86_64. The daemon's build response includes `artifactVerification` for the pinned `revision`: `checked` means the declared entry and recognizable native headers or local image metadata passed those checks; it does not prove the app starts. ZIP/JAR members are checked through EOF within fixed limits; nested, oversized, corrupt, or unreadable archives stay unknown. Tar and other compressed formats that the daemon cannot inspect also stay unknown. A wrong platform fails before archive upload or image push. `unknown` blocks automatic finalization; it names an opaque startup entry, unclassifiable native content, or unavailable image metadata. The desktop keeps the previous app live. Run an explicit test in the target Linux/x86_64 runtime before treating it as compatible. The current deploy path has no evidence override, so report the deployment as blocked rather than retrying or claiming it published. Keep build commands portable across selected machines.
5. For a Gitea checkout, commit and push the exact app revision to its remote, then verify the **selected checkout is clean and at the exact remote HEAD**. A clean remote commit does not excuse a dirty selected checkout, even if the build would read remote content. Gitea deployment cannot use uncommitted or unpushed changes. For an imported checkout, use the platform's pinned content digest and its source checks.
6. Only when the user explicitly requested publishing, call `manage_app deploy`; review its preflight's exact changes through the existing native approval. Do not bypass a rejected preview, drift, or approval. Deploy the pinned revision, then check `manage_app status`, the runtime configuration, live URL, health path, and changed behavior, including data/auth behavior when applicable. Report the revision and any verification limit.

Custom environment, access, domain, data, files, and cron changes use their matching `manage_app_*` tools and the signed-in user's permissions. Never request or print secret values.

For TeamClu platform sign-in, organization roles, or protected pages and data endpoints, read the inherent `app-auth` skill before implementation. At release, verify its saved policies and report any auth acceptance limits.

## Uninstalling a deployment

Only when the user explicitly requests uninstalling a deployment, call `manage_app undeploy` with an explicit app ID or name and obtain its native confirmation. This stops new gateway requests and cleans the FC function, HTTP trigger, origin domain mapping, build artifact and any legacy login client. It retains the App, code repository, sessions, database, uploaded files, auth policy and scheduled-job definitions. It does not delete the App or archive its repository.

An accepted operation is not a completed uninstall. Read `manage_app status` until `undeploy_operation.status` is `succeeded`; report individual failed steps and retry only when the user requests it. An unknown provider outcome remains fenced for operator reconciliation: do not force a new deploy or bypass the lock. After successful uninstall, use the normal deployment flow to publish again, retaining the last successful configuration as history. Verify retained data and platform login after redeployment; report real-account verification as pending when unavailable.