CelinQ Insights · No. 59

Enterprise Architect in Azure, on-prem or air-gapped: local-first deployment patterns

The architect's laptop stays the same wherever you put it. Where the collaboration control plane lives is a deliberate decision, not a default.

One of the quieter advantages of a local-first architecture is that the deployment question, which for a conventional shared repository is enormous and consequential, becomes comparatively narrow. When every architect's genuinely complete working copy lives on their own laptop, the thing left to deploy is not "the model" but a coordination layer: a server that stores the canonical revision history, arbitrates synchronisation, runs the Fusion merge engine, and hosts the Control Plane console. That server can live in a number of places, and because it is a standard ASP.NET Core service backed by either SQLite or PostgreSQL, the honest answer to "where should we put it" has more to do with the organisation's existing infrastructure posture, its regulatory obligations, and its appetite for operational overhead than with any constraint the platform itself imposes. This article walks through the realistic patterns — cloud, on-premises, and air-gapped — plainly, including the parts that are genuinely production-ready today and the parts that are a clear, sensible direction rather than something already sitting in a released build.

Cloud: CelinQ Server in Azure

For organisations already committed to Azure, running the CelinQ Server there is a straightforward extension of infrastructure they already operate. The server itself has no dependency that ties it to a particular cloud — it is a self-contained .NET service that listens on a gRPC port for the synchronisation protocol and a REST port for the API, Control Plane, and health endpoints — so it deploys the same way any comparable internal service would: a virtual machine or App Service instance running the published binary, sitting behind the organisation's own TLS termination and network controls, with its database either co-located or, more commonly at genuine scale, run as a managed Azure Database for PostgreSQL instance rather than the default local SQLite file. This pairing matters for exactly the reason it matters for any production service: SQLite is an excellent default for a single-process deployment with no separate database tier to operate, contract-tested and reliable for that role, but an organisation running at real scale, wanting point-in-time recovery, read replicas, or a database estate managed by an existing DBA team rather than a single file on a single disk, has a documented path to PostgreSQL through a storage-provider setting, with the same domain, synchronisation, and Fusion logic running unchanged underneath either choice. The trade-off between running your own database file and paying for a managed service is the same one covered from the pure cost angle in the piece on what a DBMS actually costs, and it applies here exactly as it would to any other service an organisation chooses to run in Azure.

Two things are worth stating honestly about this pattern rather than glossing over. First, while the server's architecture is fully cloud-portable and nothing in its design assumes a particular hosting environment, that portability is a property of how it is built, not a claim that a specific, tested, production Azure reference deployment has already been exercised end to end on this project. An organisation adopting this pattern should expect to do the same infrastructure work — network security groups, managed identity or key-vault-backed secrets, monitoring integration — it would for any other self-hosted service it moves into Azure, rather than expecting a one-click marketplace deployment that does not yet exist. Second, and more specifically, Entra ID integration — letting Azure's identity platform authenticate CelinQ users directly, the natural expectation for any Azure-hosted service in an organisation already standardised on Entra — is a clearly stated direction rather than a shipped capability today. What exists in production now is token-based authentication: personal access tokens, hashed and stored with PBKDF2, checked on every request, with workspace roles from Viewer through Owner enforced on every operation. OIDC support, with Entra ID and other identity providers named specifically as the intended targets, is the documented next step, and the underlying principal and role model was deliberately designed to accommodate it without a protocol change when it lands. Describing Entra ID as already wired up would be exactly the kind of overstatement this series refuses to make; the honest description is that token auth is real, tested, and enforced today, and OIDC is a clear, near-term direction built on an architecture already shaped for it.

On-premises and private cloud

