Static Site Generator

Vela can scaffold a frontend-only project, prerendered with @sveltejs/adapter-static and ready to deploy to any static host.

Syntax

$ vela create my-site --template static

The static template ships without a data directory, so there is no PocketBase to run. Build it like any other project:

$ vela build

The adapter is configured in vite.config.ts with a 200.html fallback, so client-side routing works on hosts that serve a single fallback document.

The site’s name and URL are in src/lib/site.ts. Set url there to where the site will be served before building for production: every page is prerendered, and its canonical link and Open Graph image URL are built from it.

Deploying

Upload the build directory to any static host. vela deploy won’t deploy it: it runs the app as a Node server, and stops on a project built with @sveltejs/adapter-static. To serve the site from your own server instead, switch the adapter to @sveltejs/adapter-node. No backend is needed for that.

Converting an existing project

A project created with the default template can drop its backend, which removes the database, the migrations and the PocketBase middleware, and switches the adapter to @sveltejs/adapter-static:

$ vela disable backend

vela enable backend adds it back.

Commands without a backend

Commands that need the database stop and say so, pointing at vela enable backend. A project has a backend when it has a data directory and depends on pocketbase-sveltekit or @velastack/pocketbase. These work without one:

  • vela dev, vela build and vela preview
  • vela ui, vela legal, vela routes and vela i18n
  • vela generate schema and vela generate form, and vela destroy for both
  • vela enable for ai, analytics, backend, blog, cms, content-negotiation and i18n
  • vela disable for ai, analytics, content-negotiation and i18n
  • vela cms, and the account commands: signup, login, logout and whoami
  • vela deploy, once the project uses adapter-node, and the server commands, such as provision, env, status and logs

Limitations

Form actions are not supported

Form actions need a server. Any generated form that posts back to +page.server.ts has to be replaced with a client-side submission to an external endpoint.

User authentication is not supported

Static builds do not support dynamic server-side rendering, so the auth module and its protected route group have nothing to run on.

No database at request time

Data can be read at build time and baked into the prerendered pages, but there is no database to query once the site is deployed.