Deploy Static sites and SPAs on Nodion

Deploy Static sites and SPAs step by step

1. Commit a lockfile and a build script Commit your lockfile; the build fails without one. Nodion runs the build script and takes the output folder from your framework: dist/ for Vite, build/ for Create React App, dist/<project>/browser for Angular, public/ for Gatsby and _site/ for Eleventy. package.json

   "scripts": {
     "dev": "vite",
     "build": "vite build"
   }

2. Set build variables Your bundler writes variables such as VITE_*, REACT_APP_* or GATSBY_* into the files during the build, so they need the Build flag on the Environment tab. Everything in them is public, so never put secrets there.
3. Name other output folders in static.toml Other generators work too: Nodion looks for an index.html in dist, build, out, .output/public, public and _site. If yours writes somewhere else, as VitePress does, add a static.toml next to package.json. It also makes Nodion treat the repository as a static site when it would not detect one. fallback names the file served for paths that do not exist. static.toml

   output-dir = "docs/.vitepress/dist"
   fallback = "index.html"

4. Plain HTML needs no build A repository with an index.html in the root and no package.json is served as it is. Nodion leaves out .git, .env files and some common key files, but treat everything you commit as public and keep secrets out of the repository.
5. Create the app and push In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository in the region EU Central and pick the smallest size. Every push builds a new release, and traffic moves to it once / answers, which your index.html takes care of.

Good to know

• Client-side routing worksPaths that match no file get your index.html, so React Router, Vue Router and Angular routes survive a reload. The fallback cannot be switched off; fallback in static.toml only swaps the file.
• No Procfile processes, no server codeProcfile processes have no effect on a static site, and only the output folder ships. A release: line would still run, but in an image that holds only the built files, so leave it out. If your repository is a Node.js server with a build script, read the Node.js guide for how Nodion tells the two apart.
• Angular SSRNodion builds Angular projects as static sites, also with @angular/ssr, so server rendering does not run. For SSR, use a Dockerfile.
• Hugo and JekyllNodion does not run Hugo or Jekyll builds. Build the site yourself, commit the generated folder (public/ or _site/) and set the app's base directory to it: a folder with an index.html and no package.json is served as it is. Or build the site in a Dockerfile.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Preview Environments Explained: An App per Pull Request A running copy of your app for every pull request: what preview environments are good for, where they get tricky and how Nodion handles them.
• Cloud Native Buildpacks Explained Buildpacks turn your source code into a container image without a Dockerfile. What they are, and how they work.

Static sites and SPAs on Nodion: questions and answers