> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# CLI Quickstart

> Use Crave CLI 1.x to inspect and configure a pinned legacy storefront example.

The Crave CLI 1.x clones a current public storefront example, writes its public environment settings, installs dependencies, and can start the local development server. It is a fast way to inspect the existing integration shape, not a substitute for production review.

> [!NOTE]
>
> The CLI publishes as **`@craveup/cli`**. The older unscoped `craveup` package
> on npm is unmaintained and stops at 1.0.3 — install the scoped name. The
> installed command is still `craveup`, so `craveup login` and the rest are
> unchanged.

> [!WARNING]
>
> The three current CLI 1.x choices are legacy public examples pinned to fixed
> Git commits for reproducibility. They predate the production-proven web and
> Expo generator releases now being validated. Review and migrate dependencies,
> browser security, exact origins, and the complete sandbox ordering flow before
> deploying one. For a new implementation, treat the published Storefront API
> and SDK guides as the current contract.

## Install & run

Run the CLI anywhere you want to create the project directory:

```bash theme={null}
npx @craveup/cli init
```

The wizard will guide you through:

* Choosing a legacy public example (`storefront-default`, Tomodachi Sushi, or Xichuan Noodles)
* Selecting the published organization and location
* Naming the project directory
* Installing dependencies with your detected package manager
* Optionally starting `pnpm dev` so you can preview immediately

## Sign in

Sign in before scaffolding so the CLI can discover the organizations and locations your account can manage:

```bash theme={null}
npx @craveup/cli login    # browser OAuth; sign in or create a free account
npx @craveup/cli whoami   # confirm the active account
npx @craveup/cli logout   # remove local credentials
```

The session is stored in the macOS keychain, falling back to `~/.config/craveup/credentials.json`, and is **shared with the [CraveUp MCP server](/docs/guides/ai/craveup-mcp-server.md)** — signing in through either one satisfies the other. On a headless or remote machine, use `craveup login --device` to pair with a code you open on any other device.

## Non-interactive usage

Prefer automation or CI pipelines? Use flags to skip prompts.

| Flag | Description |
| - | - |
| `--template <id>` | Force a template (`storefront-default`, `tomodachi-sushi`, or `xichuan-noodles`) |
| `--dir <name>` | Set the target directory name |
| `--api-key <key>` | Optional server-only CLI credential for non-interactive private API access |
| `--location-id <id>` | Provide the location ID for single-location templates |
| `--org-slug <slug>` | Provide the organization slug for organization templates |
| `--skip-install` | Scaffold files without running the package manager |
| `--force` | Overwrite an empty directory without confirmation |

Example:

```bash theme={null}
npx @craveup/cli init \
  --template storefront-default \
  --dir crave-storefront \
  --org-slug my-restaurant-group \
  --skip-install
```

## Environment variables

The CLI creates or updates `.env.local` with public storefront settings:

```env theme={null}
# Public Storefront API origin. No browser API key is used.
NEXT_PUBLIC_CRAVEUP_API_URL=https://api.craveup.com
NEXT_PUBLIC_CRAVEUP_LOCATION_ID=loc_abc123
NEXT_PUBLIC_CRAVEUP_MERCHANT_SLUG=my-restaurant-group
```

> Tip: `CRAVEUP_DASHBOARD_URL`, `CRAVEUP_PARTNER_API_URL`, and a private `CRAVEUP_API_KEY` are CLI/server concerns. They are never written to a public storefront environment variable.

The merchant and location variables are standalone/local overrides. A hosted
`cravejs-storefront-template` resolves the merchant from its controlled
host/subdomain and the location from the `[locationId]` route instead of
duplicating tenant selection in production environment variables. The CLI does
not write `NEXT_PUBLIC_STOREFRONT_URL`; the template derives its canonical
metadata origin from the request host. Add that optional override manually only
when the deployed metadata origin must differ from the request host.

## Example anatomy and production boundary

The current examples do not share one guaranteed framework or dependency baseline.
Inspect the generated `package.json` and lockfile before changing the project.
Do not assume that a CLI 1.x example already contains Next.js 16.3,
`@craveup/storefront-sdk@2.0.1`, the current component structure, or the complete
browser-security contract.

For new production implementation, start with the exact-pinned
[Storefront SDK guide](/docs/getting-started/storefront-sdk.md) and the relevant web or mobile quickstart,
then validate the sandbox vertical slice before release.

Explore the generated repository after the CLI finishes:

```bash theme={null}
cd crave-storefront
pnpm install # if you skipped installation
pnpm dev --port 3000
```

You now have the selected example running locally. Continue to the [Storefront SDK guide](/docs/getting-started/storefront-sdk.md) to build against the current public contract and review the [deployment boundary](/docs/guides/deployment.md) before accepting traffic.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.