- What is statamic/cli and is it a runtime Laravel package?
- statamic/cli is the official command-line installer for Statamic, the Laravel-based content management system. It is not a runtime Laravel package: it is a globally installed developer CLI that scaffolds a new Statamic project, wires up configuration, and exits before your application ever boots. It adds no service providers, config contracts, or runtime surface to production.
- How do I install the Statamic CLI tool?
- Install it globally with composer global require statamic/cli, or run it on demand without a global install using cpx statamic/cli. The cpx approach is explicitly recommended by the project and keeps your machine clean. Either way the tool lives outside your application's composer.json.
- Do I need to add statamic/cli to my composer.json?
- No. Because it is installed globally or invoked through cpx, it never appears in an application's composer.json and therefore never accrues dependents. Zero dependents on Packagist is structural for this kind of tool, not a sign of poor health. The meaningful health signal is that it is first-party tooling maintained by the same organisation that ships Statamic.
- Which PHP version does statamic/cli require?
- The CLI has its own PHP floor and dependency constraints, which are bumped independently of Statamic itself. Recent dependency and minimum-PHP changes are the main upgrade risk, and a mismatch typically surfaces as an opaque Composer dependency-resolution error during scaffolding. Check the current requirement on Packagist and confirm the concrete floors before rolling it out across devcontainers, CI runners, and Docker base images.
- Can I run statamic/cli in CI or a non-interactive shell?
- It can run non-interactively, but you must handle the license-key prompt: in a non-TTY or scripted context an interactive prompt can hang rather than fail fast, turning a clean error into a CI timeout. Confirm whether the prompt degrades gracefully in your environment and whether a documented flag or environment variable supplies the key. Treat this as a gating item for all scripted provisioning.
- How do I pass a Statamic license key non-interactively?
- The CLI prompts for a license key during setup, so scripted installs need a supported non-interactive path such as a command flag or environment variable. Verify that path against the current release before wiring it into automation, since an unsupported prompt in a non-TTY shell will block rather than fail. This is one of the two items that gate CI adoption.
- Does statamic/cli work with plain Laravel or only Statamic?
- It is only useful if you are standardising on Statamic. For plain Laravel or non-Statamic stacks the tool is inert and adds nothing to your workflow. If you already maintain an internal scaffolding template, the better pattern is to consume this CLI as an inner layer beneath an organisation-specific wrapper rather than let it fork your golden path.
- How should I test or assert on statamic/cli behaviour?
- Never assert on human-readable CLI output: the human-facing formatting changes regularly and will break log scraping, snapshot assertions, and screenshot-based runbooks. Instead pin the CLI version, assert on exit codes, and check the generated filesystem state. Keep the tool out of your application test suite entirely, since it runs before a project exists.
- Is the statamic/cli version tied to the Statamic version it scaffolds?
- That coupling is not documented plainly and is worth resolving before you pin. If one CLI release can only scaffold a matching Statamic release, then pinning the CLI also pins which Statamic versions you may adopt. Check the release notes and test a scaffold against your target Statamic version.
- Is statamic/cli actively maintained and safe to adopt?
- It is first-party, vendor-maintained tooling shipped by the Statamic organisation, which is the right health proxy for a bootstrap CLI rather than star count or dependents. Recent releases cover dependency bumps, output changes, and prompt behaviour, so review the changelog before pinning. Also verify release tags against Packagist and the GitHub release feed, since a future-dated release suggests a registry or mirroring inconsistency worth resolving at adoption time.