Environment Model
Staging versus live — what each environment is for and how changes move between them.
The SGEN environment model separates the space where work happens from the space visitors see. Every SGEN site has two environments: staging and production. Changes start in staging, get reviewed there, and are promoted to production when they are ready. This page walks the model at the concept level — what each environment does, what is isolated between them, how the promotion works, and what to do when the two environments drift.
This is a sibling to the Deployment and Release Overview, the Performance and Reliability Overview, the Security and Isolation Overview, and the Staging and Versioning Overview. Read this page when the question on your mind is "which environment am I looking at, and what does that mean for what visitors see?"
What this page is for
This page answers four concept-level questions every operator has in the first week of using SGEN:
- What is the difference between staging and production, and which one are visitors using?
- What is isolated between the two environments, and what is shared?
- How does a change move from staging to production?
- What happens when staging drifts out of sync with production?
Good use cases
Reach for this page when you are doing one of the following:
- Starting work on a new SGEN site and you want to understand the staging workflow before you author the first page.
- Briefing a stakeholder who is asking why their preview link looks different from what visitors see.
- Setting up a team workflow and you need to explain which environment each role should be working in.
- Diagnosing a mismatch between what you see in the admin and what visitors see on the live site.
- Planning a coordinated launch that needs multiple pages to go live at the same moment.
What NOT to use this for
This page is concept-level. It does not give you any of the following:
- A configuration walkthrough. (See the module documentation for staging refresh, scheduling, and publish actions.)
- A platform deployment runbook. (See the Deployment and Release Overview for how SGEN's own software updates.)
- Stack-specific implementation detail. (Domain patterns, infrastructure details, and internal process names stay engineer-only.)
- An SLA or availability guarantee. (See the Performance and Reliability Overview for those commitments.)
How this connects to other features
This concept doc sits in the architecture cluster. The connected pages cover the surrounding ground:
- Deployment and Release Overview — how the SGEN platform itself moves through its own deployment environments before reaching production.
- Staging and Versioning Overview — the full content lifecycle (draft, scheduled, published, rollback) that lives inside this environment model.
- Security and Isolation Overview — the platform-level isolation guarantees that back the environment separation.
- Performance and Reliability Overview — how the production environment's performance commitments are maintained.
- SGEN Glossary — definitions for
staging,production,publish, and related terms.
Before you start
This page assumes the following baseline:
- You have a site (or are planning one) on SGEN at any plan tier.
- You understand what a "publish" action is — the step that moves content from draft to visible.
- You are not looking for a configuration walkthrough; you want the mental model.
Where to find it
This page lives at docs.sgen.com/reference/environment-model. The connected architecture pages are linked from the bottom of this one.
How the environment model works
Every SGEN site runs two environments simultaneously. They share a site identity — the same admin, the same content structure, the same member roster — but they serve different purposes and different audiences.
Staging
Staging is where work happens before it is ready for visitors. Authors draft content here, designers preview layout changes here, teams review before sign-off, and tests happen here before a change goes live.
What staging has:
- A separate URL (typically
.staging.sgen.com - Its own copy of the site's content — pages, posts, custom objects, media, settings — that can diverge from production during a round of edits.
- Its own analytics feed, treated as test traffic and usually excluded from production dashboards.
- Its own form submission inbox, separate from the production inbox so test submissions do not mix with real ones.
- Visitor-facing search indexing. Staging URLs are marked noindex; search engines do not index them.
- Integration triggers that point at production endpoints. Automations and webhooks configured in staging point at staging-side endpoints by default, so a test action does not fire a production email or trigger a production CRM update.
Production
Production is what visitors see. The production domain (yourdomain.com or the custom domain configured on the site) serves the content, handles the forms, fires the analytics, and carries the integrations that connect to real external systems.
What changes on production:
- Is live to every visitor immediately on promotion.
- Is indexed by search engines (unless the page is explicitly marked noindex).
- Fires the production analytics pipeline.
- Triggers the production integrations (CRM, email, webhooks).
What is isolated between environments
The isolation between staging and production is the model's core discipline. It is designed so that staging is a safe place to work without affecting visitors.
| Feature | Staging | Production |
|---|---|---|
| Content (pages, posts, objects) | Own copy — can diverge from production | What visitors see |
| Media library | Own copy for new uploads; shared read from production assets | Live asset delivery |
| Form submissions | Own inbox — separate from production | Real visitor submissions |
| Analytics | Feeds staging dashboard — excluded from production counts | Live visitor tracking |
| Search indexing | Noindex — invisible to search engines | Indexed (unless explicitly noindex) |
| Automations and workflows | Point at staging-side endpoints | Fire against production systems |
| Integrations | Use staging credentials by default | Use production credentials |
| Site settings | Own settings copy — changes here do not change production | Live configuration |
How changes move from staging to production
The path from staging to production has three forms.
Publish now. An operator authors or edits content in staging, reviews it, and clicks Publish. The content is immediately promoted to production and becomes visible to visitors.
Schedule for later. An operator authors content in staging and schedules it for a future moment. The content sits in staging with a scheduled state until the moment arrives, then promotes automatically. Multiple pieces of content can be scheduled for the same moment to coordinate a simultaneous launch.
Staging refresh (the reverse direction). When an operator wants to start a new round of edits from the current production state — for example, after someone published an emergency fix directly on production and staging is now behind — a staging-refresh operation pulls the current production content into staging as the new baseline. This is the only case where information flows from production to staging, and it is always an explicit operator action.
| Action | Direction | Operator action required | Timing |
|---|---|---|---|
| Publish | Staging → Production | Yes — click Publish | Immediate |
| Schedule | Staging → Production | Yes — set schedule date/time | At scheduled moment |
| Staging refresh | Production → Staging | Yes — initiate refresh | Immediate |
What happens when environments drift
Staging and production are the same site in two states. They start from the same baseline; they drift apart as work happens in staging. Drift is expected and normal. The cases where drift becomes a problem are worth knowing.
Long-running staging work that misses emergency fixes on production. If a team is authoring a major update in staging over two weeks, and meanwhile someone publishes a critical correction directly on production, staging does not automatically receive the correction. When the staging work is ready to promote, it would overwrite the emergency fix if the promotion replaces the full content set. The fix: run a staging refresh before promoting the two-week update so staging incorporates the emergency correction.
Staging settings that diverge from production settings. Changing a setting in staging — an integration credential, an SEO default, a theme setting — does not change production. If the intent was to change production, the operator has to make the same change on production explicitly. The setting is part of the content set that requires its own promotion.
Testing workflows in staging that fire production-side side effects. An automation that is incorrectly configured to point at production endpoints will fire real emails, real webhook calls, and real CRM updates when triggered in staging. Before testing automations in staging, confirm the endpoint configuration points at staging-side targets.
What success looks like
After reading this page, you should be able to do the following:
- Tell at a glance which environment you are looking at and what its URL pattern means.
- Explain to a stakeholder why their staging preview link looks different from what visitors see — and how to share a preview that reflects the current staging state.
- Identify which content, forms, and analytics records stay isolated per environment.
- Describe the three paths that move changes from staging to production.
- Send a team member a one-line summary: "Staging is where work happens; production is what visitors see; changes move from staging to production through an explicit publish or schedule action."
| You should be able to | Where on the page |
|---|---|
| Identify which environment you are in | Staging / Production sections |
| Describe the isolation guarantees | What is isolated between environments |
| Explain how changes promote | How changes move from staging to production |
| Handle environment drift | What happens when environments drift |
| Pick the right connected page next | Connected pages |
Examples
Three concrete operators using the environment model in different ways.
Example 1: A solo author working on a new page.
An author creates a page in staging, writes the copy, previews the layout, and shares the staging URL with a colleague for feedback. The colleague reads the staging URL and gives feedback. The author edits, shares again. When the page is ready, the author publishes. The page is live on production from that moment; the staging URL and production URL now show the same content.
Example 2: A team coordinating a product launch.
A team is launching a new product line. They author six pieces of content — three product pages, a press release post, an updated home page, and a footer update — in staging over two weeks. Each piece is reviewed and approved in staging. On launch day, they schedule all six pieces to publish at the same moment: 10 AM. At 10 AM, all six promote simultaneously. Visitors loading the site at 10:01 AM see a fully updated site.
Example 3: An emergency fix after a live error.
A published post contains a factual error. The editor opens the post on production (not in staging), corrects the text, and publishes directly. The fix lands immediately. Later, the editor runs a staging refresh so the corrected version is also in staging, keeping the two environments in sync for the next round of edits.
Why two environments instead of one
The single-environment alternative — editing directly on production — is the workflow many smaller sites and older platforms used. The cost of that model is visible in practice:
- A half-finished edit is visible to visitors until the author is done.
- A mis-click that publishes the wrong version is immediately live.
- Reviewing work before it goes live requires the reviewer to be in the admin at the same time the author is, looking at an in-progress state.
- Testing an automation or integration requires using production systems as the test target.
Connected pages
This concept doc sits in the architecture cluster. The connected pages cover the surrounding ground:
- Deployment and Release Overview — how SGEN's own platform software moves through its own deployment environments.
- Staging and Versioning Overview — the full content lifecycle that operates within this environment model.
- Security and Isolation Overview — how site data stays protected at the environment boundary.
- Performance and Reliability Overview — how the production environment's availability targets are maintained.
- SGEN Glossary — definitions for
staging,production,publish,schedule,staging refresh, and related terms.
The shortest possible summary
If you read nothing else on this page, take this with you:
Every SGEN site has two environments. Staging is where work happens — authors draft, teams review, tests run. Production is what visitors see. Changes move from staging to production through an explicit publish or schedule action. The two environments are isolated: content, forms, analytics, and integration triggers stay separate until an operator promotes them.Send that paragraph to a new team member and they have the mental model they need to work safely in the admin.