Astro

Nitroship supports Astro’s static output and the standalone Node adapter.

Detection and build outputCopy Anchor Link

• Detection: astro in package.json; use a build script such as astro build.
• With @astrojs/node, configure node({ mode: "standalone" }) in astro.config.mjs. The server starts with node dist/server/entry.mjs, while dist/client is served from the CDN.
• The Node server bundle includes production dependencies. Put packages imported at runtime in dependencies, not only devDependencies.
• Without an adapter, Astro’s static dist is published with no compute region. Other adapters are not managed by this preset.

DeployCopy Anchor Link

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

{
  "build": {"framework": "astro"},
  "compute": {"regions": ["kr-icn"]}
}

Setting build.framework skips detection and uses this preset, even if your project root has a Dockerfile. It can't be combined with build.dockerfile. Without it, Nitroship detects the build as described in How Nitroship chooses a build.

ntro apps create my-astro-app
ntro deploy . --prod

After installing dependencies, you can also build locally with ntro deploy . --prod --local. After deployment, open static assets and a server route at the URL printed by the CLI.

Node adapter exampleCopy Anchor Link

import { defineConfig } from "astro/config";
import node from "@astrojs/node";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
});

For /_image transformation on a static site, add {"images":{"protocol":"astro"}} to nitroship.json. Remote images require an allowlist; see Image optimization.

Limits and custom setupsCopy Anchor Link

Server deployments need a compute region. Your server must listen on 0.0.0.0:$PORT (default 3000). Client assets come from the CDN, and a single Node server handles all SSR and API requests; routes aren't split into separate functions the way Next.js routes are.

Nitroship does not automatically run migrations, queue workers, or schedulers. Run migrations in CI or locally; see Scheduled jobs for periodic work. Store uploads in S3 or other object storage, and configure secrets through Environment variables.

For adapters or output layouts outside this contract, use your own Dockerfile. Remove build.framework and define installation, build, and startup in the Dockerfile.