For organisations that need or prefer to keep the collaboration server entirely inside their own network — a common requirement for the public-sector and defence clients this platform is frequently built for — the on-premises pattern is, if anything, the simpler one to reason about, because it removes an entire category of question about a third party's infrastructure. The server runs on a machine the organisation owns and controls, inside its own data centre or its own private cloud, reachable only from within the corporate network or over a VPN the organisation already operates for other purposes. Architects connect exactly as they would to a cloud-hosted instance — HTTPS to the REST and gRPC endpoints, with the same TLS and token-authentication posture — the only difference is that the network path never leaves infrastructure the organisation directly controls.

This pattern typically pairs naturally with the default SQLite deployment for smaller and mid-sized workspaces, since it removes an entire separate database tier from the list of things an already-stretched internal IT team has to operate, while remaining fully compatible with PostgreSQL for organisations that already run a database estate and would rather add one more managed instance than introduce a new kind of file-based service into their operational inventory. Either storage choice runs the identical synchronisation and Fusion logic; the decision is purely about which operational shape suits the team running it, not about any difference in what architects experience day to day.

VPN access and the local-first advantage that survives it

Because architects working against an on-premises server frequently connect over a corporate VPN, it is worth being explicit about why this deployment pattern does not reintroduce the latency problem that motivated local-first architecture in the first place, a concern examined in detail in the piece on Enterprise Architect over VPN. A conventional shared-repository setup accessed over VPN suffers because every interactive operation — opening a package, reading an element's properties — becomes a round trip across a network path that a VPN typically makes slower and less consistent than a direct office connection. CelinQ's architecture sidesteps that specific pain regardless of where the server sits, because the architect's actual modelling happens entirely against the local repository; the VPN is only in the path for the periodic, asynchronous synchronisation of changesets, not for every click. An on-premises server reached over a mediocre VPN link is, for this reason, a perfectly workable deployment pattern in a way that a conventional remote database accessed the same way usually is not — the VPN's latency is absorbed by Smart Sync's debounce and safety-sync cadence rather than being felt on every interaction, exactly as it would be absorbed for a laptop working from a hotel room described elsewhere in this series.

Where the server lives changes who operates it and who is legally responsible for the data it holds. It does not change how fast modelling feels, because modelling was never talking to that server in the first place.

Sovereign mode and air-gapped configurations

The most restrictive and, for a subset of this platform's audience, most important pattern is the fully air-gapped deployment: a server with no route to the public internet at all, running inside a network boundary that permits no outbound connections beyond what the organisation has explicitly allowed. This is a natural extension of the on-premises pattern rather than a separate product, because nothing in the core synchronisation, Fusion merge, and Control Plane path requires any external service to function. The server talks to its own database, to the architects' companion agents over the internal network, and to nothing else, by default. An organisation running this way gets the full collaborative platform — local-first editing, Smart Sync, deterministic Fusion merges, presence, monitoring, backups, the complete Control Plane — with zero external dependency at any point in the ordinary operating path.

The one part of the platform that genuinely wants an external connection is the optional AI layer, and this is exactly the situation sovereign mode exists for. Sovereign mode is a configuration flag that disables all external AI irrevocably at the instance level — not a toggle an individual user can flip back on, but a hard, administrator-set boundary that removes the external AI code path from being reachable at all. For an air-gapped deployment, sovereign mode is not an optional hardening step; it is the honest description of the environment, because there is no outbound network path for an external AI provider to be reached over in the first place. This is the same principle explored more broadly in the piece on data sovereignty: the question is never whether a vendor promises to behave well with your data, but whether the architecture makes the alternative structurally impossible to reach, and sovereign mode is that structural guarantee applied specifically to the AI layer. Setting the flag makes that reality explicit and enforced rather than merely accidental, which matters for anyone who later has to answer a security questionnaire about what the platform could theoretically do if a network boundary were ever misconfigured. Everything else in the platform — sync, Fusion, monitoring, presence, the full add-in experience inside Sparx EA — works completely normally with AI switched off, because the core product was built to be genuinely useful without it, not merely functional in a degraded sense.

Optional external AI, when it is permitted at all

