BasicDeploy

Create a new empty BasicDeploy container. A PostgreSQL database and an S3 bucket are provisioned automatically for it. Returns the container's id, subdomain, and public URL. Its public URL is proxied to PORT 8080 inside the container, so whatever you deploy MUST listen on 0.0.0.0:8080 (any other port/binding returns 503). Use deploy_app or exec_command afterwards to put an application in it. Optional memoryMb (256/512/1024/2048) and alwaysOn require the plan/add-ons to allow them (see get_account); larger sizes need Pro/Scale, and always-on on Free consumes a paid add-on slot.

PERMANENTLY delete a container. This destroys the container, its database, and all its files (S3 bucket contents included) and cannot be undone. Only call this when the user has clearly asked for the container to be removed.

Deploy an application from a local tarball (.tar, .tar.gz, .tgz, or .zip) to BasicDeploy. The runtime (Node.js, Python, or Go) is auto-detected from the archive contents; the app must listen on 0.0.0.0:8080. If containerId is omitted, a new container (with DB + S3) is created for the app; if provided, the archive is deployed into that existing container. Returns the resulting container and its public URL. IMPORTANT: tarballPath is a path on the machine running THIS MCP client (i.e. the local/stdio install). When BasicDeploy is added as a REMOTE connector (Claude/ChatGPT/Gemini chat) there is no shared filesystem, so this tool cannot read your tarball — deploy with exec_command instead (write the files into the container and start the server on 0.0.0.0:8080).

Run a shell command inside a container (like docker exec). Returns the combined stdout/stderr output and the exit code. Useful for inspecting files, installing packages, or restarting processes inside the container. DEPLOYING WITHOUT A TARBALL (the way to deploy over a remote/chat connector, where there is no shared filesystem for deploy_app): write your app's files into the container with exec_command (e.g. heredoc/echo or install from git), install deps, then start the server. CRITICAL: the container's public URL (https://<subdomain>.basicdeploy.com) is ALWAYS proxied to PORT 8080 inside the container, so your app MUST listen on 0.0.0.0:8080 — NOT localhost/127.0.0.1, and NOT 3000/5000/etc. Any other port or binding returns HTTP 503 at the public URL even though the process is running. The routing is wired when the container is created; you do NOT need deploy_app to 'register' it. There is no init/supervisor: a process you start runs only until the container sleeps or restarts and is NOT relaunched — for a long-running web server enable always-on (set_always_on) and start it detached.

Show the account's plan and capabilities: plan tier, container limit (plan base + add-ons), the memory sizes you may select, storage limit, how many always-on add-ons you hold, and whether containers auto-sleep. Use this to see what you're allowed to set.

Get full details of one container: id, subdomain, public URL, status, ports, database name and username, S3 bucket, volume path, and timestamps.

Fetch the BasicDeploy documentation as Markdown so you can answer the user's questions and deploy correctly without leaving the chat. Covers: what BasicDeploy is, deploying an app (the 0.0.0.0:8080 rule), the runtime and preset env vars, the PostgreSQL database and S3 object storage, the REST API, the MCP tools, custom domains, SSH, plans/pricing, and hosted auth-as-a-service (OpenID Connect) for your app's own end-users. Optional 'topic' returns only the matching section(s).

Fetch recent logs from a container. Use this to debug crashes or check application output.

List all BasicDeploy containers owned by (or shared with) the authenticated user. Returns each container's id, subdomain, public URL, status, and creation time.

Turn a container's always-on (24/7, never sleeps) flag on or off. On Free this consumes a paid always-on add-on slot (fails if none is free); on Pro/Scale every container is always-on already. Returns the updated container.