Why a public sector open source digital workplace suite is different
A public sector open source digital workplace suite differs from a commercial deployment mainly in how it is governed, hosted and approved. An agency that must replace or consolidate workplace tools under sovereignty and oversight requirements should first settle the control baseline, the data classification of each workload and the hosting location, because these decisions set the component list, the operating model and the procurement route. For German federal and state administrations, the most direct starting point is openDesk, a Kubernetes-based suite bundling chat, files, groupware, wiki, project management, video and web office, developed by ZenDiS GmbH, a federally owned company that took over development in January 2024. Where a narrower component set is wanted, a Nextcloud-centred stack built on the AGPL-3.0 Nextcloud Server can cover files, office and identity while other components are added separately. Government changes the build in four ways. First, the control catalog is set by law or policy rather than by the vendor. In the United States, NIST SP 800-53 Rev. 5 and its SP 800-53B baselines (low, moderate and high, selecting 149, 287 and 370 controls and enhancements respectively) determine what evidence the system must produce. Second, data classification decides where each workload may run. Criminal justice information under the FBI CJIS Security Policy, for example, requires FIPS 140-3 validated cryptographic modules, so the agency must confirm the module validation of every component that touches that data. Third, hosting must sit in government data centers or accredited clouds. Fourth, rollout happens agency by agency, with each ministry or municipality choosing its own order. Before committing, confirm three things with ZenDiS, the chosen partner and your own security office: which control baseline and classification apply to each user group, whether Community or Enterprise support is required for production, and which assessments your authority must complete and who performs them. Independent auditors and certification bodies perform compliance assessments; DeployOpen prepares the systems, controls and evidence for those assessments but does not issue audit reports or certifications.
Which public sector requirements shape the workplace build
This table compares the public sector requirements most likely to shape a self-hosted workplace, with the build impact on hosting, encryption, accessibility and procurement. Read each row against your own jurisdiction and data classes, because a requirement that applies to one agency may not apply to another in the same government.
| Requirement | What it asks for | Build impact |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines under SP 800-53B select 149, 287 and 370 controls and enhancements respectively. Relevant for US federal-aligned work and agencies that adopt the catalog by contract. | Choose the baseline with your authorizing official, then map each control to an openDesk or Nextcloud component, a Kubernetes setting or an operating procedure. Confirm which controls the chosen suite inherits and which you own. |
| FedRAMP scope under OMB M-24-15 | Cloud products that create, collect, process, store or maintain federal information on behalf of an agency fall in scope. Systems used only for one agency's operations on cloud infrastructure and not offered as a shared service are out of scope. | Hosting in your own government data center usually sits outside the cloud question, but a managed operator or hosted SaaS partner may not. Ask the partner which entity operates the workplace and whether it serves other agencies. |
| CJIS Security Policy v6.1 | For criminal justice information in transit and at rest outside physically secure locations, use FIPS 140-3 validated modules or FIPS 197 AES with keys of at least 256 bits. Vulnerability scanning must run at least monthly. | Confirm TLS termination, database and object storage encryption, and key management in every component, including mail relays and TURN. Schedule scanning across the full stack, not only the Kubernetes nodes. |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 | Federal agencies use NIST SP 800-171 to set protection requirements for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards. | If CUI moves into the workplace, the operator's systems that hold it need an SP 800-171 mapping. Confirm with the agency which safeguards apply and whether the hosting provider is inside that boundary. |
| ADA Title II and WCAG 2.1 Level A and AA | State and local government web content and mobile apps, including those delivered through contracts or licenses, must meet WCAG 2.1 A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200). | Accessibility is a procurement criterion. Test the bundled components, your theming and any custom portal pages with assistive technology, and record remediation owners. Ask each vendor for its accessibility statement and known issues. |
| NIS2 scope for public administration | Central government entities are covered regardless of size, and public administration is a high-criticality sector. Member States may extend coverage to local administration. National security, public security, defense and law enforcement are excluded. | Confirm whether your entity is in scope and whether the workplace supports risk-management measures such as supply chain security, access control and incident handling. Keep the exclusion analysis in writing, since workplace data may cross into excluded functions. |
| Procurement and edition choice | Public bodies usually need a named support model, contract terms for every bundled component and a documented upgrade path. openDesk is provided by ZenDiS, and its Enterprise Edition adds SLA-backed support. | Ask whether the procurement covers the open-source core only or the Enterprise Edition, and who supports each component. Budget for the chosen edition in the written scope before the build starts. |
Community or Enterprise: how openDesk support changes the operating model
Both editions rest on the same open-source core. The openDesk deployment automation is Helmfile and Helm based and licensed under Apache-2.0, while each bundled component keeps its own license. Nextcloud and Nubus are licensed under AGPL-3.0, OpenProject under GPL-3.0 and Collabora under MPL-2.0. This means the license of every component travels with it into your deployment, whichever edition you buy.
- Deployment code: Helmfile and Helm charts are Apache-2.0, so you can read, mirror and modify the deployment logic.
- Component licenses: each bundled product keeps its own terms, which affects how you may modify, redistribute or host it.
- Community support boundary: the Community setup relies on public channels and your own staff for production troubleshooting.
- Release cadence: openDesk plans annual major releases in Q3, monthly minor releases and on-demand patches, and supports only the latest minor version.
Confirm with ZenDiS and your legal team which obligations apply to your modifications, especially for AGPL-3.0 components you operate for users outside your organization. Do not assume the Community setup is production-ready without a named operations team and a tested upgrade path.
ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and a license file, and SLA-backed second and third level support and patches. It is sold as SaaS or for on-premises installation. The commercial layer changes who you call and what is contractually promised, not the open-source components beneath.
- Closed-source modules: Enterprise adds proprietary modules on top of the open-source core, which need to be reviewed under your procurement and source-code policies.
- Registry and license file: Enterprise images come from an Enterprise-only registry and require a license file, so plan for credential handling in your mirror.
- Support tiers: second and third level support and patches are covered by SLAs, and the response times and hours are stated in the contract.
- Deployment choice: choose between SaaS and on-premises installation according to your data residency and hosting rules.
Confirm in writing the SLA response times, support hours, patch delivery method, the registry access model and the license term before you sign.
Several capabilities that public sector teams often need are listed as Enterprise-only. They cover load handling, directory synchronization, administration and storage. Each one changes how you run the platform day to day, so they should be scored against your operating requirements rather than treated as add-ons.
- Collabora scaling: Enterprise includes Collabora branding and automatic load scaling for the web office, which matters for peaks in document editing.
- Element AdminBot and GroupSync: AdminBot and GroupSync with the Admin Console support administrative tasks and user group handling in Element and the wider suite.
- Nextcloud Guard and patches: Enterprise includes Nextcloud Enterprise security patches and the Guard app.
- OX S3 storage and search: Enterprise provides OX S3 storage and advanced full-text search for groupware data.
- OpenProject and XWiki add-ons: OpenProject Enterprise add-ons and XWiki Pro apps extend those components.
Ask the vendor which features are available in your chosen deployment model and whether any depend on a specific Kubernetes or storage setup.
Where the stack is centred on Nextcloud, Nextcloud GmbH sells Nextcloud Enterprise alongside the community version, aimed at enterprise, public sector and education users. Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum. According to the pricing page, list prices start at 71.29 euros, 104.99 euros and 204.75 euros per user per year respectively for 100 or more users, with lower rates from 200 users.
- Standard: includes one year of maintenance.
- Premium: adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support.
- Ultimate: adds support up to 24/7 with response times down to one hour.
- Release cycle: Nextcloud publishes a major version every four months and supports each for one year, so the tier must match your upgrade planning.
- Upgrade rule: Nextcloud does not allow skipping major releases, so each upgrade is a planned step.
These prices are list prices from the pricing page and may not reflect your negotiated terms. Confirm the tier, user count, maintenance lifecycle and support hours in the quote.
A quote should make the operating model explicit. Procurement must confirm license terms with the vendor before committing, since closed-source modules, registry access and component licenses each carry conditions. The following points are the ones public sector buyers most often leave unclear.
- Scope of the license: which components, user counts, environments (production, test, disaster recovery) and deployment models are covered.
- Support obligations: SLA response times, support hours, escalation path and who performs second and third level work.
- Patch and upgrade delivery: how patches reach your environment, how the registry or license file is handled in air-gapped areas, and the upgrade path between majors.
- Recurring and one-time costs: which subscription fees recur annually and which are one-time, and what changes when user counts grow.
- Operator responsibility: what your staff, the implementation partner and the vendor each operate.
Ask for the license terms in writing and have legal review them alongside the support schedule before procurement signs.
Which platforms fit government workplaces and why
Government buyers usually choose between a full sovereign bundle and a set of components they assemble themselves. Each option below trades integration effort against control over the parts, and each carries licensing and feature questions that must be confirmed with the vendor before a decision.
openDesk as the full bundle
openDesk is a Kubernetes-based suite from ZenDiS GmbH for public administration. It bundles Element with Nordeck widgets for chat, Nextcloud for files, OX App Suite for groupware, XWiki for wiki, Nubus for portal and identity, OpenProject, Jitsi, Collabora as the web office, and CryptPad with diagrams.net. It fits agencies that want one pre-integrated package and accept a Kubernetes operating model. Check that the mail, wiki and office feature sets meet your users' needs, and confirm which modules need Enterprise Edition for production support.
Nextcloud-centred stack
Nextcloud handles files, sharing and identity integration, paired with Collabora Online or ONLYOFFICE Docs for office editing, Stalwart or mailcow for mail, and Jitsi Meet or BigBlueButton for meetings. It fits organizations that want to assemble components individually and keep each one replaceable. You own the integration work between the parts, including single sign-on, backups and upgrade sequencing, so plan that effort explicitly in scope.
Office editing: Collabora or ONLYOFFICE
Collabora Online is licensed under MPL-2.0, while ONLYOFFICE Docs is licensed under AGPL-3.0 and advertises compatibility with Office Open XML formats. License terms differ, so legal review belongs in the selection. Test both against the document formats your ministries exchange, including macros and complex spreadsheets, and confirm how each integrates with your chosen file platform before committing.
Mail is a gap to plan
Neither a Nextcloud-centred stack nor the openDesk bundle should be treated as a drop-in replacement for a government mail estate. Stalwart is licensed under AGPL-3.0 with an optional Enterprise License, and mailcow is licensed under GPL-3.0, but both need separate design for deliverability, archiving, legal hold and calendar sharing with existing clients. Mail migration is usually the longest workstream, so start its requirements early. Confirm the mail protocols and retention features with each vendor against your records rules.
Wiki and knowledge gaps
Public sector knowledge bases often need page-level permissions tied to directory groups, versioned records and a clear owner for each space. BookStack is licensed under MIT, while Outline is licensed under the Business Source License 1.1 and its additional use grant restricts offering a commercial Document Service. Outline's license terms need legal review before it is adopted by any body that delivers services to third parties. XWiki, as bundled in openDesk, should be assessed against the same access model.
License notes for procurement
The components use different licenses: AGPL-3.0 for Nextcloud and Nubus, GPL-3.0 for OpenProject, MPL-2.0 for Collabora, and Apache-2.0 for the openDesk deployment automation. Each license sets obligations for modifications and distribution, and openDesk Enterprise Edition adds closed-source modules. Every license and feature claim in this comparison must be confirmed with the vendor or ZenDiS before the procurement file is written. Ask counsel to review each component license against your intended use.
Deployment patterns for ministries, states and municipalities
Public bodies rarely deploy openDesk the same way twice. The patterns below differ in who owns the cluster, how many organizations share it and where identity lives, but each one rests on the same Kubernetes baseline and the same split between bundled components and external services. Use them to decide which operating model fits your government data center and who signs for each piece.
Single ministry on a government cluster
One ministry runs openDesk on its own Kubernetes cluster inside a government data center, with a single tenant and a single set of administrators. The platform needs Kubernetes v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager and an RWO volume provisioner. Confirm early that your cluster is tested on kubespray, because openDesk is not tested on OpenShift. Your agency's platform team usually operates the cluster, while the ministry's IT service provider or DeployOpen operates the openDesk release and the external services such as PostgreSQL, MariaDB, Redis and the SMTP relay.
State-wide shared tenant with agency namespaces
A state IT center hosts one openDesk platform that serves several agencies, separating each agency into its own Kubernetes namespace. This pattern concentrates the cluster, the external databases and the upgrade work in one team, but it makes tenant isolation, per-agency data stores and change windows the central design questions. Ask who owns the shared PostgreSQL 15 and MariaDB 10 instances, the Redis 7 cache and object storage, and whether each agency can accept the same upgrade schedule. Confirm how Helmfile values are split per namespace before you commit to one release train.
Municipal consortium on a shared platform
Several municipalities pool budget and operations to run one workplace through a regional provider. Each municipality keeps its own users and administrators, but the consortium carries the Kubernetes platform, the Helm 3.17.3 or later (below v4) toolchain, Helmfile 1.0.0 or later and the external services. Smaller municipalities often lack the staff to run ingress, cert-manager and SMTP relays, so decide in writing which party carries the 2nd and 3rd level support. Ask whether the consortium will buy openDesk Enterprise Edition support for production, since that choice changes who answers for patches.
Federation with an existing agency identity provider
Many agencies already run a directory and want openDesk to trust it rather than create a second set of accounts. openDesk supports federation with an external identity provider, so the agency's directory remains the source of truth for sign-in and access. Plan who operates the identity bridge, which attributes are matched, and how joiners and leavers flow through. Keep the cluster's cert-manager and ingress configuration under the same change control as the identity service, since a certificate or ingress fault blocks sign-in for every component at once.
External services and who runs them
openDesk expects production-grade services outside the cluster: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Under each pattern, one party must own each service, its backups, patching and monitoring. Agencies often assume the cluster team covers these, then discover that mail relay and TURN belong to a network team. Write a responsibility matrix per service before procurement, and confirm that the external databases and object storage are hosted in the same government data center as the cluster.
How agencies roll out the workplace in phases
The sequence moves an agency from data classification and procurement to a governed, identity-federated production workplace that is rolled out in stages with monthly minor upgrades. Each phase closes with a named output that the next phase depends on.
Classify data and set governance per agency
Each agency's data owners, security officer and records lead agree which information classes will live in files, mail, chat, wiki and projects, and which applicable rules apply to them, such as federal control baselines, CJIS-type criminal justice requirements or EU NIS2 obligations where they apply. A DeployOpen consultant can facilitate the workshops, but the agency owns the decisions. The output is a signed classification register and a list of in-scope components, which later drives the hosting, encryption and retention requirements.
Define scope and place the procurement order
The agency decides which openDesk components it needs, whether it will run the Community or Enterprise edition, and which support tier applies. ZenDiS recommends Enterprise Edition for production, so the order should state whether SLA-backed second and third level support is included. Confirm with the vendor and the procuring body how each component is licensed and ordered, since each bundled component keeps its own license. The output is a written order and a statement of work that names the components, edition and support terms.
Run an evaluation deployment
The integration team stands up a non-production openDesk instance on a CNCF-certified Kubernetes cluster that meets the documented version requirement. The documented minimum for evaluation is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not yet supported. This environment is for validating components and workflows only, not for production data. The output is a test report covering installation, component health and the main user journeys, plus a list of gaps to close before production.
Build the production environment with external services
The platform team provisions production Kubernetes, ingress, certificate management and storage, then connects the external services openDesk expects in production, including PostgreSQL, MariaDB, Redis, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Hosting follows the agency's government data center or approved cloud policy. Backups, monitoring and a tested restore procedure are part of this phase. The output is an accepted architecture record and a restore test that the agency's operations team has witnessed.
Federate identity with the agency directory
The team connects openDesk to the identity source the agency already runs, typically through federation with an external identity provider or a directory import, and agrees attribute mapping for roles, departments and groups. Access rules for administrators are separated from ordinary users and reviewed before go-live. Confirm the supported federation path for the agency's directory in the current release documentation. The output is a tested login matrix for each user group and an approved access model signed by the identity owner.
Pilot with one agency
A single agency, or a limited group within it, moves real work onto the production instance for a defined period agreed in advance. The pilot tests onboarding, support routing, data migration of files and mail, and user training materials. Feedback is logged against the scope from step two. The output is a pilot closure report listing defects, accepted changes and the criteria the agency will use to approve wider rollout.
Roll out in stages with monthly minor upgrades
The agency adds user groups in waves, with each wave tied to a checked upgrade path. openDesk publishes minor releases monthly and supports only the latest minor version, so the team rehearses each upgrade in a staging copy before production. Where a deployment has fallen several minor versions behind, the upgrade may require intermediate steps. The output is a change record for each wave and a documented upgrade rehearsal result for every release applied.
Sign off accessibility and security evidence
Before the workplace is declared operational, the agency collects the evidence its assessors and policy owners need: accessibility testing against WCAG 2.1 Level A and AA for public-facing and contracted web content where it applies, vulnerability scan results, hardening baselines, audit log configuration and the signed patch record. DeployOpen prepares these artifacts, but independent auditors and accessibility reviewers issue the findings. The output is a signed evidence pack and a formal go-live decision from the agency's security and accessibility owners.
Evidence public sector assessors and auditors ask for
This table maps the evidence that federal, state and municipal assessors typically request to the part of the workplace suite that produces it. Read each row as a question to ask your implementation partner and your assessor: what artifact exists, which component generates it, and what is still missing. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do.
| Evidence area | What assessors expect | Where it usually falls short |
|---|---|---|
| Control mapping to NIST SP 800-53 | A documented mapping of suite controls to the selected SP 800-53 Rev. 5 baseline (low, moderate or high), with the system boundary stated | Shared Kubernetes and external services left out of the boundary, or inherited controls not attributed to a named owner |
| FedRAMP status for cloud-hosted parts | Confirmation of whether any hosted service is a cloud offering serving agency information, and its FedRAMP authorization status | Assumption that a self-hosted deployment in the agency's own data center needs no review, or a SaaS add-on with no authorization evidence |
| Encryption for CJI and CUI | FIPS 140-3 validated modules or AES with at least 256-bit keys for data in transit and at rest outside physically secure locations | TLS and database encryption configured at 128-bit, or module validation status unknown for bundled components |
| Monthly vulnerability scan reports | Scan results at least monthly for the suite's hosts, containers and applications, with findings tracked to closure | Scans run on the cluster only, not on container images, external services such as databases and SMTP relays, or the admin consoles |
| Audit logs across Nextcloud, Nubus and mail | Logs of authentication, administrative and file access events, retained and centrally searchable, with a named review process | Logs stay in each application, clock sources differ between components, or mail transport logs are not retained with user identity |
| WCAG 2.1 AA test results | Accessibility test results for each user-facing component against WCAG 2.1 Level A and AA, with a remediation plan for gaps | Testing limited to the front page, bundled third-party widgets excluded, or no record of fixes after upgrades |
| NIS2 supply chain evidence | Signed Helm charts, pinned image digests, a software bill of materials per release and a record of who approved each upgrade | Images pulled by floating tags, no signature verification step, or component license and version inventory kept in spreadsheets |
| Upgrade and patch records | Change records showing each minor or patch release tested in a non-production environment before rollout | Skipped minor releases without documented intermediate steps, or Nextcloud major upgrades run without a pre-upgrade backup |
What to ask an implementation partner for a government workplace
Has the partner run openDesk in a government data center before?
Ask for named references you can contact, or at least a written description of past openDesk deployments in government or regulated environments, including the hosting model and the team that operated them. openDesk runs on Kubernetes and expects external production-grade services such as PostgreSQL, MariaDB, Redis, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, so ask who designed and operated each of those. Confirm how the partner handles a government data center that restricts outbound internet access, since that changes how images, charts and updates reach the cluster. DeployOpen's role is to plan, implement, harden, document and support self-hosted open-source platforms inside the client's own infrastructure, so ask for the exact scope of that work in writing.
How does the partner handle openDesk Enterprise Edition for production?
The partner should state in writing whether it recommends Enterprise Edition for your production environment and why. ZenDiS recommends openDesk Enterprise Edition for production, which uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Ask which Enterprise-only features your agency needs, such as the GroupSync and Admin Console or the Nextcloud Guard app, and who holds the license relationship with ZenDiS. Confirm how the partner separates its own implementation work from vendor support, so you know which party answers a patch request. Ask for the licensing terms as a separate line in the quote.
Which open-source versions will you support, and how are monthly minor releases tested?
Ask which openDesk release line the partner will deploy and how long each stays supported. openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand, and only the latest minor version is supported, so an agency that falls behind must catch up. Ask how the partner rehearses each monthly minor release in a staging environment that matches production, and how it handles the case where several minor versions are skipped, since intermediate steps may be needed. Also ask how bundled components with their own licenses, such as Nextcloud, OpenProject and Collabora, are tracked and patched between releases. Request the written release calendar and rollback procedure.
How will you federate identity with our agency directory?
Ask which identity source the partner will connect to, whether that is Active Directory, LDAP, an existing OpenID Connect provider or a federated identity service, and how users and groups will be mapped to roles across the workplace components. For openDesk, ask how the identity layer is configured to federate with an external identity provider and which attributes are matched to user accounts. Ask who owns the directory schema, who approves group changes and how deprovisioning of leavers is tested. For a Nextcloud-centred stack, confirm whether the partner will use the LDAP app, OpenID Connect or SAML. Request a test plan that covers login, group membership, mail address matching and account removal before go-live.
How do you plan Nextcloud upgrades when major releases cannot be skipped?
Nextcloud does not allow skipping major releases, so administrators must upgrade one major version at a time, back up before every upgrade and disable third-party apps until they are confirmed compatible. Ask the partner for its upgrade runbook, including how it builds a staging copy of production, how it tests the apps your agency depends on and how it times each step against the Nextcloud maintenance schedule. Confirm which major versions are currently supported and what the upgrade path looks like from your starting version. Ask who performs upgrades after go-live, how change windows are agreed and whether the upgrade effort sits inside the fixed scope or inside a retainer.
How do you test accessibility against WCAG 2.1 AA before go-live?
Ask for a written accessibility test plan that covers each user-facing component in scope, the test tools and the criteria used. Public-sector web content and mobile apps, including content provided through contracts or licenses, must meet WCAG 2.1 Level A and AA under the ADA Title II rule, with compliance dates of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Ask whether the partner tests with assistive technology, how it reports defects, and whether it retests after component updates. Clarify whether accessibility fixes in bundled upstream components are your responsibility, the partner's or the vendor's. Confirm that the partner prepares evidence for your assessors rather than issuing any conformance statement itself.
What evidence pack will you produce for assessors?
Ask for a list of the artifacts the partner will hand over, such as the system architecture and data flow diagrams, the control mapping to your chosen baseline, configuration baselines, vulnerability scan results, patch and upgrade records, backup and restore test records, access review outputs and logs of administrative actions. Relevant frameworks include NIST SP 800-53 Rev. 5 control baselines, FedRAMP for cloud services that handle federal information, and CJIS Security Policy where criminal justice information is involved, so confirm which of these apply to your agency. Ask who will answer assessor questions after handover. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications, so ask how independent auditors will be engaged.
What is fixed scope and what should we expect from a retainer?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the partner to list what is in that fixed scope, such as design, installation, identity integration, hardening, data migration, documentation and handover, and what is excluded. Ask separately what ongoing support, upgrades and continuous testing would cost under a retainer, and which monthly minor releases, security patches and major upgrades it covers. The quote should show one-time implementation costs separately from recurring operations costs, including any vendor subscriptions that you buy directly. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope.
How DeployOpen scopes and supports a government workplace
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted workplace platforms inside the ministry's, state's or municipality's own infrastructure: its government data center, its approved cloud tenancy or an isolated network. The work starts with a written scope that names the components in play (for example, the openDesk namespaces or the Nextcloud, Stalwart and Mattermost services of a Nextcloud-centred stack), the identity source each one authenticates against, the Kubernetes platform and external services that will host them, and the acceptance tests that close each phase. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing before any hardening or migration begins. Ask any partner for the same document before signing, and check whether it names who operates the external PostgreSQL, object storage, SMTP relay and antivirus services, since those are often where public sector projects stall.
Once the platform is running, the support model matters as much as the build. Hardening covers the configuration each component exposes, such as administrative interfaces, audit logging, session policies and the trust relationships between components, and it should be re-tested after every upgrade. DeployOpen runs security testing of applications, APIs, infrastructure and AI features in the same environment, so findings can be tied back to the configuration that caused them. For compliance, DeployOpen prepares systems, controls and evidence for assessments that your agency or an independent auditor will run, but it does not issue audit reports, attestations or certifications. Ask each bidder which evidence it will hand over, in what format, and who signs off on it. Ongoing upgrades, patch handling and support are available as retainers, which suits platforms that receive frequent minor releases and must stay on supported versions.
