Understanding Staging and Live in SGEN
Two environments per site, with deliberate separation between work and public.
The staging and live separation in SGEN gives every site two environments. The split is deliberate. The staging environment gives operators a controlled place to work; the live environment is the public-facing version visitors see. Knowing which environment is which, when each is ready, and how to move work between them is the foundation of every SGEN site's operating cadence.
What is this for?
Read this guide to understand the staging and live separation before working on an SGEN site for the first time. The mental model — staging available immediately, live available once domain and certificate conditions are met — drives most of the early decisions on a new site.
Good use cases
- You provisioned a site and want to know which environment is ready when.
- You are explaining the two-environment model to a teammate or stakeholder.
- You are trying to understand why a newly created site is not yet visible at its public URL.
- You hit a question like "Why does my site work in staging but not at our domain?"
What NOT to use this for
- Step-by-step access workflow — open How to Access Staging and Live in SGEN.
- Domain configuration — open How to Point Your Domain in SGEN.
- Live status interpretation — open How to Interpret Live vs Maintenance or Unavailable States in SGEN.
Before you start
You should have:
- An SGEN account with at least one site provisioned.
- Access to SG-Dashboard's Site Manager.
- A vague understanding of how DNS and SSL certificates work — not deep, only "domains point to servers, certificates take time to issue."
How this connects to other features
- How to Access Staging and Live in SGEN — the operator workflow for opening either environment.
- How to Point Your Domain in SGEN — the configuration step that brings live into ready state.
- How to Interpret Live vs Maintenance or Unavailable States in SGEN — what specific state labels mean.
- SG-Dashboard Site Manager — the surface where staging and live are managed per site.
Where to go
Open SG-Dashboard, then Site Manager. Each provisioned site shows controls for both staging and live environments.
How staging and live work
Steps — Use the two-environment model
1. Recognize the two-environment model
Every SGEN site has two environments — staging and live — provisioned at the same time. The two are independent stacks: each has its own database, its own file storage, its own URL, its own state. Changes in one do not automatically appear in the other.
Staging is the working environment. Operators set up the site, configure settings, build pages, test forms — all on staging — without affecting any public-facing version.
Live is the production environment. It is the version that real visitors load when they reach the site's public domain. Live has the same shape as staging (same database structure, same admin surface) but is treated as the real thing.
2. Use staging from day one
Staging is available immediately when a site is created. From Site Manager, the View Staging Site action opens the staging build in a new tab; Login to Stage opens staging already logged into the admin.
Operators work entirely on staging during the build phase. The staging environment doesn't depend on DNS or SSL — it has its own SGEN-provided URL that resolves the moment the site is provisioned. Build, configure, draft, preview, all on staging.
3. Wait for live readiness
Live readiness depends on two conditions:
- DNS propagation — the operator's domain (e.g.
acme.com) must be pointed at SGEN's servers. DNS changes take time to propagate, often anywhere from a few minutes to a few hours depending on the registrar and the prior DNS state. - Certificate provisioning — once DNS resolves, SGEN issues an SSL certificate for the domain. Issuance is typically fast once DNS is correct, but it has its own short delay.
Until both conditions are met, live exists as a placeholder — provisioned but not yet usable. The Site Manager surfaces this state clearly; operators don't have to guess whether live is ready.
4. Move work from staging to live
Once live is ready, operators move the site forward to live. The mechanism depends on the workflow:
- Promotion — the platform offers a promote-to-live action that takes the staging site state and applies it to live in one step. Useful when the staging build is the version that should go live.
- Direct edit on live — once live is the production target, operators can edit live directly. Most teams continue using staging as the working environment and promote selectively.
- Restore from backup — staging and live can be reset from any backup; this is the recovery path more than the standard promotion path.
The right mechanism depends on the team's workflow. Most small teams use staging as the working environment and promote when ready; larger teams sometimes use staging only for experiments and edit live directly for content updates.
5. Maintain the separation
After the initial promotion, staging and live diverge. Updates made on one do not automatically appear on the other.
Operators choose which environment to work on based on what the work is. Quick content updates often go directly on live. Riskier changes — design rebuilds, structural changes, schema migrations — usually start on staging, get reviewed, and promote.
The separation is intentional. Operators who treat staging as a sandbox and live as the production target avoid most of the publish-too-early problems that one-environment platforms produce.
What success looks like
A successful understanding of staging and live shows up as:
- You know which environment you're working on at any moment without having to check.
- You use staging for risky changes and live for routine updates without thinking about it.
- You don't expect changes on one environment to appear on the other.
- You understand that newly provisioned live needs DNS and SSL to complete before it's usable.
When all four hold, the two-environment model is internalized.
What to do if it does not work
The site appears in staging but not at the domain. Almost always a DNS or SSL state issue. Open the Site Manager and look at the live status; the surface tells you whether DNS is propagated, whether the certificate is issued, and what step is pending.
Changes on staging aren't appearing on live. Expected — the environments are independent. To move staging changes to live, run the promote-to-live action.
Login fails on live but works on staging. Live and staging have separate session state. Logging into one does not log you into the other. Use the per-environment login actions in Site Manager.
The staging URL works but feels slow or shows errors. Staging shares fewer resources than live by design — it's a working environment, not a production environment. Persistent errors should be reported through support; intermittent slowness is usually expected.
The promote-to-live action isn't visible. May indicate live isn't ready yet (DNS or certificate pending) or that the role assigned to your account doesn't include promote rights. Check live status first; check role assignment second.
Best practices
- Use staging for the build phase. Don't try to work on live before staging settles.
- Watch the live readiness state in Site Manager rather than guessing.
- Promote to live deliberately, not on every staging save.
- After promotion, decide per-change whether to use staging or live for subsequent edits.
- Keep credentials for staging and live distinct in your password manager — they are separate logins.
Common questions
Why two environments? To give operators a controlled place to work before changes affect public visitors. The separation is the simplest reliable safety net for site changes.
Are staging and live always identical? No. They start identical when the site is provisioned, then diverge based on what operators do on each.
Can I see what's different between staging and live? The platform's diff and revision tools surface per-record changes; full-environment diffs are typically reviewed through the staging-then-promote workflow rather than a side-by-side comparison.
How long does live readiness take? Once DNS is correctly pointed, certificate issuance is usually fast (minutes). The bottleneck is DNS propagation, which depends on the registrar and the prior DNS state.
What happens if I edit live directly? Nothing breaks; live is a working SGEN environment too. The discipline question is whether you want a tested staging version before the change goes live; for routine content updates, direct edit on live is fine; for design or structural changes, staging-first is safer.
Can I have more than two environments? Some plans support additional environments (e.g. a development environment alongside staging and live). The default is the two-environment model; team plans may extend it.
Multi-site management
For operators managing several SGEN sites, the staging-and-live model applies per site. Each site has its own staging and live; the SG-Dashboard surfaces all of them under one account.
Switching between sites in Site Manager is one click. Sessions are per site (logging into one site's admin doesn't log you into another's), but the dashboard chrome makes the switch fast.
Multi-site teams sometimes share a saved-component library or design tokens across sites.
That sharing is handled through site-templates and theme management rather than through staging-and-live promotion.
The two systems compose cleanly: shared design assets at the account level, per-site staging-and-live workflows for the actual site state.
Each site's staging-and-live state stays isolated; sharing happens at the design-system layer, not at the per-site state layer.
Site states across the lifecycle
The state of staging and live changes across the site's lifecycle. A few states worth recognizing.
Newly provisioned. Staging ready, live waiting on DNS+certificate. Operators work on staging; live shows a "not yet ready" indicator in Site Manager.
Live ready, no domain. If the operator hasn't pointed a domain yet, live runs on an SGEN-provided URL similar to staging. Some teams use this state for internal preview before committing to a domain.
Domain pointed, certificate pending. DNS resolves to SGEN, certificate not yet issued. Visitors hitting the domain get a temporary error or self-signed warning depending on the configuration. The window is usually short.
Fully live. DNS pointed, certificate issued, public traffic served. Steady-state for a published site.
Maintenance. Operator-triggered or platform-triggered maintenance window during which the live site shows a maintenance message. The Site Manager surfaces the active maintenance state.
Suspended. Account or plan-level issue suspends live serving. The live URL returns a notice; staging may also be limited depending on the cause. Resolution depends on the underlying issue (billing, terms-of-service, etc.).
Reading state correctly
The Site Manager surfaces the current state for both staging and live. The state read in Site Manager is authoritative; visitor-side observations are confirmation, not the primary source.
When state appears off — live not loading when Site Manager says ready — clearing the visitor's DNS cache or checking from a different network usually reveals whether the issue is propagation lag or something deeper.
Promote action in detail
The promote-to-live action is the bridge between staging and live. Knowing what it does at the engine layer makes the rest of the workflow easier to reason about.
What promotes: records (Pages, Posts, Custom Object instances), templates, components, configuration, media references. Anything stored in the staging database that has a corresponding home on live.
What doesn't promote automatically: form submissions captured on staging (those are typically not relevant on live), per-environment configuration that's intentionally divergent (different analytics IDs, different integration credentials), session data.
How conflicts resolve: when a record exists on both staging and live and both have changed since the last promote, the platform's default is to favor the staging version. Operators can configure conflict resolution per record class for finer-grained control.
When promote is reversible: the prior live state is preserved as a backup snapshot before the promote runs. Restore from that snapshot returns live to the pre-promote state. The window for this restore depends on the plan's backup retention.
Promote frequency
Most teams promote infrequently — once at launch, then per-major-release. Day-to-day content updates often happen directly on live without a promote. The promote action is for moving substantial work between environments, not for every save.
Teams that promote frequently usually have a pipeline that automates the action; manual frequent promotes tend to introduce coordination overhead that defeats the safety benefit.
What changes between staging and live
The environments share the SGEN admin shape but carry independent state.
Database state is independent. Each environment has its own database. Records, settings, configurations are stored separately. A page created on staging exists only on staging until promoted; a form submission on live exists only on live.
File storage is independent. Media uploaded to staging stays on staging; media uploaded to live stays on live. The promote action carries media along with content where applicable.
URLs are different. Staging has its own SGEN-provided URL (typically a subdomain); live serves the operator's domain. Internal links written into content adapt automatically to the rendering environment.
SSL certificates are different. Staging uses an SGEN-managed certificate covering its subdomain; live uses a per-domain certificate issued for the operator's domain.
Sessions are independent. Logging into the staging admin does not log you into the live admin. Operators with access to both environments use separate sessions.
Backups are independent. Each environment maintains its own backup history. Backups can be restored within an environment; cross-environment restore (taking a live backup and restoring it onto staging) is supported through the promote / restore tooling.
What stays the same
The admin surface, the module set, the available components, the underlying engine — all identical between staging and live. Operators don't have to relearn the admin when switching.
The shared admin shape is intentional. Operators who learn the admin on staging are ready to work on live without retraining.
Common workflows on the two environments
Different teams settle into different rhythms with staging and live. A few patterns recur often enough to be worth naming.
Build-on-staging pattern. All build work happens on staging. Promote-to-live runs once when the site first launches. After launch, content updates often go directly on live; structural changes return to staging first. This is the default pattern for small operator teams.
Always-staging pattern. Every change starts on staging, gets reviewed, then promotes to live. Suitable for teams that want a strong review gate; adds a small amount of friction to every change in exchange for a stronger safety net.
Direct-on-live pattern. Content updates happen on live; staging is only used for risky structural work. Suitable for high-velocity content teams where the friction of stage-then-promote outweighs the safety benefit for most edits.
Branched-staging pattern. Multiple staging configurations are maintained for different purposes — a "next release" staging, a "prototype" staging. Requires plans that support multiple staging environments. Useful for larger teams running parallel work streams.
Choosing a workflow
The right workflow depends on team size, change velocity, and risk tolerance. The platform supports all of the patterns; teams pick the one that matches how they work.
A useful starting point: build-on-staging for the first launch, then transition to direct-on-live for routine content with returns to staging for risky changes. Most teams find this rhythm settles into place naturally without explicit configuration.
Common questions about the live environment
Will live be slow on day one? Live shares production resources from the moment it goes ready. Performance is the same as it will be in steady state.
Can visitors reach the staging URL? The staging URL is reachable to anyone who has it, but it doesn't appear in search results, isn't linked from the live site, and operators don't typically share it. Practical privacy is good even though the staging environment isn't formally restricted.
Does staging count toward my plan's traffic? Staging traffic is generally not counted against the plan's traffic allowance. Live traffic is. Plans vary; check the specific plan terms.
What happens if I delete a record on live? It moves to trash on live. Staging is unaffected; the record still exists there.
Can I copy a single page from staging to live without promoting everything? Yes. The platform supports per-record export and import; operators promote selectively when needed.
Why does the live URL show "Unavailable"? Either DNS is not yet propagated, or the certificate isn't issued, or both. Check the Site Manager state for the specific signal.
Does promoting overwrite live's content? It depends on the promote action. The default is to promote the staging state to live in full; selective promote is available where needed.
Why staging exists
Two-environment models exist because one-environment models punish the operator's first mistake. On a one-environment site, every save is a potential public-visible change — operators have to be perfect on first try, or risk visitors seeing broken state.
The two-environment model softens this. Mistakes happen on staging where they don't matter; the work that reaches live has been seen first. The trade-off is a slightly heavier mental model — operators have to track which environment they're on — but the safety net is worth it for almost every operator.
Why not branching like Git?
Some platforms offer Git-style branching: many parallel environments, merges between them, full version-control of the site. SGEN's two-environment model is simpler — one staging branch alongside one live branch, with a promote action between them.
The simpler model fits most operator workflows. Teams that genuinely need parallel branches usually have engineering operators on staff and can model that workflow externally. The two-environment default avoids putting that complexity in front of every operator.
Domain readiness in detail
Domain readiness — getting live from "provisioned" to "usable at your domain" — has a few specific steps.
Step A — DNS pointing. Operators update DNS records at their registrar so the domain resolves to SGEN's servers. The exact records depend on whether SGEN handles the apex (root) domain, the www subdomain, both, or a different configuration entirely. The Site Manager provides the specific records.
Step B — Propagation. DNS changes propagate through caches across the internet. Some clients see the change quickly; others see it after their cache TTL expires. Most production-relevant DNS propagation completes within an hour for most visitors.
Step C — Certificate issuance. Once SGEN's servers see the domain pointed at them, the certificate authority issues an SSL certificate. This step is automated and typically finishes within minutes.
Step D — Live ready. Once DNS and certificate are both in place, live serves the production site at the domain. The Site Manager updates to show live as ready.
The four steps usually run in sequence. Operators don't have to drive each step; SGEN automates B, C, and D. The operator action is A (the DNS pointing); everything after is observation.
Reading order
Read this guide first. Pair with How to Access Staging and Live in SGEN for the per-environment access workflow. Pair with How to Point Your Domain in SGEN when ready to bring live into ready state.
If live shows an unexpected state (Maintenance, Unavailable), How to Interpret Live vs Maintenance or Unavailable States in SGEN explains what each state means.