The first useful Appaloft action is still the same: take this directory and make it reachable. Git can sit next to that path. It is not the input.
We used to print appaloft deploy as the command people copied from the site. That spelling still works. It is the supported 1.x compatibility name. The command a new user should paste is:
appaloft upThat verb landed in public v1.10.0 through appaloft/appaloft#1373. The rest of this post is the product contract around it, not a changelog.
The input is the folder you are in
Most hosted PaaS stories start from a connected repository. That is a reasonable default when the platform also owns the machines. It is a worse default when the developer already has a directory, a runtime, and a server they can reach.
Appaloft’s Deploy door reads the current working directory. Optional local config can point at appaloft.yml. An already-built static tree can be passed as a path. None of those steps require a git remote.
appaloft up --config appaloft.yml
appaloft up ./dist --as static-siteIf the directory already has public/index.html, the CLI can pick static on its own. That is a detection detail, not a second product.
The outcome we ask people to judge is narrow. Success is a live URL for this app. Failure must exit non-zero. We do not publish a demo URL here because we do not have a public folder→URL that a stranger can open and reuse. A placeholder on the Deploy page is https://<public-url>. Inventing a prettier one would be a marketing lie.
Two doors, one runtime change
appaloft up changes shared runtime state. appaloft setup agent does not.
The Agent door writes skill files and MCP configuration into the Cursor or OpenCode already on this machine. After that, the agent still has to ask before every deploy, then run appaloft up and return the live URL. Setup is local instruction. Deploy is the publication step.
That split is the same one we described in Teach Cursor and OpenCode how to deploy. Mixing the two commands on the first screen is how people start treating “the agent is installed” as “the app is live.”
If you are not signed in, the first deploy asks you to sign in. You also need a usable Server. Those are prerequisites, not extra hero commands. Do not stack login, project create, or server enroll next to appaloft up.
What this is not
Appaloft is a Railway alternative, not a 1:1 replacement. Railway’s railway up lives inside a hosted cloud whose default story is a git-connected service. Appaloft’s appaloft up lives on a server you bring. The verbs look similar. The compute owner is different.
The developer CLI is still npm i -g @appaloft/cli or brew install appaloft/tap/appaloft. curl -fsSL https://appaloft.com/install.sh | sudo sh installs the self-host control plane on a server. It is not the command that deploys this folder.
We also do not treat a clean process exit as proof. Health and a public route have to land before the command is allowed to say the app is reachable. That evidence boundary is observed facts — digest, runtime, routing, health, access — not a claim that the application is correct or safe.
Where to start
Humans can stay on /deploy. Coding agents should start at /llms.txt, run appaloft setup agent if the machine is not taught yet, ask before every deploy, then run appaloft up.
If you already have a real public URL from this path, keep it. If you do not, do not invent one for a screenshot, a README, or a Show HN post. The folder is enough to start. The URL has to be earned.