Server app requirements

Server apps (server-rendered) run on your own App VM. Support is alpha: today that means Next.js with standalone output. Single-package repos build with npm, or with pnpm when pnpm-lock.yaml is their only lockfile; monorepo workspace members can use npm, pnpm, or Yarn classic. This page lists exactly what's checked at import time and how to fix each case. For what alpha means across the platform, see Alpha status.

When you import a repo, Stasho inspects it and blocks the Deploy button if your app would fail its first deploy. Each block links to the matching section below. Fixes take effect after you push and click Re-detect in the notice.

Prompt for your agent

Copy this into Claude Code, Cursor or any agent that can run shell commands. The agent checks your repo against this page and fixes what it can; the import stays a click of yours.

Read https://docs.stasho.xyz/guides/backend-app-requirements.md. I want my repo <owner>/<repo> to
deploy as a server app on my Stasho App VM. Check it against every section of the page: the
framework, output: "standalone" in next.config, the package manager and the lockfile, and a pnpm
pin. Tell me each thing that would block the import. Fix it in a commit or a pull request if I
give you push access, and ask me first. Then tell me, in the page's words, to click Re-detect and
Deploy, and wait for me. Never ask for my wallet key, my seed phrase, a GitHub token or an agent
key in chat.

What a blocked import looks like. Each blocker links to its section here, and the standalone check offers an override.

Standalone output

App VM deploys package your app as a self-contained bundle: a server.js entrypoint at the bundle root with everything it needs to run. Next.js only produces that layout with the standalone output mode:

// next.config.js
module.exports = {
  output: "standalone",
}

Add the setting, push, then click Re-detect in the notice.

The import check is a plain-text scan of your next.config.*. If your config sets output indirectly (a variable, a spread, a wrapper), the check can't see it: use the "deploy anyway" link in the import screen. The deploy itself verifies the real build output either way.

Static sites

A static site (React or Vue with Vite, static Astro, a Next.js static export, or plain HTML) builds to files, with no server to run. Switching one to the Server app target is blocked, because its first build would fail on the App VM. Keep the Static site target. To run it as a server app, move it to Next.js with standalone output first.

Nuxt and Astro SSR

A repo with a nuxt.config.ts or .js, and an Astro project with output: "server" or "hybrid", are detected, but there's no App VM build adapter for either yet. A single-repo import blocks the Deploy button entirely for now. A monorepo import does let you switch a workspace's Deploy Target to Static site, but the detected output for Nuxt is .output, which holds the server too, so set it to .output/public and make the workspace's build script run nuxt generate. We have not built that path end to end.

For Astro the fix is usually one line: drop the adapter and the output setting, and the site builds with Astro's default static output. It then imports and deploys as a normal static site.

Your options today:

• Wait. Adapters are prioritized by demand during alpha. Nuxt is next in line if enough imports ask for it.
• Publish the prerendered output as an uploaded site. If your app can nuxt generate, publish .output/public with stasho create, which needs a key with the create scope, or as a drop, which needs nothing. It has no repo behind it, so each update is a new publish.

Need another framework or runtime? The blocker and step 1 of the App VM wizard carry a Need another framework? Tell us link, which opens an email to hello@stasho.xyz.

Package managers

For monorepo workspace members, App VM builds support npm, pnpm, and Yarn classic (v1) workspaces. Two package managers are still blocked:

• Yarn Berry (v2+). Its install flags and Plug'n'Play layout differ from classic Yarn, and its build output hasn't been verified yet. Switch the repo to Yarn classic, pnpm, or npm workspaces, or watch this guide for updates.
• Bun. Bun workspace builds haven't been verified yet. Use npm, pnpm, or Yarn classic workspaces for now.

Single-package repos aren't affected by this check: they build with npm, or with pnpm when pnpm-lock.yaml is the only lockfile at the repo root.

pnpm version. When your root package.json doesn't pin an exact pnpm version (a packageManager field, or devEngines.packageManager with an exact version), App VM builds use pnpm 9. pnpm 9 can't read some files that pnpm 10 and newer write: a lockfile with patched dependencies, a lockfile that records the pnpm version, or a pnpm-workspace.yaml that holds settings but no packages list. Without that pin, a devEngines.packageManager entry with a version range, a tag or no version stops the build before install. A repo with any of these is flagged at import instead of failing mid-build. Fix it by adding the pnpm you use to your root package.json (the version pnpm --version prints), then push and re-detect:

{ "packageManager": "pnpm@<version>" }

If you keep a devEngines.packageManager entry, it must name pnpm, and any version there must be a range that this version satisfies.

---

Alpha means these constraints shrink over time: when an adapter or package manager gains support, existing blocked imports simply stop being blocked, and nothing on your side needs migrating.

Working with an agent

An agent can read your repo and fix most of this page there: output: "standalone", a pnpm pin, a package manager. No API tells it what the import will say, so it checks the same files the import does. The import itself is yours: the wizard runs in your browser and no agent key creates a project. Once the app exists, a key with read and deploy can read it and redeploy it.

What the agent hands you, in these words:

In the Stasho dashboard open the import screen for <owner>/<repo>. In the App VM notice, click
Re-detect. If the notice is gone, click Deploy. If it still lists something, read me its words.
If it says to add output: 'standalone' and I told you the config sets it indirectly, click the
link that starts "My config already sets standalone", then Deploy. Merge the setup pull request
when the project page asks, and tell me when the deployment reads Pinned or Live.

How the agent verifies it afterwards. The repo holds the fix, and the build proves it. With gh signed in to an account that can read the repo, a build with no standalone output, or no server.js where the bundle needs it, stops the run with a line starting FATAL::

gh run view $RUN_ID --repo $OWNER/$REPO --log-failed

Once the deploy is pinned, the VM's status document lists the app under its projectId, and its entry reads serving when it runs:

curl -sk "https://$VM_HOST:8443/"

With a read key, stasho deployments --project $PROJECT_ID shows the entry go from pinned to live.

See it in the demo

The demo API project shows a live App VM deployment: standalone Next.js output, its own domain, and workspace details.