Staging vs. Production

Insites uses separate environments to keep development and testing safely isolated from your live application. Staging instances have an address that ends in , and production instances an address that ends in . Understanding how staging and production instances differ helps you build a workflow that minimizes risk and keeps your users happy.

Staging Environments

A staging instance is your testing ground. It mirrors production in terms of infrastructure and configuration, but it is not accessible to end users. Use staging for building features, testing workflows, presenting changes to clients, running QA, or conducting user acceptance testing (UAT).

Key characteristics:

• Isolated from production - Bugs and incomplete features on staging do not affect your live users.
• Realistic testing - Staging uses the same infrastructure, databases, and integrations as production, so your tests reflect real-world behavior.
• Email suppression - All outbound emails on staging instances are suppressed by default. Any email that would normally be sent to a user is instead delivered only to your configured test email list, with the intended recipient shown in the email subject line. This lets you test with realistic data without accidentally emailing real users.
• API notifications off by default - API call notifications are disabled on staging to prevent triggering third-party integrations during testing.
• No custom domains - Staging instances cannot have custom domain names attached. They are served from their system domain only, and they send email from [email protected].
• Hidden from search engines - Every page on a staging instance is sent with the header , so search engines do not list staging pages. This applies to every staging instance and cannot be turned off. Staging is for building and testing, not for running a live site. When your site is ready for visitors, move it to a production instance.

Production Environments

Your production instance is the live application that end users interact with. It requires careful management to ensure high availability, performance, and data integrity.

Key characteristics:

• Live and public - Production serves real users and handles real data. Issues here directly affect user experience.
• Custom domains - Production instances support custom domain names with SSL. Connect a domain from the Domains section of the instance in the Console. See Instance Domains.
• Email from your own domain - A production instance can send from [email protected], or from an address at a connected domain whose email notifications are live. See Sending Email from Your Own Domain.
• Visible to search engines - A production instance serves only its own robots.txt. Insites does not add any crawler rules of its own, including rules for AI crawlers. You decide what search engines and AI tools may read.
• Full notifications - Email, SMS, and API call notifications are all active.
• Monitoring and maintenance - Production requires ongoing attention. Keep dependencies updated, monitor performance, and apply security patches promptly.

Key Differences

Aspect	Staging	Production
Purpose	Building, testing, QA, UAT	Serving end users
Access	Developers and testers only	Public or specified user groups
Data	Sample or test data	Real, live user data
Email	Suppressed (test recipients only)	Full delivery
API Notifications	Disabled by default	Enabled
Custom domains	Not supported	Supported
Search engines	Hidden (noindex on every page)	Controlled by your robots.txt
Risk	Low (no user impact)	High (affects users, revenue, reputation)

Setting Up Your Environments

You create and manage instances through the Console. A typical setup includes:

• One staging instance per developer - Each developer syncs code to their own instance for independent work.
• A shared integration instance - Where developers merge code to resolve conflicts and verify combined changes.
• A UAT instance - For client review and sign-off before production deployment.
• A production instance - The live application.

The right number of environments depends on your team size and project complexity. A solo developer might use a single staging instance and production. A larger team benefits from the separation described above.

Security Considerations

Pay careful attention to data and access across your environments:

• Test data - Avoid copying real user data to staging environments. Use anonymized or synthetic data for testing.
• Access control - Restrict who can access each environment. Use password protection or token-based access on staging instances to prevent unauthorized access.
• Secrets and API keys - Use instance constants () to store API keys and secrets. Configure different values per environment so staging does not accidentally interact with production services.