For organisations one step less restrictive than a full air gap — permitted a controlled connection to a specific external service but nothing more — CelinQ's AI layer is designed around exactly that boundary. It is off by default in every deployment pattern described in this article, cloud or on-premises, and switching it on is a deliberate, administrator-only action: selecting a provider, supplying credentials that are then stored write-only and encrypted at rest, and enabling it per workspace rather than instance-wide, so a restricted workspace inside an otherwise AI-enabled deployment can simply be left disabled. Today that provider is OpenAI, reached through its Responses API, with the integration built behind a provider-abstracted interface specifically so that a customer-hosted or alternative provider can be added without reworking the policy and audit layer around it. It is worth being precise that a customer-hosted or fully private LLM option is, like Entra ID above, a described direction for that abstraction rather than an integration already shipped and tested; what is shipped and tested today is the OpenAI path, together with the fail-closed policy gateway, the audit trail of every AI call, and the sovereign-mode kill switch that overrides all of it. An organisation evaluating this pattern for a semi-restricted network should ask specifically which of those two states — shipped-and-tested, or documented-direction — applies to the exact configuration they need, rather than assuming a provider-abstracted architecture means every provider is equally available today.

Containers, and being honest about what has and has not been exercised

A Docker image is provided for organisations that prefer to run infrastructure as containers rather than as bare processes on a VM, and it is worth describing its status with the same candour applied throughout this article. The Dockerfile builds the server — which is entirely Sparx-free, since the server itself never touches Enterprise Architect's COM automation surface, only the companion agents on architects' own laptops do that — into a self-contained Linux image, configured to listen on the same gRPC and REST ports as the bare-metal deployment and to write its SQLite database into a mounted volume. It compiles from the identical source tree that passes the full test suite on Windows. What has not yet happened, plainly stated, is building and running that image on a machine with Docker actually installed and verifying it end to end; the development environment this platform has been built and tested on does not currently have Docker available. Treat the image as a correct, buildable starting point drawn from tested code, not as an artifact that has itself been exercised in a running container. Any organisation planning a containerised or Kubernetes-based deployment should build and smoke-test the image themselves as a first step, exactly as they would for any newly-provided container definition from a vendor, rather than assuming "a Dockerfile exists" is equivalent to "this has been run in production."

Multi-office deployments and the question nobody asks until it matters

Most discussions of deployment pattern implicitly assume a single server instance serving a single, geographically coherent team, and for a majority of deployments that assumption holds. It is worth addressing the case where it does not, because it is common in exactly the kind of organisation this platform tends to serve: a public-sector body with several regional offices, a consultancy with architects distributed across client sites in different countries, an agency whose headquarters and a satellite office sit on opposite sides of a continent. The honest answer is that CelinQ's architecture handles this case naturally, precisely because the coordination server was never in the critical path of interactive modelling to begin with. A single CelinQ Server, hosted in whichever pattern the organisation has chosen — Azure, on-premises, or a private cloud region — can coordinate architects in every office simultaneously, because what crosses the distance between offices is not interactive traffic but periodic, asynchronous changesets, the same traffic Smart Sync already adapts sensibly to a slow VPN link or an intermittent mobile connection. An architect in a satellite office three time zones away experiences exactly the same full-speed local editing as one sitting next to the server, because their editing was never talking to the server directly in the first place; only their synchronisation cadence differs, and that differs invisibly, in milliseconds spent in the background rather than seconds felt on every click.

Where this genuinely matters is in choosing which region hosts the single server instance, because that choice does carry real consequences even though the modelling experience does not depend on it. A server hosted in the same region as the majority of an organisation's architects will show marginally faster synchronisation for that majority and marginally slower synchronisation for a minority working from further away — a difference measured in the responsiveness of background sync, not in anything an architect notices while actually working. The more consequential factor is usually regulatory rather than technical: many public-sector contracts specify explicitly which jurisdiction data must reside in, and that requirement, not network topology, is typically what decides where the single canonical server actually sits. This is worth raising directly with the same audit-minded rigour applied throughout this series, in the spirit of the piece on public-sector audit requirements: know the data-residency clause in the contract before choosing a hosting region, not after.

