CLI

The create-pluto command makes a new project from a template (or from scratch), installs the dependencies, and tells you how to start it. For the default setup, see the Quickstart: press Enter at each question.

Run the CLI

npm create pluto@latest

pnpm create pluto@latest

yarn create pluto

bun create pluto@latest

deno run -A npm:create-pluto@latest

The wizard

The wizard asks these things, in this order:

1. Project directory. The default is my-pluto-project. The CLI makes the directory if it does not exist.
2. Website title. The default is My Awesome Website.
3. Backend. Choose Git CMS (Markdown files in Git) or Supabase. With the Git CMS, the CLI also makes the project a Git repository: in development, each save in the admin is a commit in it.
4. Supabase values. Only for Supabase. See With Supabase.
5. Template. The list shows the starter templates that the backend allows, then Start from scratch.
6. Layers. Only for Dashboard only and Start from scratch. See Dashboard only.
7. Add SEO? Only for the blog. The default is yes. Yes adds the SEO add-on @plutocms/seo: the SEO fields of a post, the head tags, sitemap.xml, robots.txt and feed.xml.

After the download, the wizard asks one more thing: the package manager (npm, pnpm, yarn, bun or deno). The default is the one that runs the CLI.

The templates are in the templates repository. The CLI reads its list of templates, so a new template does not need a new version of the CLI.

Start from scratch

The CLI downloads nothing. It writes a Nuxt app that extends Pluto, with no pages of its own: package.json, nuxt.config.ts, app/app.vue, tsconfig.json, and .gitignore. It is a good start for an agent, or for a site that you write yourself. It works with both backends, and it can add layers, as Dashboard only does.

Dashboard only

This template has no public site. It is Pluto with the admin at /admin and the public API: a headless CMS to deploy, for a site in any stack. The home page redirects to /admin. See Use Pluto headless.

It works with both backends. The CLI sets the backend in it. With Supabase, the layer in nuxt.config.ts becomes @plutocms/supabase. Then the wizard asks which layers to add. You can select several:

The CLI adds each layer to extends in nuxt.config.ts and to package.json. Shop and Blog extend @plutocms/supabase themselves, so the app extends them in place of @plutocms/supabase. See Layers.

The blog is one template for both backends. The pages are the same. The CLI sets the backend in it: the layer in nuxt.config.ts (@plutocms/core or @plutocms/supabase-blog), the packages, the sample posts in content/ (Git CMS only), and the .env.

Then the CLI downloads the template and writes .env. The wizard asks for the package manager, and the CLI installs the dependencies. The name in package.json becomes the name of the project directory. At the end, it shows the next steps:

◇  Next steps
│  cd my-pluto-project
│  npm run dev
│
│  Then open /admin on the dev server.
│
│  Local Git publishing works in development only. To publish from a
│  deployed site, connect GitHub (Settings > GitHub).
└  Docs: https://pluto.vulmix.dev/docs/start-here/quickstart

The note about local Git shows only for the Git CMS. The dev command follows the package manager: pnpm run dev, bun run dev, deno task dev, and so on.

Before the download, the wizard checks two things. If nuxt.config.ts exists in the current directory, the wizard asks "Nuxt project detected. Do you want to add Pluto environment variables?". If the target directory is not empty, the wizard asks for confirmation.

You can cancel at any prompt.

Skip the prompts

npm create pluto@latest my-blog -t blog --backend git --pm pnpm
npm create pluto@latest my-cms -t dashboard --backend supabase --layers shop,3d
npm create pluto@latest my-app -t none --backend git

The Supabase shop works with Supabase only, so -t supabase-shop needs no --backend. The blog asks for the backend when --backend is not set. A template with a backend that it does not support (-t supabase-shop --backend git), an unknown name, or an unknown package manager stops the CLI: it prints the right names and exits with status 1.

In a script (no terminal), the CLI does not ask for the website title, the layers, SEO or the package manager. It uses the defaults: no layers, and the blog gets the SEO add-on. So create-pluto my-blog -t blog --backend git --pm bun runs with no question.

What the CLI writes

The CLI downloads the folder of the template from GitHub with giget, for example gh:plutocms/templates/templates/blog. The project gets that folder only: no workflow and no other file of the templates repository.

The CLI reads the list of templates from templates.json of the templates repository. Set PLUTO_TEMPLATES_URL to read another list (a URL or a local file). When the list does not load, the wizard offers Start from scratch only. With -t and a template id, the CLI stops with status 1.

Then it writes a .env file. If .env exists, the CLI merges the new values into it. Each value is quoted.

The CLI always writes the website title as NUXT_PUBLIC_WEBSITE_NAME.

With Supabase

The CLI asks for three values. It checks each one.

You need a Supabase project first. You can make one at database.new. Find the connection string in the Supabase dashboard: Project Settings, Database, Connection string. The pooler connection string also works.

With the Git CMS

The CLI asks nothing about GitHub. It writes NUXT_PLUTO_GITHUB_SESSION_PASSWORD, a random value with 43 characters.

You make the GitHub App later, from the admin of your site:

• On your machine, you need no App. The dev server signs you in as a local user and edits the files in content/.
• After a deploy, open /admin/login and select Create the GitHub App. See Deploy.

Local layers

A normal project uses the npm packages and needs no setup for local layers. The plutoLayer helper and PLUTO_LOCAL_ROOT are for people who work on Pluto itself. See Local layers.