Skip to main content

Environment

Environments are distinct instances of your Brand's backend. They are a critical tool for safe development, testing, and deployment, ensuring that changes to your menu or settings do not disrupt live customer orders.

Each Brand can have a single Production environment and multiple Sandbox environments.

Production vs. Sandbox​

There is a fundamental difference between the live environment and a testing sandbox.

Production Environment​

  • This is your live restaurant. It processes real customer orders, takes real payments, and sends tickets to the kitchen.
  • High Performance: It has no artificial limits on API requests, orders, or menu items.
  • High Reliability: Changes are made carefully, usually after being tested in a Staging environment.
  • Automatic Backups: The Production environment database is automatically snapshotted daily, with snapshots retained for 7 days to ensure data integrity and disaster recovery.

Sandbox Environment​

  • This is your testing playground. It can be a Staging environment for managers or a Development environment for programmers.
  • Resource Limits: Sandboxes have reasonable limits on usage (e.g., API requests per minute, number of orders) to ensure fair use. These limits are visible in the console.
  • Isolated: A Sandbox is completely separate from Production. You can test new menus, experiment with pricing, and train staff without any risk to your live operations.
  • Own API URL: Each Environment, including every Sandbox, has its own unique API URL. This allows front-end applications (like a Kiosk app) to be pointed at the Staging environment for testing.

Sandbox Lifecycle Management​

Understanding how Sandboxes are managed helps you plan your development workflows:

  • Automatic Deletion: Unused Sandboxes are automatically deleted after 30 days of inactivity to optimize resource usage
  • Inactivity Definition: No API calls, menu updates, console access, or any data modifications during the period
  • Deletion Warnings: Email notifications are sent 7 days and 1 day before scheduled deletion
  • Final Snapshot: An automatic snapshot is created before deletion and retained for 7 days for recovery
  • Reactivation: Simply accessing or using a Sandbox resets the inactivity timer

Core Features of Environment Management​

Snapshots​

A Snapshot is a complete copy of an environment's database at a specific point in time. This is a powerful feature for safe and productive workflows.

  • Use Cases:
    • Staging: Create a snapshot of your Production data and restore it to a Staging sandbox. This allows you to test a new promotion with your real menu and product data.
    • Development: Provide developers with a realistic dataset to build and test new features.
    • Reverting Changes: If a major error is made during a menu update in a Sandbox, you can simply revert to a previous snapshot.
  • Restoring Deleted Environments: If a Sandbox is automatically deleted due to inactivity, a final snapshot is created. You can restore the environment from this snapshot within 7 days.

Snapshot Best Practices​

Effective snapshot management improves your development and testing workflows:

  • Naming Convention: Use descriptive names like "pre-holiday-menu-2025-07-15" or "before-modifier-group-changes"
  • Scheduling Strategy: Consider creating snapshots before major changes or on a regular schedule for critical environments
  • Storage Limits: Each environment can maintain up to 10 snapshots; older snapshots are automatically deleted when limit is reached
  • Restoration Time: Typically completes within 5-10 minutes for standard databases, depending on data size
  • Documentation: Keep notes about what each snapshot contains for easier future reference

Common Development Workflows​

  1. Create snapshot of Production environment with current live data
  2. Restore snapshot to Staging environment for realistic testing
  3. Test menu changes, pricing updates, or new features in Staging
  4. Verify changes work correctly with real data patterns
  5. Deploy tested changes to Production during planned maintenance window

Feature Development Workflow​

  1. Developer uses Development environment with sample data for initial coding
  2. QA testing performed in Staging environment with Production data snapshot
  3. User acceptance testing conducted in dedicated UAT environment
  4. Approved features deployed to Production following change management process

Emergency Recovery Workflow​

  1. Identify issue in Production environment
  2. Quickly create snapshot of current state for analysis
  3. Restore previous known-good snapshot to recover service
  4. Investigate issue in separate environment using problematic snapshot
  5. Implement fix and test before applying to Production

Version Upgrades​

The FNBNext platform is constantly evolving. Environments allow for safe, on-demand version upgrades.

  • Independent Versions: Each Environment's version can be managed independently. This allows you to test a new FNBNext version in your Staging environment to ensure it's compatible with your customizations before upgrading your Production environment.
  • Zero Downtime: Upgrades are designed to be seamless and do not require downtime for your live restaurant operations.

Access & Subdomain Management​

  • API Access: Each Environment has its own access control settings, allowing you to restrict which front-end applications can connect to it.
  • Subdomains: The subdomain for each environment (e.g., my-brand-staging.fnbnext.io) can be managed directly from the console.

Understanding how your Menu System works across environments is crucial for safe operations:

  • Environment Isolation: Each environment maintains its own complete copy of menu data including Master Products, Menu Items, Modifier Groups, and Collections
  • Manual Promotion: Changes must be manually applied to each environment - there's no automatic sync between Staging and Production
  • Testing Safety: You can completely restructure your menu in Staging without any impact on live customer orders
  • Data Consistency: Use snapshots to ensure your testing environment reflects current Production menu structure
  • Change Validation: Always test menu changes in Staging before applying to Production to avoid customer-facing issues
  • Organization - The top-level entity that owns this Brand and its environments
  • Brand - The restaurant concept that contains these environments
  • Menu System - The menu architecture that exists within each environment
  • Location - Physical locations that connect to specific environments