Skip to main content
Crave Cloud hosts the restaurant backend behind Crave.js storefronts. Use the Developer 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.
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. 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

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. 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.

​
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 18, 2026:
These tags are a dated registry observation, not a compatibility recommendation. Older SDK methods and newer API routes can differ. Confirm the exact package versions, supported operations and deployed API before following checkout or customer-authentication examples. Do not substitute the newest tag, an unpublished source checkout or a private transport to bypass an unsupported integration.
Start with the Storefront SDK guide and upgrade guidance, then confirm the supported release with Crave. Documentation examples are being reconciled across those release lanes.

​
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.