A Misaki Studio boilerplate supplies the application, packaging, backend, or hosting shell around generated project output. It is useful when you want a prepared destination; it is not required when your existing application already provides that shell.
Misaki Studio currently maintains five standalone boilerplate repositories. Their public readiness is not identical.
Boilerplate: misaki-studio-website · Use it for: A general Next.js static-site shell you can run or self-host. · Current public status: Early starter. Public main has no README and pins an older Misaki runtime; verify and update dependencies before adoption.
Boilerplate: misaki-studio-npm · Use it for: Building exported modules into an installable package. · Current public status: Advanced/unfinished starter. Public main contains project-specific generated package metadata and no empty src/; registry, package identity, entry points, and loader dependencies require review.
Boilerplate: misaki-studio-backend · Use it for: Running generated database/auth behavior on Node.js, Express, and Postgres. · Current public status: Not ready for production use. Its public README says the SQL action engine is not built, so real action reads/writes throw.
Boilerplate: misaki-studio-cloudflare · Use it for: Building and deploying a static exported site to Cloudflare Workers assets. · Current public status: Documented static-site target. Does not host a generated database backend.
Boilerplate: misaki-studio-vercel · Use it for: Building and deploying a static exported site to Vercel. · Current public status: Documented static-site target. Does not host a generated database backend.
Repository reachability and public main content were verified on 2026-09-09. Recheck the repository's README, package.json, and latest commit before publishing version-specific commands.
Start with the Website boilerplate. It is the smallest generic Next.js shell, but it currently needs manual dependency review and has less user guidance than the provider-specific starters.
Choose the Cloudflare boilerplate or Vercel boilerplate. Both use a Next.js static export and keep provider configuration outside the generated src/ and public/ trees.
Read the npm-package boilerplate. Treat its current public repository as a packaging example requiring cleanup, not a neutral one-click starter.
Read the Backend boilerplate, but do not deploy its public current state for real reads or writes. The static Cloudflare and Vercel targets explicitly do not host it yet.
Publish Website uses Misaki Studio's hosted publishing workflow.
A hosting boilerplate writes generated output into a repository you own and uses that repository's build/deploy scripts and cloud account.
Publish NPM uses the configured package-publishing workflow.
The npm boilerplate is the shell and build configuration around output you want to package yourself.
Choose based on ownership and deployment requirements, not only on the shortest command.
For the website, Cloudflare, and Vercel frontend shells:
REACT SRC PATH → <clone>/src
ASSET PATH → <clone>/public
Leave NODEJS SRC PATH empty for a frontend-only/static deployment. A backend path requests a separate generated backend artifact and must point to a compatible shell.
Coverage: UI + MCP for local export settings; deployment remains provider/CLI work.
Inspect my project and the chosen boilerplate clone. Read
settings/export, the clone's README,package.json, and generated-folder boundary. Propose the exact React source, asset, and optional backend paths. Do not add a target, export, install packages, publish, or deploy until I approve the plan.
After approval, an agent can configure a local target and run the whole-project local export. It should then show the target diff and run the boilerplate's documented checks. Cloud provider authentication and deployment are separate external actions requiring explicit approval.
Configure the local or Git target only after the clone and generated-directory boundary have been verified.