Deploy the Platform

Read AGENTS.md, the README deployment section, and this repository's deploy configuration and scripts. Use those files to identify the provider and its exact commands, required CLI versions, environment file, and teardown behavior. Do not assume every template has deploy scripts or supports the same flags. For Docker or an existing Kubernetes cluster, follow the repository's Compose or Helm instructions.

Never print credentials or the MCP connect secret. The JWT verification key is public and may be shared to complete configuration.

1. Prepare

• Check the required tools and the authenticated provider account. Interactive logins belong in the user's terminal.
• Confirm the intended workspace, account, project, region, or cluster context before making changes. Use the inputs required by this repository's commands.
• Set up the project environment if the deploy scripts need it. Use the production env file documented in the README; create it from example.env only if absent. Configure credentials without printing them. Check how the deploy scripts load settings rather than assuming they read .env or exported shell variables.
• Keep production authentication enabled. Do not upload RUNTIME_ENV=dev. Configure JWT_VERIFICATION_KEY or a JWT_JWKS_FILE available on the server.
• If a sandbox is requested, configure its provider and REPOSITORY in app/sandbox.py using the sandbox setup guide. AgentCore needs an existing runtime, host AWS access, and an S3 checkpoint bucket. Set SANDBOX_ENABLED = True and the repository in code; set SANDBOX_PROVIDER=agentcore, runtime ARN and checkpoint bucket/prefix in the hosted environment. Do not attach an API disk or use PostgreSQL for checkpoint archives. Supply GitHub tokens at runtime and optional Bedrock overrides through the provider's env. Never put secret values in source.
• See docs/scaling.md for current scaling guidance.

2. Choose first deployment or update

Use the provider's status/list commands, saved project identifiers, and local configuration to find an existing deployment. A failed health check does not mean its resources are gone. Resolve authentication, permission, and network errors before deciding to create anything. Link an existing project where required.

For a new deployment, explain which resources will be created, their billing, and the actual teardown command and data it deletes. Run the README's first-deploy procedure with the intended account and target explicitly selected. For owned infrastructure, configure its public URL and JWT key before first boot.

For an update, follow the README's code and environment update commands. Read the scripts to establish their order and whether updating settings also triggers a redeploy. Use flags such as --no-deploy only when implemented by that script. If a command fails, inspect existing resources and any partial settings changes before retrying. Do not create a second project to recover from a failed deploy.

3. Complete authentication and settings

Some providers create a URL before the API can start. Follow this repository's handoff: use that URL to connect a Live OS at https://os.agno.com/?ref=railway-template, enable token-based JWT authorization, and obtain the public verification key. Save the full key as a quoted multiline JWT_VERIFICATION_KEY in the production settings, or configure JWT_JWKS_FILE. Then use the documented sync/deploy commands to finish. Do not treat an exit code or missing-key stop as identical across providers.

Ensure AGENTOS_URL is the public HTTPS URL used by the scheduler and MCP OAuth. Keep MCP_CONNECT_SECRET in the production settings for browser MCP connections. Check how this provider clears remote variables; removing a local line may not remove the saved value. Database credential rotation is separate from updating API settings. Disable a sandbox by setting SANDBOX_ENABLED = False in app/sandbox.py and redeploying.

4. Verify and hand over

Build submission is not successful deployment. Inspect bounded provider logs and test the public URL: /health must succeed; unauthenticated /agents requests and MCP initialization POSTs must reject access. A plain GET /mcp may return public server-card metadata; it does not test authorization. With MCP OAuth enabled, verify the POST's Bearer challenge. Exercise an authenticated request with an existing token, then confirm the UI connects at os.agno.com.

Model prompts spend calls; report exactly what ran. Coding agent HTTP runs, delegation, and Company Task completion need separate verification before claiming they work.

Provide the URL, verification results, and this repository's commands for code updates, settings, logs, and teardown. For browser MCP, use <AGENTOS_URL>/mcp and tell the user to enter MCP_CONNECT_SECRET from the production settings into the consent page; do not print it. For coding clients, use uvx agno connect --url <AGENTOS_URL>.