Cendia is hosted inside your .NET application. Your deployment contains your models, templates, assets and the released Cendia packages. Managed Cendia hosting provisions environments and provides stage operations for that application; it does not replace your site with a generic CMS.
Choose your environment shape
Managed environments can have one stage (PROD), two (INTE, PROD) or three (INTE, PREP,
PROD). INTE is integration; PREP is preparation for production. Each stage has its own database
and storage configuration. Promotion slots are available on target stages that have a lower stage.
The managed hosting account and environment are provisioned through the Cendia onboarding process. The customer portal exposes the operations permitted for that environment. A newly provisioned CMS uses an issued first-administrator setup link; complete setup before that link expires. Contact the environment administrator if it is no longer valid.
Deploy the application
Publish the .NET host using the release configuration:
dotnet publish -c Release
Deploy the resulting application to INTE, or to PROD for a single-stage environment, using the deployment access supplied for that environment. Keep each stage's connection strings, storage credentials and host configuration in its environment settings. Do not ship development user secrets in the publish output.
Packaged CMS migrations can run at hosted startup when Cendia__MigrateOnStartup=true is set.
Your own database context and migrations remain your responsibility. Review database changes
before deployment, including compatibility with the previous application version.
Checkpoint: the target stage starts, /cms is reachable with the intended access controls,
and a published page or delivery request returns the expected content for its hostname and culture.
Promote code with Push, verify, then Swap
In a multi-stage environment, Push copies the lower stage's application into the target's swap slot. The slot runs against the target stage's settings and database. Startup can therefore apply migrations to the target database before the code is swapped into the primary site.
- Push INTE to the next stage's slot.
- Open and test that slot with the target stage's content and configuration.
- Verify rendering or headless delivery, sign-in, media and the relevant authoring workflow.
- Swap only after those checks pass.
- For three stages, repeat from PREP to PROD.
This promotes application code. It does not copy the lower stage's content database into PROD.
Understand rollback
Swap Back returns to the previous application code in the retained slot. It does not reverse database migrations or content changes. A database change incompatible with the previous code requires a planned recovery; code rollback alone cannot make it compatible.
Keep schema changes compatible across the promotion window where possible. Confirm backups and the environment's recovery process before changes that require restoring data.
Copy data only when you intend to overwrite it
The portal's overwrite operation copies a database and the media/designer containers into the target stage. Existing target data is replaced. Form uploads are excluded from that storage copy and remain stage-specific.
Before launch, permitted copy directions depend on schema compatibility. After launch, normal customer operations copy down one adjacent stage: PROD to PREP to INTE, or PROD to INTE for a two-stage environment. Overwriting live PROD requires the staff-managed process of taking the environment out of live status. There is no automatic customer undo for a data overwrite.
Confirm the source, target and consequences shown by the portal before starting. Use code promotion for deploying features; use data copying when you explicitly want the target to receive another stage's content.
Self-hosted applications and headless frontends
For self-hosting, arrange the .NET runtime, SQL Server, durable media storage, HTTPS, secrets, backups and migration execution in your own platform. See Media storage and Database changes.
A separate headless frontend also needs its own deployment and cache-refresh strategy. Test it against the intended CMS stage rather than assuming that a CMS code swap redeploys the frontend.