create-solana-dapp is a template fetcher with a policy for renaming your project

The tool fetches a template, it does not contain the app

The first thing to understand is what the CLI actually is. The README describes it as a CLI that automates the initialization of predefined Solana templates, and the official create-solana-dapp templates live in a separate repository, solana-foundation/templates. The project description points readers at that templates repository as well. So the division of labour is clean. The templates hold the application code, the framework choices and the example content, while this package holds the machinery for fetching, customising and installing. That split has a practical consequence for anyone evaluating it. The generated application is only as good as the template behind it, and the template is a moving target that this CLI does not pin for you unless the template itself asks for a version. If what you need is a particular stack, a particular frontend framework or a particular Anchor setup, the question to ask is which template provides it, not whether this CLI is good.

One command works across four package managers

The generation command is short enough to be the whole quick start, and it is published under the same name for npm, pnpm, bun and yarn:

npm create solana-dapp@latest

The pnpm form is pnpm create solana-dapp@latest, bun has bun create solana-dapp@latest, and the yarn form is yarn create solana-dapp, which the README notes supports only the latest tag. The four variants are not decoration. The tool has a strong opinion about which package manager a project should use, and the init script can pin it. A template can declare a packageManager field, and an explicitly selected different package manager will stop the installation, so the choice a template author makes is enforced rather than merely suggested. The package metadata shows the same intent elsewhere: the tool itself requires node 22.12.0 or newer, is marked sideEffects false and type module, and ships both ESM and CommonJS entries with a bin mapping for create-solana-dapp.

External templates are pulled by GitHub organisation and repository

The template flag is the interesting extension point, and it is not limited to the official set. The --template flag, or -t, supports anything that giget supports, so a project can be generated from a template hosted anywhere on GitHub by giving an organisation and repository:

npm create solana-dapp@latest -t <github-org>/<github-repo>

The pnpm and yarn forms take the same flag. This is what turns the tool from a one-off scaffolder into a shared convention. If your organisation keeps its own template repository with your house conventions, your security defaults and your preferred client library, every developer can generate from it with a single flag and get the same starting point. The templates are fetched rather than embedded, so the tool stays small and the template is the artefact you version. The upstream dependency on giget is the mechanism, and the tool is essentially a policy layer on top of it.

The init script runs before dependencies install, and a failure deletes the project

Template authors control the install through a create-solana-dapp block in their package.json, and the execution order is specified precisely. A script can return instructions to the user, check the anchor and solana versions, and replace text and files in the project. When a script declares a run value naming a script in the template's package.json, optionally followed by arguments, it runs with the selected package manager after the template is cloned and before dependencies are installed. The stated reason is that a script that trims package.json is reflected in the lockfile and node_modules, and any files it writes are still picked up by the rename step. Two constraints follow. The script must not prompt, because it runs without an interactive terminal. And a non-zero exit aborts the run and removes the target directory, so a broken init script leaves nothing behind rather than a half-built project. The value of the run argument is also restricted to letters, digits, whitespace and . : @ / = , + - _ , with shell metacharacters rejected rather than escaped, which means an argument cannot contain a space and anything needing quoting has to live in the script itself.

Version checks and option groups are both declared by the template

The versions block in the template configuration is a small but useful feature. A template can declare minimum or expected versions of tools such as anchor, solana or adb, and the tool checks them and gives a warning if the tool is not installed or the installed version is lower. For a Solana project that means the failure mode of a confusing Anchor build error becomes a message at project creation, which is a better time to find out. The same block also carries the skills setting, which is optional and lets a template skip skill installation entirely by setting it to an empty list, or replace the default Solana skill with one or more skill repository URLs. The options block is the third piece, and it is where template specific boolean flags are declared, grouped so that only one option from a group can be active at a time. The options mechanism is the most demanding part of the template contract, and it exists to solve a real problem. A template can declare boolean long flags, and when no flag is passed for an option group, the group's default option is selected. Passing another option from that same group replaces the default. The documentation's example has an ollama option marked as the default in a group called engine, and a llamacpp option in the same group, so choosing one means the other is not used. The options can carry their own instructions and their own rename maps, so the flag does more than select a variant. The invocation with a template-defined option looks like this:

pnpm create solana-dapp@latest my-inference-app \
  --template pay-gate-inference \
  --ollama

A second group covers example code, where a reset-project option runs the template's own reset-project script, and the documentation gives its instruction as editing app/index.tsx to start building. The result is that the CLI can present a coherent set of choices rather than a wall of flags.

Renaming is a map of terms applied across the project tree

The rename block is what keeps a generated project from being full of the template author's placeholder names. It is a map of terms to rename, and each term has an in list of paths and a to value. In the documentation's example, counter is renamed across the anchor and src directories, with the replacement being the project name, so the name is templated. A term can also be a fixed string rather than the project name, and the options block uses that to swap a model placeholder such as __MODEL__ for a specific value like qwen3:0.6b in request.json. This is a text and file substitution pass over the cloned template, and it is why the init script's run step is ordered before the rename: anything the script writes is still eligible to be renamed. The deprecated name for the paths key is called out in a comment, since it was called paths and will be removed in the next major version.

The repository is a pnpm workspace with a Dockerfile that mirrors the CLI

The engineering side of the repository is conventional. The top level holds a src/ directory for the CLI source, a test/ directory, __mocks__/ for the test doubles, a .changeset/ directory for release notes, a Dockerfile, a csd.sh script, a lefthook.yml for git hooks, an eslint config, and a vitest.config.ts, with pnpm-lock.yaml and pnpm-workspace.yaml for the workspace. The package metadata shows the build is done with unbuild, the tests run through vitest with coverage, and there is a separate type check with tsc --noEmit --skipLibCheck, so the test script runs lint, type check and the suite together. The Dockerfile is a small Alpine image on node:22-alpine that installs bash and git, enables corepack with pnpm@latest-10, installs the workspace with a frozen lockfile, and copies csd.sh into /usr/local/bin/csd. Its entrypoint is bash with the command wired to the built CLI, so the container is a way to run the generator in a reproducible environment. The version in the metadata is 4.8.5, the licence is MIT, and the repository is not archived with the last push on 2026-10-13.

Where create-solana-dapp is the wrong choice

Three situations argue against it. The first is a team that has already chosen its stack and wants a starting codebase to copy. The tool is a fetcher with a customisation layer, so a project that will diverge from the template immediately is paying for a mechanism it will not use. In that case a repository you own and control is simpler and clearer. The second is a project that needs guaranteed reproducibility. The templates are fetched from GitHub at their current state unless the template itself pins a version, and the version block in the configuration is described as a check with a warning, not as a lock, so the generated project is a moving target by default. A team with a compliance requirement around exactly what enters its build needs to control that reference itself. The third is a project that is not a Solana application at all. The naming makes the audience obvious, and the templates, the version checks and the skills default are all Solana specific. The honest alternative for a general starter is a scaffolding tool with no ecosystem opinions, or a generator you write for your own organisation. This one earns its place when you want the official template set and the option and rename conventions, not when you want an application skeleton.

Editorial conclusion

Adopt create-solana-dapp when you are starting a Solana application and want a template you can point at, a fixed package manager and a project name substituted consistently, and build the app yourself if you need a specific stack today. Skip it if you want a generator that ships the application code, because this tool only fetches and customises templates. Verify first which template you are pulling and what its init script does, since that script runs before dependencies are installed and a non-zero exit removes the target directory.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. solana-foundation/create-solana-dapp on GitHub