> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. # Crave Cloud Overview > Build and test restaurant storefronts with a managed backend, Business Manager, and workspace billing. Crave Cloud hosts the restaurant backend behind Crave.js storefronts. Use the [Developer Console](https://developer.craveup.com/console) to manage your business workspace, projects, hosting subscription and customer-payment connection. Use each project's **Business Manager** to manage its restaurant and menus. > [!NOTE] > > Develop is for development and testing. Onboarding is currently assisted and > subject to available capacity. A working test installation does not activate > live restaurant payments or establish general self-service availability. ## Workspace and projects One workspace represents one merchant business. Its team, hosting billing and customer-payment connection belong to that workspace. A project is the restaurant application. Select its **Sandbox** or **Production** environment to open that environment's installation, Business Manager and storefront. The environments have separate data, URLs and payment bindings; changing the hosting plan must not turn test data into production data. Supported environments inherit the workspace's verified payment connection for the matching merchant and payment mode. An existing different account is not replaced silently. | Surface | Use it for | | - | - | | **Developer Console** | Projects, installation status, recent activity, customer payments, hosting subscription, invoices and workspace team access. | | **Business Manager** | Restaurant administration, menu editing and publication, and supported order operations. Open it from the intended project. | | **Storefront** | Customer-facing menus, cart, checkout and order confirmation for the installation. | | **Crave.js** | Storefront templates, SDKs and developer tooling for building a custom customer experience. Package and API versions must be compatible. | | **Restaurant OS desktop** | A separate staff frontend over the canonical backend, subject to its own installation and staff-auth configuration. | A ready backend, a published menu and payment readiness are separate states. Check each in the selected environment. When an installation includes a clearly labeled sample menu, replace its sample items with your own menu before sharing the storefront. Sample content and test orders are not live merchant activity. ## Sandbox and Production Use Sandbox for test orders and menu changes. Launch's intended package keeps a persistent shared Sandbox alongside a dedicated Production application service. The complete self-service upgrade is still undergoing acceptance; existing workspaces with duplicate hosting subscriptions require billing reconciliation. Do not buy a second base subscription to create a testing environment. Menu publication and code releases are different actions. Where publication is available, review the Sandbox menu changes before copying them to Production. Existing Production items removed from Sandbox are retained. Orders, customers and payment objects are not copied. A new hosting plan does not publish a menu, switch environment roles or activate live customer payments. ## Hosting plans | Plan | Monthly subscription | Application resources | Intended use | | - | - | - | - | | **Develop** | \$29 | Shared application resources with isolated restaurant installations | Development and test checkout; platform-managed upgrades. | | **Launch** | \$99 | A dedicated application service per restaurant | Arranged with Crave; live-payment activation and operational readiness are reviewed separately. | Each installation serves its canonical API, storefront and embedded Business Manager through one application origin. Develop projects share the application service; creating a project does not give it a separate Docker service or an independently selected image. Database and cache resources are separate from the application service. A dedicated application service does not imply dedicated database/cache resources or unlimited capacity. Confirm inclusions and limits with your hosting agreement. See [current pricing](https://developer.craveup.com/pricing). Crave's hosting subscription is separate from restaurant order payments. ## Customer payments Restaurants connect an eligible **merchant-owned Stripe account**. Crave does not take an order application fee under this hosting model. Stripe processing charges are separate from the Crave subscription. Sandbox permits test payments only. Production hosting can retain a test-mode connection while checkout is being verified; the Production label does not mean real money will be charged. Read the payment mode in the selected environment. Test payments do not produce live payouts, and paying for a hosting subscription does not enable live restaurant processing. Account eligibility and the canonical readiness checks determine whether payment is available. Workspace-first connection without an existing project is being completed; do not assume that a visible page or an existing connected workspace proves fresh account authorization is available in every environment. Follow the supported flow shown in your Console and [Stripe payment guidance](/docs/guides/integrations/stripe.md). ## Staff and customer identity Staff identity authorizes workspace and restaurant administration. Customer identity authorizes storefront customer actions; guest checkout capabilities are separate. Ordering never makes a guest a member of the merchant's staff workspace. Customer-authentication contracts are changing across release lanes. The selected API-owned successor uses server-side provider verification with tenant-scoped opaque application sessions. That source direction is not a claim that every hosted API or public SDK has activated it. Use the exact SDK/API pair approved for your environment; do not combine older token-provider examples with successor session methods or add an authentication fallback. ## Developer package compatibility Registry availability, source implementation and hosted support are separate. As checked on October 19, 2026: | Package | npm `latest` | npm `development` | | - | - | - | | `@craveup/storefront-sdk` | `2.0.1` | `4.0.0` | | `@craveup/commerce-contracts` | `1.0.0` | `4.0.0` | | `@craveup/cli` | `1.4.0` | — | > [!WARNING] > > Use the storefront included with your Cloud project for checkout. We have not > verified a published npm SDK for the current managed Cloud API. Do not connect > the 2.x checkout examples to a Cloud project or assume the `development` tag is > compatible. October 19 checks against the managed Sandbox release found: | Client | Verified result | | - | - | | SDK `2.0.1` | Merchant, location, ordering-readiness and menu reads succeeded. Its payment-intent route differs from the Cloud order-submission route; full checkout is not supported by this result. | | SDK `3.0.0` / contracts `2.0.0` | An empty cart session worked, but published menu and cart schema checks failed. | | SDK `3.1.0` / contracts `3.0.0` | Published menu and cart schema checks failed. | | SDK `4.0.0` / contracts `4.0.0` | An empty cart session worked, but published menu and cart schema checks failed. | | Included Cloud storefront | A TEST order reached customer confirmation and Business Manager Paid/Captured with zero due. This uses the client bundled with that runtime. | For a custom frontend, contact Crave for a release pair validated against your installation before implementing checkout or customer authentication. The [Storefront SDK guide](/docs/getting-started/storefront-sdk.md) describes the separate published 2.x API contract. A successful catalog request does not establish cart, checkout, authentication or loyalty compatibility. These checks do not promote an npm tag or establish compatibility with every Cloud release. ## Additional capabilities Ordering, identity, payments and loyalty have separate configuration and activation requirements. Loyalty includes implemented admission and lifecycle work, but enabled ordering does not automatically mean loyalty is enabled for a merchant. External loyalty, POS and payment providers require their specific integration and readiness checks; vendor names are not prebuilt connector promises. Workspace automation keys, external-app Connections, Add-ons, true resource metering and automated Launch deployment are not part of the supported Develop self-service promise. Activity describes project events, not resource usage or metered spend. Public demos and template previews are presentation/test content. For package licensing and deployment responsibilities, see [Developer Package and Crave Cloud](/docs/guides/open-source-and-cloud.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.