Should you self-host Onyx or use Onyx Cloud?
The short answer: choose Onyx Cloud when your company documents and AI queries can live in a managed service that your security and legal teams approve, and choose self-hosted Onyx when they cannot. Data sensitivity, not feature set, is the deciding factor, because the open-source Onyx Community Edition and the managed service cover the same core assistant and search job. Onyx Cloud fits teams that want to start quickly and do not want to own databases, index clusters, model servers and upgrades. It matters most when your data classification allows a vendor-hosted service and no residency rule forces the workload into your own accounts. Before you sign, confirm with Onyx the hosting region, subprocessors, encryption arrangements and which certifications actually cover the managed service, since those answers are not part of this comparison.
Self-hosted Onyx fits when the rules on where data may sit are strict. The deployment can run inside your cloud account, data center or an air-gapped network, using the self-contained services Onyx documents, including Postgres, Vespa or OpenSearch for the index, Redis and model servers. It also matters when you want local models through Ollama or vLLM so that prompts and document content never leave your environment. The cost of this choice is operational: your platform team owns sizing, backups, upgrades, monitoring and the connector credentials that sync permissions from SharePoint, Google Drive, Confluence or Slack. Ask your DeployOpen or internal team to estimate that ongoing effort against your own infrastructure before comparing it with a managed subscription, because the quote depends on scope, not on a list price.
A useful middle step is to map each data source against your rules before deciding. Public or low-sensitivity wikis may be acceptable in Onyx Cloud, while regulated customer records, source code or export-controlled material may require self-hosting with local models. If you are not sure which group a connector falls into, treat it as restricted until classification says otherwise. Also check whether Onyx Cloud supports the connectors and permission sync you need, and whether a self-hosted Enterprise Edition license is required for SSO, SCIM and role-based access control in your setup. Writing these answers into a decision record makes the trade-off visible to the CISO and to procurement, and it gives you a clear exit path if your classification changes later.
How self-hosted Onyx and Onyx Cloud compare on the factors that matter
This table compares Onyx Cloud with self-hosted Onyx on control, infrastructure, identity, local models, air-gap capability, licensing and upgrade ownership. Read each row as a question to settle with Onyx against your own data sensitivity and staffing, since the sensitivity of your data usually decides the first rows.
| Factor | Onyx Cloud | Self-hosted Onyx |
|---|---|---|
| Control and data location | Onyx runs the managed service; confirm with Onyx where indexed content and chat data are stored and processed | Runs inside your own cloud accounts, data centers or air-gapped networks, so you decide where indexed data lives |
| Deployment options | Managed by Onyx; no deployment method is chosen by you | Docker, Kubernetes, Helm or Terraform, per the Onyx README |
| Standard vs Lite infrastructure | Confirm with Onyx which Standard or Lite footprint applies to the managed service | Standard runs Postgres, Vespa or OpenSearch, Redis, model servers and object storage; Lite drops the vector database and background workers |
| Connector permission sync | Onyx documents that it syncs source permissions for its 50+ connectors; confirm the same behavior for your sources | Onyx syncs source permissions so answers only draw on documents the user can already see; you operate the connectors and sync workers |
| Local model support | Confirm with Onyx which local model routes are available in the managed service | Supports Ollama, LiteLLM and vLLM for self-hosted models alongside proprietary providers |
| SSO and SCIM | Confirm with Onyx which identity features apply to your plan | OIDC or SAML SSO, Google OAuth and SCIM provisioning are Enterprise Edition features, per the Onyx README |
| Air-gap capability | Not applicable to a managed service hosted by Onyx | Documented as air-gappable, with the index, database and processing inside a self-contained set of services |
| Licensing | Managed service terms apply; confirm contract terms with Onyx | Community Edition is MIT licensed; code in ee directories needs the Onyx Enterprise License |
| Who maintains upgrades | Onyx operates the service and its upgrades; confirm the change and maintenance windows in writing | Your team or a services partner applies releases such as v4.9.2 and Helm chart updates, so plan upgrade effort |
What data location and access control change for your compliance file
Where documents and the index live, who can read them, and what logs survive are the points an assessor will test first. The cards below set out what changes between Onyx Cloud and a self-hosted Onyx, and what to verify before you describe either in a control narrative.
Where documents and the index live
In a self-hosted Onyx, the document index (Postgres, Vespa or OpenSearch), Redis, model servers and object storage run inside your own cloud account, data center or air-gapped network. In Onyx Cloud, those components sit in the vendor's managed environment, so your data residency statement depends on that hosting arrangement. Ask the vendor which regions, subprocessors and storage locations apply, and whether any model inference leaves your boundary when a proprietary provider is configured.
Permission sync limits answers
Onyx syncs permissions from connected applications, so an answer should only draw on documents the user can already see in the source system. This is the control that matters most for a file review, but it is only as good as the sync. Test it with a user who lacks access to a restricted SharePoint site or Confluence space, and confirm that sync frequency and any permission-change lag are documented for both deployment models.
Identity integration and RBAC
Google OAuth, OIDC and SAML sign-in, SCIM user provisioning and role-based access control are listed as Enterprise Edition features, so a self-hosted Enterprise deployment and Onyx Cloud need separate checks. Confirm which of these the Cloud tier provides, how deprovisioning reaches the index, and whether group roles map to the access rules your policy requires. Ask for the license terms in writing before you rely on them.
Audit trail of queries and usage
Query history auditing and usage analytics are listed among Onyx's enterprise features. For an assessor, the questions are who can export these logs, how long they are retained, and whether they reach your SIEM. In a self-hosted deployment, you control retention and storage; in Onyx Cloud, ask where logs are kept, how long they persist and how you obtain them for an investigation or audit sample.
Hosting arrangements and your evidence
Onyx Cloud changes who operates the controls, so your evidence has to show the split of responsibility between you and the vendor. Request the vendor's current compliance documentation and any independent audit reports it holds, then map each control to the party that performs it. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications. Auditors and certification bodies make the final determination.
Which deployment fits your environment and sensitivity level
When policy or contract says certain records cannot be sent to a third party, the hosting question comes before any feature comparison. Onyx Cloud runs as a managed service operated by Onyx, so the question becomes whether your data-handling terms, subprocessors and data location fit your obligations. A self-hosted Onyx keeps the document index, database and processing inside infrastructure you control, which is the usual reason regulated teams choose it.
- Data location: Self-hosting places the index, Postgres database and object storage in your cloud account or data center.
- Model routing: If prompts must stay local, pair self-hosted Onyx with Ollama or vLLM rather than a proprietary provider.
- Permission sync: Onyx syncs source permissions, so confirm that the connectors you need keep access rules intact in your environment.
- Identity controls: SSO through OIDC or SAML, SCIM provisioning and RBAC are listed as Enterprise Edition features, so budget for that license if you need them.
- Operating ownership: You, or a partner such as DeployOpen, own patching, backup and evidence collection under self-hosting.
Confirm with your data protection and compliance leads which systems of record may be indexed, where logs and query history are stored, and whether your auditor expects evidence from the vendor or from your own environment.
Disconnected networks rule out any hosted service, so the only option to evaluate is a self-hosted Onyx. Onyx documents an air-gappable deployment in which the document index, database and processing run within a self-contained set of services. Deployment can use Docker, Kubernetes, Helm or Terraform, so the packaging path depends on what your enclave already runs.
- Model location: Local models through Ollama, LiteLLM or vLLM keep inference inside the enclave. Proprietary providers such as Anthropic, OpenAI and Gemini require outbound connectivity that a true air gap will not allow.
- Connector reach: Connectors to SharePoint, Confluence or Jira need network paths to those systems, so an air-gapped site usually indexes only systems hosted inside it.
- Updates: Images, Helm charts and model files must be transferred in through an approved process, which adds a recurring step to every upgrade.
- Dependencies: Postgres, the chosen index (Vespa or OpenSearch), Redis and model servers all need to be mirrored or built inside the enclave.
- Hardware: Local inference needs GPU or CPU capacity sized for your model choice, which you should size with the vendor before procurement.
Confirm with the site team whether the enclave permits any inbound media transfer, who signs off on each transfer, and how often a patched release must reach the site.
Some teams want the assistant and search working quickly and have no platform engineers to run an index, a database and model servers. Onyx Cloud is the managed option, and it removes the infrastructure build from your side. The trade is that your team depends on the vendor's operations, release timing and data terms, rather than on its own change calendar.
- Operations: Hosting, scaling and upgrades for the service are handled by the vendor, so your internal effort is mostly connector setup and access policy.
- Data terms: Review where data is processed and stored, retention for indexed content and query history, and how deletion works when a connector is removed.
- Identity: Confirm how the managed service connects to your identity provider and whether the plan includes the SSO and provisioning features you need.
- Exit path: Ask how you would export indexed content, settings and user data if you later move to self-hosting.
- Pricing model: Cloud pricing is set by the vendor's plan, so ask for the written scope and what changes as user counts or connectors grow.
Confirm the service's data residency and subprocessor list with your legal team, and ask for a written statement of how incidents and maintenance windows are communicated.
Many organizations hold a mix of public wikis, internal documents and restricted repositories. A single deployment choice may not fit every source, so it helps to split the estate by sensitivity before choosing where the index lives. Onyx connects to more than 50 applications, and its permission sync limits answers to documents each user can already see in the source system.
- Classification first: Label sources as public, internal or restricted, and decide which tier may be indexed in a managed environment.
- Separate instances: Some teams run a self-hosted instance for restricted sources and a managed instance for low-sensitivity content, which doubles administration and access reviews.
- Connector scope: Index only the spaces, sites or projects that the assistant needs, to reduce the data that a single instance holds.
- Permission fidelity: Test that a user who cannot open a restricted page cannot retrieve its content through chat, using accounts from each group.
- Consistency: Two deployments may run different versions, so track release levels and connector behavior for each.
Confirm with your data owners which sources they will allow in each environment, and whether splitting the estate creates a second audit scope that your compliance team must document.
Onyx Standard or Onyx Lite: what the self-hosted footprint actually contains
The first decision in a self-hosted Onyx build is which deployment profile to run. Onyx Standard carries the full stack: a vector and keyword index (Vespa or OpenSearch), Postgres, Redis, background sync workers, model inference servers and object storage. Onyx Lite is a lighter chat and agents deployment with no vector database and no background workers. The difference is not cosmetic. Standard is the profile that ingests documents, keeps them current and enforces who can see what, while Lite gives you a chat front end without that retrieval layer. Confirm the exact service list for your chosen version in the Onyx deployment overview before you size hosts, because the components documented there are the ones your operators will have to patch, back up and monitor.
Lite removes connector sync, and that has a direct consequence for access control. Permission-aware retrieval from SharePoint, Google Drive, Confluence, Slack and similar sources depends on the sync workers and the index that Standard provides. Onyx's README states that answers draw only on documents the user can already see in the source application, and that behavior comes from the synced permissions, not from the chat layer. If your use case needs answers grounded in connected company systems, Lite is the wrong profile and the Standard footprint is the baseline to cost. If users only need a model-backed chat without company document retrieval, Lite may be enough, but confirm that no connector is expected to run later, because adding one means moving to Standard.
The tradeoff is operating load against retrieval scope. Standard adds stateful services that need capacity planning, backup and upgrade testing for the index and the database, and its model inference servers consume memory or GPU capacity that a chat-only deployment may not need. Ask your Onyx partner or Onyx itself to provide the component list, resource requirements and upgrade path for the version you plan to run, and to state which services are required for air-gapped operation. Those answers, not the marketing labels, should set the infrastructure budget and the staffing plan.
What your team runs in each model and where the effort lands
This table compares who provisions, upgrades, backs up, scales, monitors and responds to incidents for Onyx Cloud and for a self-hosted Onyx deployment, including connector credentials. Read each row as a split of duties: the vendor side is what Onyx Cloud operates, and the customer side is what your own staff or a services partner must staff and keep running.
| Responsibility | Onyx Cloud | Self-hosted Onyx |
|---|---|---|
| Infrastructure provisioning | Onyx operates the managed environment; your team mainly configures tenant settings and identity | Your platform team provisions cloud, data center or air-gapped hosts, Kubernetes or Docker, and the Onyx services, using the Docker, Kubernetes, Helm or Terraform paths the project documents |
| Upgrades | Onyx applies platform releases; confirm the timing and any customer notice in your agreement | Your team tracks releases such as Onyx v4.9.2 (October 15, 2026) and Helm chart 0.9.17, tests them in staging and schedules the rollout |
| Backups and recovery | Confirm in writing which backups Onyx takes, retention, and how you request a restore | Your team backs up Postgres, the Vespa or OpenSearch index, object storage and any Redis state, and tests restores |
| Scaling index and model servers | Capacity changes are handled by the vendor; ask how scale-up requests and limits are managed | Your engineers size the index, sync workers and model inference servers; the index and model servers usually drive hardware sizing |
| Connector credential management | Your admin authorizes source connectors; confirm where credentials are stored and who can rotate them | Your security team stores, rotates and revokes connector credentials for SharePoint, Confluence, Jira, Slack and other sources, and checks that permission sync still works after rotation |
| Monitoring and logging | Onyx monitors the managed service; ask what telemetry you can export to your SIEM | Your operations team monitors services, queues, index health and sync jobs, and forwards logs to your own tooling |
| Incident response | Shared model: confirm severity levels, response windows and your escalation contacts in the written scope | Your on-call and security staff lead response; a services partner supports only if the retainer covers it |
Moving data and users between Onyx Cloud and self-hosted Onyx
This sequence shows how to move an Onyx deployment's connectors, indexed content, permissions and users in either direction, and how to confirm that access still matches the source applications before users are cut over. The migration path and export options must be confirmed with Onyx for the version you run.
Inventory connectors and permission mappings
List every connector in the current deployment, including the source application, the account or service identity it authenticates with, the scope of documents it indexes and how permissions are mapped to Onyx users and groups. Confirm with Onyx which connector configurations can be exported and which must be recreated by hand in the target environment. The step closes when the team has a written register that a reviewer from the data owner's side has signed off on.
Confirm the migration path with Onyx
Ask Onyx, in writing and against the exact release you run, whether a managed-to-self-hosted or self-hosted-to-managed move is supported, what data export options exist for the database, object storage and index, and whether chat history and user settings transfer. Record the answers with the version number. Do not assume a path that the vendor has not confirmed for that release. The step closes when the migration scope is agreed in writing with Onyx and with your own change board.
Rebuild identity, SSO and SCIM provisioning
Recreate the identity configuration in the target environment: the SSO method (Google OAuth, OIDC or SAML), redirect URIs, role mappings and SCIM provisioning from your identity provider. Users should not be created by hand if SCIM is in use, because manual accounts can drift from the directory. Confirm which SSO and SCIM features are included in your edition before building them. The step closes when test users from each role can sign in and their group memberships match the directory.
Re-index content and re-sync permissions
Run a full re-index of each connector in the target environment, then run a permission sync for each source. Re-indexing and permission re-sync are where most verification effort lands, because the migrated index must reflect current source permissions, not the permissions captured at export. Schedule the sync windows with the application owners so that revoked access is not missed. The step closes when every connector reports a completed run with no unresolved errors in its logs.
Validate permission sync against source applications
Pick a sample of documents from each connector and compare who can see them in the source application with who can retrieve them through Onyx. Include at least one restricted document, one document shared through a group and one document whose access was removed recently in the source. Log every mismatch and fix the mapping before cutover. The step closes when the sample shows no access that the source application would deny, and the test record is filed for your auditors.
Cut over users and model connections
Move users to the new endpoint at an agreed time, and update any model provider keys, Ollama or vLLM endpoints and LiteLLM routes that the deployment depends on. Keep the previous environment read-only until the new one has run through a full business cycle without access defects. The step closes when the support queue shows no permission or sign-in issues for the agreed monitoring period and the cutover record is complete.
Decommission the source environment
Revoke connector credentials in the source environment, delete or archive indexed content according to your retention policy, remove stored secrets and close administrative accounts. Confirm with Onyx how data is deleted from managed infrastructure and request written confirmation. Keep the export and validation records under your own retention rules. The step closes when credentials are revoked, the deletion confirmation is on file and the source environment is removed from your asset inventory.
What drives the cost of each option and what to ask for in a quote
Onyx Cloud is a recurring subscription, while self-hosted Onyx moves cost into infrastructure, model usage and labor. For Onyx Cloud, the subscription covers the managed service, and the exact current pricing has to be confirmed directly with Onyx. Onyx publishes a Business price, which can serve as a reference point when you compare, but it is not a substitute for a current quote. For self-hosted Onyx, the license terms decide what you pay Onyx for. The Onyx Community Edition is MIT licensed, while code in the ee directories falls under the Onyx Enterprise License, so SSO, SCIM, RBAC and query auditing require a license decision before go-live. Infrastructure is paid to your cloud provider or data center for the Standard services: Postgres, Vespa or OpenSearch, Redis, model servers and object storage. Lite reduces that footprint but drops the vector database and background workers, so confirm which connectors and sync features you need before you choose it.
Separate one-time setup from recurring operation, because the upgrade cadence drives most of the long-term labor. Setup covers deployment, connector configuration, permission sync validation, identity integration, hardening and documentation. Recurring costs include infrastructure, model provider or GPU capacity for local models through Ollama or vLLM, Enterprise License fees if applicable, and staff time for upgrades, backups and connector maintenance. Onyx publishes frequent releases, including v4.9.2 on October 15, 2026, and a Helm chart at version 0.9.17 as of October 16, 2026, so ask who tests each upgrade and who owns rollback. Internal labor (security, platform and application owners) and external labor (DeployOpen or another implementation partner) should be shown as separate lines in any estimate.
A DeployOpen scoping quote is only comparable if it is written and specific, so request these items before you sign. Ask for a written scope listing each connector and the permission model it must honor, the deployment target (cloud account, data center or air-gapped network), the model providers in use and how they are reached, support hours and response expectations, and who performs each upgrade, backup test and Enterprise License administration task. Ask whether the quote is one-time, a retainer for ongoing support and continuous testing, or both. DeployOpen fixed-scope engagements agree scope, deliverables and timelines in writing before work starts, so the quote should list what is excluded as well as what is included. Ask Onyx separately to confirm current Cloud pricing and which features require the Enterprise Edition.
Questions buyers ask before choosing Onyx Cloud or self-hosting
Can a small team self-host Onyx without a dedicated platform engineer?
Possibly, but only if one named person can own the stack after go-live. Onyx Standard runs Postgres, Vespa or OpenSearch, Redis, model servers, object storage and background sync workers, so someone must handle container or Kubernetes operations, upgrades, backups and index health. Onyx Lite drops the vector database and background workers, which shrinks the operating surface, but it also removes the vector index and connector sync that make Onyx useful for document search. Decide the deployment first, then check whether your team can cover those duties. Onyx documents Docker, Kubernetes, Helm and Terraform paths, and the Helm chart was at version 0.9.17 as of October 16, 2026, so confirm which path your platform team already runs. If the duties have no clear owner, a fixed-scope implementation with ongoing support from DeployOpen can cover setup and upgrades, agreed in writing first.
How long does a self-hosted Onyx setup take, and what drives it?
Setup time depends on scope, and no standard duration applies to every environment. Ask Onyx and any implementation partner for a timeline only after the scope is written. The main drivers are:
- The number and type of connectors, since each source has its own credentials, permission model and testing.
- Identity integration, whether Google OAuth, OIDC or SAML, plus SCIM provisioning if you need automated user lifecycle.
- The model path, whether Ollama, vLLM, LiteLLM or a hosted provider, and whether models must run inside an isolated network.
- Infrastructure readiness, including the container or Kubernetes platform, storage, backups and network approvals.
- The volume of content to index and how much permission validation your security team requires.
Ask for milestones, the dependencies on your own teams, and a clear list of what is out of scope. DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Do local models through Ollama or vLLM work without internet access?
Yes in principle, because Onyx supports self-hosted models through Ollama, LiteLLM and vLLM, and documents an air-gappable deployment in which the index, database and processing run in a self-contained set of services. Air-gapped operation still depends on staging everything inside the network beforehand: model weights, container images, Helm charts and any packages the services fetch at startup. Hosted providers such as Anthropic, OpenAI and Gemini will not answer from an isolated network, so they only fit connected deployments. Confirm with Onyx which components make outbound calls at runtime, including telemetry and update checks, and test the full stack with egress blocked before you sign off. Keep the model server version and the model file list in your change records so an offline upgrade can be repeated.
Does connector permission sync survive a migration to a new deployment?
Onyx syncs source permissions so that answers draw only on documents the user can already see in the source application, which is the core reason to keep permissions in the migration plan. Whether permission state and index data carry over when you move between Onyx Cloud and a self-hosted instance is a question to put to Onyx directly. Ask whether the index migrates or re-indexes, whether connectors need fresh authentication, and whether permissions re-sync from each source at first run. Build a pilot before cutover: pick several users across groups, list the documents each can see in the source app, and compare that with what Onyx returns. Connector credentials usually belong to service accounts, so plan their rotation and owner as part of the migration.
Can Onyx Cloud meet our data residency rules?
Confirm this with Onyx before you choose, because residency depends on the region options, subprocessors and data locations Onyx states for its managed service. Ask for the location of the index, the database, logs, backups and any model provider calls, plus how each subprocessor is used. Self-hosting places the deployment in your cloud accounts, data centers or air-gapped networks, which gives you direct control over where the data sits. It does not, by itself, settle residency, because model calls to hosted providers still leave your environment unless you route them to local models. DeployOpen plans and implements self-hosted deployments inside client infrastructure, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies provide those, so ask them which evidence they need.
Which SSO and RBAC features need the Onyx Enterprise Edition license?
Onyx lists Google OAuth, OIDC or SAML single sign-on, SCIM user provisioning, role-based access control, usage analytics and query history auditing among its enterprise features. The Community Edition is MIT licensed and covers chat, RAG, agents and connectors, while code in the ee directories falls under the Onyx Enterprise License. The Onyx deployment documentation describes the Enterprise Edition as a self-hosted option with premium features such as RBAC. Because feature placement can change between releases, check the current README and LICENSE against the version you plan to deploy. Ask Onyx to confirm in writing which features your license covers, which terms apply to upgrades, and how renewals are priced before you commit to a design that depends on them.
Can DeployOpen run a self-hosted Onyx deployment or help migrate to it?
Yes, DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Onyx, that could cover the deployment path, connector and identity setup, permission validation during a move from Onyx Cloud, cutover and runbooks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen is not an official Onyx partner, reseller or certified provider unless that status is stated separately, so verify any vendor relationship you need directly with Onyx.
How does the cost of Onyx Cloud compare with running Onyx yourself?
The two models shift different costs, so compare them line by line rather than by headline price. Onyx Cloud is a managed service, so the recurring fee covers hosting and operation, and your team handles configuration and user management. Self-hosting shifts the recurring cost to your infrastructure, the staff time to operate upgrades and backups, any hosted model usage, and an Enterprise Edition license if you need its features. One-time costs include implementation, connector setup and migration testing. Cost rises with the number of connectors, identity complexity, compliance evidence needs and how often you upgrade. Ask Onyx for its current Cloud and Enterprise terms in writing, and ask DeployOpen for a quote based on a written scope so both options are priced on the same assumptions.
How DeployOpen scopes, deploys and supports self-hosted Onyx
DeployOpen starts from your data sensitivity, identity model and connector list, then agrees a written scope before any work begins. We plan, implement, integrate, harden, document and support self-hosted Onyx inside your own cloud accounts, data centers or air-gapped networks, so the deployment choice follows your requirements rather than a default.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We map which applications, connectors and permission sync paths your users need, and which data may leave your boundary.
- We confirm model choices, including Ollama, vLLM, LiteLLM or proprietary providers, and where each one runs.
How we build
- We deploy the Standard or Lite configuration you choose, with Postgres, the Vespa or OpenSearch index, Redis and model servers as scoped.
- We wire SSO, SCIM provisioning and RBAC only where your license tier covers them, and we verify permission sync against source applications.
- We test access controls, connector behavior and air-gapped operation, then harden the environment for your security baseline.
How we hand over
- You receive documentation covering architecture, configuration, connector setup, backup and upgrade steps.
- We prepare the evidence and control records your compliance assessors need, without issuing any audit report or certification.
- Your team gets a walkthrough of operations so the handover is tested by the people who will run the system.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Upgrades to new Onyx releases are planned and tested against your connectors and identity configuration before rollout.
- Confirm with us which Onyx license tier your scope assumes, since premium features depend on it.
