openDesk: multicloud operations and recovery safeguards

Situation: software choice creates operating responsibilities

An open-source workplace is a collection of services with shared identity, storage and mail dependencies. Selecting the applications leaves a second decision: who owns their lifecycle and how do changes preserve existing data and communication?

• Microsoft 365 and Google Workspace combine office and communication products as cloud services.
• Nextcloud Hub combines files, collaborative editing and communication, with self-hosting available.
• openDesk integrates open-source workplace applications. Community can be independently operated; public administrations also have Enterprise support and operating-model options.

Senticor's pilot used planned application pauses. That made lifecycle coordination a concrete engineering problem: application capacity could be rebuilt, but stored documents, identities and email could not be treated as disposable infrastructure.

Task and my contribution

My work covered lifecycle automation, upgrade safeguards, mail integration and incident investigation. The operating model separated functions that could pause from those that needed to continue, and made destructive steps conditional on evidence that retained state was safe.

The scope included infrastructure configuration, deployment customisations, operating scripts, checks and runbooks. The accepted trade-off was limited application availability in a pilot, with data retention taking precedence over uninterrupted access.

Actions: control changes across service boundaries

Separate the runtime from durable state

openDesk applications and mailboxes run on Google Kubernetes Engine. Terraform describes the GCP infrastructure; Helmfile customisations and scripts manage installation and lifecycle. Retained application disks and independent snapshot scheduling survive runtime pauses. An Ansible-managed STACKIT host provides mail reception and start/stop control; that retained host is deliberately outside Terraform's lifecycle.

Treat an upgrade as a change to data contracts

The upgrade proceeded through an intermediate release. Comparing rendered deployments checked persistent-volume claims, stateful storage templates and mail service interfaces. A changed upstream default would have selected a different object store on a cold rebuild. Explicitly retaining MinIO kept the installation connected to its existing store instead of creating a new empty one.

Make mail continuity and shutdown separate decisions

An independent MX mail receiver accepts and queues incoming messages while the application runtime is paused. It provides continuity of acceptance, not mailbox access. Shutdown must first drain the application's SMTP queues, stop their writers and verify the actual queues are empty. A failed or inconclusive check blocks teardown: the controller cannot infer safe shutdown from a successful command alone.

Investigate user access across dependencies

A restart incident left a healthy webmail application behind the public readiness gate. Correcting selection and state transitions restored access. Another investigation tied portal and mail symptoms to shared identity-service saturation. These records informed checks of login and delivery across the complete path, alongside component health.

Results: implemented controls and observed behaviour

Implemented

The pilot has a documented lifecycle across two providers, staged upgrade safeguards, independently scheduled disk snapshots and a mail-drain gate before runtime teardown. A retained-disk cleanup near-miss also led to inventory checks that refuse uncertain deletion and regression coverage.

Verified in the operating records

The records show an applied upgrade, restored public access and login after the gate correction, a complete ready snapshot set, and successful mail-queue preparation, offline inspection and service resumption. These are distinct observations, rather than an inference that every recovery scenario works.

Operating boundary

This remains a pilot with accepted downtime. The single MX receiver has finite queue retention; it is neither redundant nor covered by the GCP disk snapshots. Those snapshots are per-disk copies, not proof of an application-consistent restore. A complete isolated restore remains unproven. GCP and Cloudflare dependencies remain; neither full sovereignty, savings nor an availability improvement is claimed.

Lessons for platform decisions

• Define lifecycle boundaries before automating deletion: Runtime, persistent state, mail queues and recovery inputs have different lifetimes. Automation needs an explicit inventory and conditions under which it must refuse to proceed.
• Validate contracts across upgrades: Successful deployment is insufficient when storage defaults or service interfaces change. Existing data must remain reachable after both in-place upgrades and cold rebuilds.
• Separate service objectives: Accepted, forwarded and readable email are different states. A single availability indicator hides those dependencies and their separate failure modes.
• Make recovery a demonstrated operation: Snapshot existence, restore prerequisites and successful application recovery are different evidence. Production adoption needs the missing restore exercise and explicit service objectives.

Project and background

This case draws on Senticor’s own pilot operations records. The linked products provide market context; no comparative product test was performed.

• The openDesk project by ZenDiS
• openDesk documentation
• Public deployment repository