Skip to main content

​
Overview

When building a website or app, it’s important to have safe spaces to experiment without affecting what your real users see. Think of it like having a practice kitchen where you can try new recipes before serving them in your restaurant. Stardeck gives you three separate environments:
Managed Sandbox, Preview, and Production data are separate by default. Connected data stores use branch routing — each runtime maps to a branch, and if two runtimes are intentionally mapped to the same branch, they share that branch’s data. Ordinary previews do not use production data unless you explicitly override the mapping.

​
The Three Environments

​
Sandbox

The sandbox is your personal development space where you build and test your application. What makes it special:
  • Changes appear instantly as you work
  • Safe to experiment—nothing here affects your live site
  • Perfect for trying new features or fixing bugs
  • Your sandbox runs only when you’re actively working
When to use it:
  • Building new features
  • Testing changes before sharing with others
  • Debugging issues
  • Experimenting with ideas

​
Preview

Preview deployments let you share a working version of your changes before making them live. What makes it special:
  • Creates a real, working version of your site that anyone can visit
  • Each preview has its own shareable URL
  • Great for getting feedback from clients or stakeholders
  • Behaves like production but with test data
When to use it:
  • Getting client approval before launch
  • Sharing progress with stakeholders
  • Testing with a wider group before going live
  • Quality assurance and review
Creating a Preview:
  1. Make your changes in the sandbox
  2. Deploy a preview from the Stardeck dashboard
  3. Share the preview URL with anyone who needs to review it

​
Production

Production is your live site—the version that real users see and interact with. What makes it special:
  • Accessible to everyone at your app URL
  • Uses real data and real user accounts
  • Automatically secured with SSL
  • Globally distributed for fast loading
When to use it:
  • Launching your finished work
  • Serving real customers
  • Running your actual business

​
Understanding Data Separation

This is one of the most important concepts to understand: managed Sandbox, Preview, and Production data are separate by default. Connected data stores use branch routing: each runtime (sandbox, preview, production) maps to a store branch. Different branches hold different data. If two runtimes are intentionally mapped to the same branch, they share that branch’s data — including production when a runtime is mapped to a production branch.

​
What This Means

Imagine you have a store. In sandbox, you might create a test product called “Sample Widget” and a test user called “Test Customer.” Here’s what happens with the default separate mappings: Nothing you create in sandbox automatically appears in preview or production. Each environment starts empty and only contains the data you specifically create there — unless you explicitly map runtimes to the same data-store branch.

​
Experimental Workspaces

Some organizations have access to Workspaces (labeled Experimental in the dashboard). A workspace preview can use the Environment panel to manually point a connected data store at a production-mapped branch. That preview then reads and writes live production data. Cross-app routing in a workspace may also fall back or be pinned to Production; that production destination is read-only. These are explicit overrides, not automatic leakage. Ordinary app previews and the default workspace auto mappings do not use production data.
Only map a workspace preview to a production data-store branch when you intentionally need live production data. Confirm the dashboard warning before saving — the preview will read and write that production branch.

​
Why This Is Actually Good

This separation is a feature, not a limitation:
  • Safe testing: Create fake users, fake orders, and fake content without cluttering your real data
  • No accidents: You can’t accidentally delete real customer data while testing (when using default separate mappings)
  • Clean production: Your live site only has real data, not test entries
  • Honest testing: You see exactly what new users will experience
If you create test users or test data in sandbox, those accounts won’t work in production. You’ll need to create real accounts in production for actual users.

​
Seeding Data in Different Environments

Since environments use separate data by default, you may need to populate them with initial data. Starcat Developer can help you set this up.

​
Option 1: Database Migration (All Environments)

If you need the same seed data in every environment (sandbox, preview, and production), ask the agent to create a database migration that inserts the data. Migrations run automatically when each environment starts. Example prompt:
“Create a migration that seeds the database with default product categories: Electronics, Clothing, Home & Garden, and Sports.”
This approach is ideal for:
  • Default configuration data
  • Required lookup tables
  • Initial content that every environment needs

​
Option 2: Seed Button (Specific Environment)

If you only want seed data in certain environments—like demo data for previews or initial setup for production—ask the agent to create a hidden seed button in your app. Example prompt:
“Add a seed data button to the admin dashboard that creates sample products and test customers. Hide it so only admins can see it.”
This approach is ideal for:
  • Demo data for client previews
  • One-time production setup (like creating an admin account)
  • Test scenarios you want to trigger manually
For production, consider creating the seed button, using it once to set up initial data, then asking the agent to remove it. This keeps your production app clean while still giving you a way to populate initial data.

​
Common Scenarios

​
”I created a test user but can’t log in on my live site”

Why this happens: The user account you created exists only in the environment where you created it. If you signed up in sandbox, that account only exists in sandbox. Solution: Create a new account in production (your live site). This is actually the correct behavior—you don’t want test accounts mixed with real customer accounts.

​
”I added products in sandbox but they’re not showing in production”

Why this happens: Products, content, and all data are environment-specific. Your sandbox has its own database, separate from production. Solution: Add the products to production when you’re ready to sell them. Many teams do this by:
  1. Testing the product setup in sandbox first
  2. Re-creating the products in production once everything looks right

​
”My client can’t see the changes I made”

Why this happens: Your sandbox is only visible to you. Clients can’t access your development environment. Solution: Deploy a preview and share that URL with your client. Preview deployments are real, accessible websites that anyone can visit.

​
”I made changes but my live site looks the same”

Why this happens: Changes in sandbox don’t automatically publish to production. Solution: When you’re ready, publish your changes to production from the dashboard. See Publishing & Deployment for details.

​
Best Practices

​
For Development (Sandbox)

  • Use test data that’s clearly fake (e.g., “Test User” instead of real names)
  • Experiment freely—that’s what sandbox is for
  • Test edge cases and error scenarios here

​
For Review (Preview)

  • Deploy previews when you want feedback
  • Share preview URLs instead of describing changes
  • Create realistic test scenarios for stakeholders to try

​
For Launch (Production)

  • Only publish when you’re confident in your changes
  • Set up real data and real user accounts
  • Monitor for issues after publishing

​
FAQ

Q: Can I copy data from sandbox to production? A: Not automatically. Environments are intentionally separate by default. However, you can ask Starcat Developer to help you seed data—either through a migration (for all environments) or a seed button (for specific environments). See Seeding Data in Different Environments above. Connected data stores can share a branch if you intentionally map two runtimes to the same branch — see Understanding Data Separation. Q: How do I know which environment I’m looking at? A: In the Stardeck dashboard, the environment is clearly indicated. Your live production site is at your app URL (e.g., your-app.stardeck.site), while preview deployments have unique URLs. Q: Do environment variables work the same in all environments? A: Environment variables can be configured separately for each environment. This lets you use test API keys in sandbox and real ones in production. See Environment Variables for details. Q: What happens to preview deployments over time? A: Preview deployments remain accessible at their URLs. You can manage and remove old previews from your dashboard. Q: Can multiple team members work in sandbox at the same time? A: Each team member has their own sandbox environment for development. Changes are synchronized through your app’s version control.
Understanding environments helps you work confidently—experiment freely in sandbox, get feedback with previews, and publish to production when you’re ready.