EmDash Staging Sites
Last updated
A staging site is a separate copy or environment used to test changes before they affect the production website. EmDash does not make every site automatically require staging, but the practice becomes useful when a change is larger than an ordinary content edit.
Because an EmDash website is an application with persistent content and media, a useful staging environment needs clearer boundaries than simply copying the public HTML.
When is staging useful for an EmDash site?
Routine content changes usually belong directly in the CMS workflow. Correcting a sentence or replacing a photograph does not necessarily justify creating another environment.
Staging becomes more useful for application changes, larger redesigns, new integrations, content-model changes or work that needs several rounds of review before it should appear publicly.
What should a staging copy include?
The answer depends on what is being tested. A realistic staging environment may need the same application and design version as production, along with representative content and media.
It does not always need a permanent copy of every production resource. The important requirement is enough isolation and realism to exercise the change without accidentally mutating the live site.
Keep staging and production separate
A staging site should not share writable production resources unless that behaviour is deliberate and understood. Testing a migration against the live database defeats the main reason for having a separate environment.
Authentication and public visibility also need thought. A temporary test site may contain copied business content that is not intended to appear in search results or be treated as another public version of the website.
Staging is different from recovery
Recovery returns a damaged or unwanted production state to a protected earlier point. Staging gives you somewhere separate to test a future change. They solve different problems.
A robust managed platform can use both: staging to reduce the chance of introducing a problem, and recovery to provide a route back when production still needs to be restored.
Staging is different from a local development site
A developer's local environment is excellent for coding and fast iteration. A staging environment is closer to the hosted production arrangement and can be shared with other people for review.
For an Astro and EmDash application, that distinction can matter when a change depends on hosted database, media, routing or runtime behaviour that differs from a local machine.
DashHarbor staging and cloning
DashHarbor plans managed site cloning and staging after the core paid hosting product is proven. The goal is to create a temporary managed copy without turning staging into a separate infrastructure project for the customer.
Production continues to serve visitors while the temporary copy is used for testing. See DashHarbor staging and cloning for the product direction.