Staging vs. Production

Insites uses separate environments to keep development and testing safely isolated from your live application. 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.

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

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.