Choosing between the patterns

None of these patterns is objectively correct; each answers a different question about who is accountable for the infrastructure and what the organisation is required to prove about where its data sits. A team without an existing on-premises footprint, comfortable with cloud accountability and already standardised on Azure for other services, gains the most from the Azure pattern — mainly reduced operational burden, since a managed PostgreSQL instance and a standard App Service deployment are things most cloud-native teams already know how to run and monitor. A team in a regulated sector with an existing data-centre or private-cloud footprint, and a requirement to demonstrate that architecture data never leaves infrastructure it directly controls, gains the most from on-premises, accepting the operational cost of running the server and its database themselves in exchange for a much simpler answer to any data-residency question an auditor asks. A team working with classified or extremely sensitive material, for whom even a controlled outbound connection to an AI provider is unacceptable, wants the air-gapped pattern with sovereign mode set from day one, accepting that the AI layer of this platform — and every other tool's AI layer — is simply not available to them, in exchange for a network boundary with nothing to misconfigure in the first place.

What stays constant across all three is the thing that matters most for the architects actually doing the modelling: the local repository on their laptop, the responsiveness of Sparx EA against it, and the offline continuity that lets them keep working through a VPN drop or a server maintenance window. The deployment pattern is an organisational and compliance decision made largely without the working architect's day-to-day experience changing at all, which is precisely the separation this whole series has argued for — the modelling experience and the collaboration infrastructure are two different concerns, and a well-designed local-first platform lets an organisation make hard decisions about the second without having to compromise on the first.

Migrating between patterns later

A question worth answering before it becomes urgent is what happens if an organisation's needs change: a team that started on Azure to move quickly later wins a contract requiring on-premises hosting, or a team that began on-premises later decides the operational overhead of running its own database is no longer worth avoiding cloud accountability. Because the domain, synchronisation, and Fusion logic are identical regardless of where the server process runs or which storage provider backs it, moving between patterns is fundamentally a data-migration and infrastructure exercise rather than a re-platforming one — export or replicate the database, stand up the server in its new location with the same configuration keys pointed at the new storage, and redirect architects' companion agents to the new server address. None of the client-side experience changes, and none of the revision history, Fusion rules, or workspace roles need to be rebuilt, because none of that logic was ever tied to a specific hosting environment in the first place. This portability is a direct consequence of keeping the server a plain, storage-abstracted service rather than something entangled with a particular cloud provider's proprietary primitives, and it is worth treating as a genuine advantage of the architecture rather than an afterthought: the deployment decision made today is not a decision an organisation is permanently locked into, in the way that a purpose-built managed service with no self-hosted equivalent often is.

Honest limits

It would undermine the whole point of this article to close without restating its central caveats together. The core platform — sync, Fusion, monitoring, the Control Plane, the EA add-in — is genuinely deployment-agnostic and tested in the Windows environment it has been built and hardened in, including a full production security posture of token authentication and TLS. Two specific things named repeatedly in this article are not yet finished, tested artifacts: OIDC and Entra ID authentication, which remain a clearly-stated direction built on an architecture designed to support it rather than a shipped integration today, and the Docker container image, which compiles from tested code but has not itself been run and verified end to end on this project. A customer-hosted or private LLM alternative to the OpenAI integration is likewise a described direction for the provider abstraction rather than a second, already-tested provider sitting alongside it. None of these gaps affect the core value of local-first collaboration, which functions completely without any of them. But an organisation choosing between these patterns, particularly one with a hard compliance deadline attached to identity federation or container orchestration, should treat this article's honesty as the actual specification and plan its rollout accordingly, rather than discovering the gap after the decision has already been made.