EmDash Updates and Safe Website Upgrades
Last updated
Updating an EmDash website is an application change, not merely clicking a version number. The running site may include EmDash itself, an Astro application, a theme or custom presentation, database changes and plugins. A safe update considers the complete working site before deciding the new release is successful.
The right process depends on how the site is maintained. A developer-operated project can use its normal source-control and deployment workflow. A managed host can automate more of that process, but it should still protect the existing state and verify the result.
What can change during an EmDash update?
The visible version number is only one part of the change. An update can alter application code, dependencies, database expectations or the way an existing design interacts with CMS data. Plugins can introduce their own compatibility requirements as well.
That is why a working site should be treated as a known combination rather than a collection of unrelated latest versions. Knowing the EmDash release, design release and relevant extensions makes update testing much more useful.
Protect the working site first
Before an update changes persistent data or the running deployment, create a recovery path for the current working state. That protection should cover the data and media the site needs, not only the application files that can already be rebuilt from source control.
The protection point also needs to remain available until the new release has passed its checks. Removing the previous state as soon as a deployment starts defeats much of the purpose.
Database migrations need special care
Application releases can include database changes. Once persistent data has been migrated, simply redeploying older code may not be enough to return the website to its previous state.
A safe workflow therefore distinguishes between an update that has not changed persistent state and one that has. If the database or media has been mutated, rollback may need to restore protected data as well as the previous application release.
How do you know an EmDash update worked?
A deployment reporting success is only the first check. The public website should load, important content should render, uploaded media should remain available and the EmDash editor should still work.
For a managed site, publishing through the updated editor is an especially useful end-to-end check because it exercises more than the public homepage. The exact checks can vary by site, but they should represent real customer workflows.
What should happen when an update fails?
A failed mandatory check should stop the new release from becoming the accepted working version. If the update has already changed data or media, recovery needs to restore those components as well as the previous deployment.
DashHarbor's planned managed update flow protects the site before mutation, applies the supported release, verifies the website and editor, then either promotes the release or restores the previous protected state.
See managed EmDash safe updates for the DashHarbor-specific lifecycle.
Do plugins need updating separately?
Plugins are another compatibility surface. Sandboxed registry plugins and native application plugins have different installation models, so their update behaviour should be considered alongside the site release rather than assumed to be identical.
Read the EmDash plugins guide for the distinction between registry-installed sandboxed plugins and native plugins that form part of the application deployment.