up reads the directory, works out how to build it, creates the app, creates and connects the database, builds from your git remote and prints the app’s URL. Push your code to the remote first: the server builds from git, not from your working copy.
What up infers
Each value comes from the first of these that has one: a flag, your app spec (app.yaml), detection, a default. up prints every value with where it came from, so you know what to change.
A Node project without a Dockerfile works: it builds with Railpack. A project in a subdirectory of a monorepo (
levelrail-cli up apps/web) builds from that subdirectory.
See the plan first
--dry-run prints what was inferred and the exact commands up runs, and changes nothing:
up asks for confirmation before it changes anything. Pass --yes in scripts.
Run it again
up is safe to repeat. A second run finds the app, database, connection and domain it already made, changes only settings that differ from what you asked for, and rebuilds from your latest push. Nothing is created twice.
If a step fails partway, up stops and says what to run. For example, if the database exists but connecting it fails, no build starts, and the message names levelrail-cli apps connect and says re-running up is safe.
Advanced flags
For anything
up does not cover, use the commands it expands to: apps create, apps scale, apps connect, apps domains add. An app.yaml in the project replaces detection, and flags still override it.
Day to day
rollback without --image goes back to the previous successful deploy. backup uses your only backup target when there is exactly one. Run levelrail-cli help for the everyday verbs and levelrail-cli help advanced for the rest.
See the CLI reference for every command and the getting started guide for the server install.