No. A boilerplate is a prepared application, packaging, backend, or hosting shell. You can instead inspect generated code, export into an existing application, configure another local folder, or use a Git target. Choose the output that matches the result you need.
For the complete generation model, read How export works, Export your code, and Understand generated output.
Misaki Studio currently maintains five: Website, npm package, backend, Cloudflare, and Vercel. They do different jobs and are not equally ready for use. Compare their purpose and current status.
None should be treated as an unreviewed one-click production launch. The Cloudflare and Vercel repositories have documented static-site build and deployment routes, but you must still verify the generated diff, dependency installation, provider account, environment variables, preview, and destination. The Website starter needs dependency and script review. The npm starter is unfinished for general use. The public backend starter explicitly says its SQL action engine is not built.
Use built-in Publish Website when you want Misaki Studio's hosted website workflow. Use Publish NPM when you want its package-publication workflow. Choose a boilerplate when you want the generated files, build configuration, provider account, and deployment lifecycle in a repository you control.
These routes can have similar names but different authentication, side effects, and recovery. Inspect first and approve the exact destination before publishing.
Not through the current static-site boilerplates. Both export Next.js as static files and deploy the resulting frontend assets. Leave NODEJS SRC PATH empty for those targets. A generated Node.js/Express backend needs a separate compatible host and a verified backend workflow.
Editor label: REACT SRC PATH · MCP/stored field: path · Output: Generated frontend source.
Editor label: ASSET PATH · MCP/stored field: asset · Output: Images, fonts, and other media.
Editor label: NODEJS SRC PATH · MCP/stored field: backendPath · Output: Optional generated Node.js/Express backend; empty means no backend output.
For the Website, Cloudflare, and Vercel shells, the usual frontend destination is <clone>/src plus <clone>/public.
Yes. export-code-to-folder writes the whole project's generated output to every configured local-folder target, not only the file you were viewing. Hand edits inside generated output are not preserved reliably. Snapshot the target, search for files marked HAND EDIT (not produced by the exporter), run the export, and inspect the complete diff.
Use the complete re-export checklist.
Partially, depending on the destination. Production MCP tools can read, add, update, and remove local or Git target settings, and can run the whole-project local-folder export. A Git push, registry publication, hosted-site publication, provider login, and cloud deployment are separate external actions and require destination-specific review and explicit approval.
Treat the current raw get-export result as sensitive. If a Git token is configured, the tool includes it in its text output. Do not paste that response into documentation, issues, or shared transcripts. Ask the agent for a redacted summary or inspect non-secret values in the editor.
Read the complete local and Git target guide.
No. Public main currently contains one project's package identity and generated export maps, has no neutral src/, references an undeclared loader, and maps package entry points to filenames that do not match the current webpack output name. Its declaration-file configuration is also incomplete. Read the npm-package boilerplate limitations.
Not in its current public state. Its README says the SQL action engine is not built and real action reads/writes throw. Treat it as scaffolding for evaluation until a current guide verifies the missing runtime behavior. Read the backend boilerplate status.
The configured source, asset, and optional backend paths point to the intended clone.
The diff contains only understood generated changes.
No credential or local environment value entered the repository.
Dependency installation completes from a clean state.
The repository's typecheck, tests, build, and local preview pass.
The actual production artifact contains the expected routes, assets, and package entry points.
Deployment or publication still waits for approval after the destination and artifact are known.