Skip to content
Docs

Deploying

What happens when you deploy a folder: what is sent, how Basemodo works out how to build and run it, when it goes live, and what happens when it fails.

A Deploy is one published version of an App. You make one with basemodo deploy in the App's folder (or an agent makes one with the deploy tool). The first Deploy creates the App.

What is sent

The CLI packs the folder and uploads it. It leaves out .git and everything your .gitignore, .ignore, .basemodoignore and .dockerignore files exclude, so dependencies like node_modules and build output stay home (Basemodo installs and builds on its own machines, never on yours). A folder may pack to at most 50 MB; add a .basemodoignore (same syntax as .gitignore) to leave out large files you do not need.

How Basemodo knows what to build

Basemodo looks at the files and says what it found and why: "Detected Next.js 15 (next.config.ts, package.json dependencies.next)". That detection decides how to install, build and start the App. Supported runtimes lists what it recognizes and what each becomes. In short:

  1. A Dockerfile at the top of the folder wins: Basemodo builds it as it is.
  2. Otherwise a framework it knows (Next.js, Django...), then a runtime it knows (Node, Python), then a static website (an index.html).
  3. Otherwise the Deploy stops with nothing_detected, and the fix names the file to add.

When detection cannot know something (the command that starts your App, the Node version you need, the App's name), say it in the manifest, a small basemodo.toml at the top of the folder: see the manifest. What the manifest changes is listed next to the detection's explanation, each with its line.

The stages

basemodo deploy reports each stage as it happens (an agent receives them as progress):

  • upload: the folder is packed and sent.
  • detect: what Basemodo found, and what the manifest changed.
  • queued: another Deploy of this App is still running; Deploys of one App run one at a time, in the order they were asked for, so two in a row end with the latest one live.
  • build: the image is built on Basemodo's builders. Its log goes into the App's Logs.
  • start: the new version starts on the App's machine.
  • ready: it answered HTTP, so visitors now reach it.

When it is live

Your App must listen for HTTP on the port in the PORT environment variable, on every interface (0.0.0.0), and answer within 60 seconds of starting. Any answer counts, even an error page. Detected Apps do this by themselves; an App started by your own command or Dockerfile must do it itself. How Apps run explains this Port Contract.

When it fails

A failed Deploy changes nothing for your visitors: the previous version keeps running. The error says why, with the fix:

  • build_failed: the build stopped; the error carries the build log, so you (or your agent) can read what broke.
  • not_ready: it built and started, but never answered HTTP on $PORT within 60 seconds.
  • start_failed: it could not start at all.
  • invalid_manifest: basemodo.toml has a mistake; the error names the key and the line.

You are also told by email and in your notifications on basemodo.com.

Going back

basemodo rollback makes an earlier Deploy live again, as a new Deploy that runs that Deploy's image: nothing is rebuilt, and it takes seconds. It uses the App's Secrets as they are now. The App's page on basemodo.com lists its Deploys, with their ids; basemodo deploy --json prints the id of the Deploy it made.

Names and addresses

An App's name is the folder's name, or name in basemodo.toml, or --name: lowercase letters, digits and dashes, at most 40. Its address is https://<name>.basemodo.app, with a short random suffix (lunch-rota-3f9a) only when another App already has that name. Apps live on basemodo.app, a domain apart from basemodo.com, so an App can never read your basemodo.com sign-in.