When Wazuh Cloud fits and when self-hosted Wazuh fits
Choose self-hosted Wazuh if your data must stay inside infrastructure you control, if your team needs shell access to the server or indexer, or if you need to change the ruleset, decoders or API behavior beyond what a managed service exposes. Choose Wazuh Cloud if you want the vendor to run the platform, your staff cannot absorb ongoing operations, and a dashboard-only workflow with read-only APIs is enough. The self-hosted software carries no license fee because Wazuh server and agent are GPL-2.0, while Wazuh Cloud is a paid managed service priced by agent count and retention tier. You pay for the platform either way, but the cost sits in different places: a subscription with Wazuh Cloud, and staff time, hosting and upgrades with self-hosted Wazuh.
Data location is usually the first constraint. Wazuh Cloud environments run in one of nine listed regions, including Frankfurt, London and North Virginia, so confirm with your data protection and legal owners that the region and any archive copies meet your residency rules. Staff capacity is the second. Wazuh Cloud keeps environments on the latest Wazuh version without manual upgrades, which removes a recurring task, but you lose the ability to run custom server commands or tune the indexer directly. A self-hosted deployment gives you that control and also gives you the upgrade calendar. Patch releases in the 4.14 line have arrived roughly every one to two months, so ask who will own that cadence before you commit.
Retention and exit planning decide the rest. Check the indexed and archive periods on the tier you need, since the published Small tier keeps one month indexed and three months in archive, and confirm whether your audit window requires more. Wazuh Cloud archive data can be downloaded and re-indexed into a local environment but not back into the cloud, so ask the vendor how long a full archive export takes and what it costs before you rely on it as an exit path. If you expect to move later, run a trial on the 14-day free trial with a realistic agent count and test the archive download first.
How Wazuh Cloud and self-hosted Wazuh differ on the factors that matter
This table sets Wazuh Cloud's published tiers against a self-hosted Wazuh deployment on license, price, regions, access, compliance statements, archive handling and upgrades. Read each row with the condition that makes it matter to your team, and confirm any value marked as a quote item before you commit.
| Factor | Wazuh Cloud | Self-hosted Wazuh |
|---|---|---|
| License and fees | Managed subscription billed by agent tier; the service is not open source software you run yourself | Wazuh server and agent under GPL-2.0 with an OpenSSL exception; indexer and dashboard under Apache-2.0; no license fee |
| Published tier prices | Small (up to 100 agents, 1 month indexed, 3 months archive) from $571 per month; Medium (up to 250 agents, 3 months indexed, 1 year archive) from $923; Large (up to 500 agents) from $1,467; Custom tier (source: Wazuh Cloud page) | No Wazuh fee; you pay for hosts, storage, network, staff time and any outside services. Ask your team or a partner to scope these |
| Hosting regions | Nine regions: Tokyo, Mumbai, Singapore, Sydney, Frankfurt, London, Canada, North Virginia and Ohio (Wazuh Cloud technical FAQ) | Anywhere you can run Linux hosts, containers, Kubernetes or a virtual machine, including air-gapped networks |
| Access model | Dashboard and agent communication ports only; no command-line or shell access | Full shell, configuration files, rule and decoder editing, and local API access on your own hosts |
| API access | Server and indexer APIs are off by default and read-only when Wazuh Support enables them | You control API exposure, authentication and write access |
| Compliance statements | Service states it is compliant with PCI DSS and SOC 2 and links to PCI DSS and SOC 2 Type 2 reports; confirm scope with Wazuh | Dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53; your own environment and controls determine any compliance outcome |
| Archive handling | Archive data can be downloaded and re-indexed locally, but cannot be re-indexed into the cloud environment | Archives stay where you store them; confirm your retention and export process with your own tooling |
| Upgrade responsibility | Wazuh keeps environments on the latest Wazuh version with no manual upgrades; the 4.14 line received six patch releases in 2026 | Your team plans and applies upgrades; the 4.14.9 release of October 14, 2026 is the current 4.x release to plan against |
| Support and trial | Standard support on published tiers and a 14-day free trial with no credit card; confirm any higher support level in a quote | Community and documentation by default; any paid support or partner retainer is a separate scope to agree in writing |
Where your data lives and what a compliance assessment will ask
Wazuh Cloud and self-hosted Wazuh place your alert data, administrative access and evidence in different hands. The cards below cover where the data sits, what the managed service lets you touch, and what an assessor will ask to see in each model.
Choosing among the nine cloud regions
Wazuh Cloud environments are offered in nine published regions: Tokyo, Mumbai, Singapore, Sydney, Frankfurt, London, Canada, North Virginia and Ohio. Confirm with Wazuh which region holds your indexed alerts and archives, whether backups replicate across regions, and whether any data leaves the region for support or updates. A self-hosted deployment keeps the data in your own cloud account, data center or air-gapped network, so the location question becomes one of your own network design.
Dashboard-only access on the managed service
Wazuh Cloud users work only through the Wazuh dashboard and agent communication ports, with no command-line or shell access. The server and indexer APIs are off by default and read-only when Wazuh Support enables them. Self-hosted Wazuh gives your administrators shell access, write access to rules and decoders, and direct control over the indexer. Check whether your procedures need that access for change control, incident response or custom detection work.
Reading the PCI DSS and SOC 2 claims
The Wazuh Cloud page states that the service is compliant with PCI DSS and SOC 2 and links to PCI DSS and SOC 2 Type 2 reports. Those reports cover Wazuh's controls for the managed service, not your own environment, agents or configuration. DeployOpen does not issue audit reports or attestations, so ask your assessor which provider reports they will accept and which of your controls remain your responsibility.
Mapping shared responsibility controls
In the managed model, your evidence for access control, logging, change management and vendor oversight comes partly from Wazuh's reports and partly from your own records of agents, users and alert handling. In a self-hosted model, you produce the evidence for infrastructure, patching, backups and configuration yourself. Build a control matrix that names the owner of each control before the assessment starts, and confirm the scope of Wazuh's reports against it.
Retrieving archives for local review
The Wazuh Cloud technical FAQ states that archive data can be downloaded and re-indexed into a local environment, but cannot be re-indexed into the cloud environment. This gives you a path to keep evidence on premises, but it is a one-way copy. Ask how long downloads take for your archive volume, what format they arrive in, and how you prove that the local copy is complete and unaltered for an examiner.
Retention and evidence custody
Published Wazuh Cloud tiers set indexed and archive retention periods, so the retention your assessor requires may not match the tier you buy. Write down which retention period your control set needs, who holds the evidence during an audit window, and what happens to data when a subscription ends. Confirm each of these in writing with Wazuh before you sign, because the answers determine whether the managed service meets your evidence needs.
Which features each model gives you
Wazuh Cloud is delivered as a managed service, and customers work through the Wazuh dashboard and the agent communication ports. Users do not get command-line or shell access to the environment, so day-to-day work happens in the web interface and in the agents deployed on endpoints. The service keeps environments on the latest Wazuh version, which removes manual upgrade planning from your team's calendar.
- Dashboard-only work: Analysts investigate alerts, build views and manage agents from the Wazuh dashboard without a server login.
- Agent ports: Endpoints communicate with the managed environment over the agent communication ports, so agent network paths must be planned for each site.
- Latest version kept current: The published tiers include environments kept on the latest Wazuh version with no manual upgrades.
- Standard support: The published tiers include Standard support, and the scope of that support is defined in the vendor's terms.
- Limited API surface: The server and indexer APIs are off by default and read-only when Wazuh Support enables them.
Confirm with Wazuh which custom integrations, scripts or config changes your team needs, since anything that requires shell access will not be available on the managed service.
A self-hosted Wazuh deployment runs inside your own infrastructure, so your team holds shell access to the server, indexer and dashboard hosts. You decide when to change configuration, which decoders and rules to add, and how the server and indexer APIs are used. Because the software is open source with no license fee, the operational work of running it sits with your staff or with an implementation partner.
- Shell access: Engineers can edit configuration, review logs and troubleshoot each component directly.
- Open APIs under your control: Server and indexer APIs can be enabled, scoped and integrated with your own tooling.
- Offline installation: The offline installation guide covers systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository.
- Automation options: Ansible and Puppet are documented deployment options, alongside Docker and Kubernetes.
- Custom rules and decoders: Your team can extend the ruleset for internal applications and data sources.
Before committing, confirm who will apply patch releases, how often your team can take maintenance windows, and which staff will own the platform after go-live.
Wazuh documents several installation paths, and the choice affects who builds and maintains the underlying hosts. The all-in-one and step-by-step installations, the prebuilt OVA, the Amazon Machine Image, Docker, Kubernetes, installation from sources, Ansible and Puppet each suit a different platform team. A managed service removes this choice entirely, while a self-hosted deployment requires you to pick one path and support it over time.
- Packaged install: The all-in-one and step-by-step installations suit teams that manage Linux hosts directly.
- Virtual and cloud images: The prebuilt OVA and Amazon Machine Image shorten first-time setup on virtualization or AWS.
- Containers and orchestration: Docker and Kubernetes fit teams that already run container platforms.
- Configuration management: Ansible and Puppet fit teams that standardize hosts through code.
- Offline and source builds: The offline guide and source installation support air-gapped or tightly controlled environments.
Check which deployment method your platform team already supports, since the operating burden of each method differs.
The Wazuh ruleset ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK. The dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. These capabilities are documented for the platform generally, so they apply to the self-hosted product and should be verified for the managed environment against the current Wazuh Cloud documentation before you rely on them.
- Built-in rules: Over 3,000 rules and decoders cover common log sources and alert conditions.
- MITRE ATT&CK mapping: Alerts are mapped to ATT&CK techniques for triage and reporting.
- Compliance dashboards: Prebuilt views exist for PCI DSS, GDPR, HIPAA and NIST 800-53.
- Custom content: Self-hosted teams can add decoders and rules for their own applications.
- Vendor attestations: The managed service's PCI DSS and SOC 2 statements are separate from whether a dashboard view satisfies your own assessment.
Ask your assessor which evidence they need, since a dashboard view is not an audit report and a compliance framework is not satisfied by a tool alone.
The right model depends on who runs the platform and what your team must be able to change. A managed service suits teams that want the vendor to keep the platform current and prefer dashboard work to host administration. A self-hosted deployment suits teams that need shell access, custom integrations, offline operation or direct control of the APIs. Both models use the same agents and core product, so the decision rests on operations and control rather than on detection content.
- Managed fit: Small teams without platform engineers often prefer the dashboard-only model.
- Self-hosted fit: Teams with air-gapped networks or custom integrations usually need shell and API access.
- Upgrade ownership: The managed service handles upgrades, while self-hosted teams plan and test them.
- Data location: Archive data can be downloaded and re-indexed locally, but not back into the cloud environment.
- Support scope: Compare the support included in each tier with the support you would buy for self-hosting.
Before deciding, document which changes your team must make without vendor involvement and test that list against the managed service's limitations.
What Wazuh Cloud costs and what self-hosting costs in practice
Wazuh Cloud publishes starting prices by tier: Small at $571 per month covers up to 100 agents with 1 month indexed and 3 months archive retention, Medium at $923 covers up to 250 agents with 3 months indexed and 1 year archive, and Large at $1,467 covers up to 500 agents with the same retention as Medium. A Custom tier sits above these. The Wazuh Cloud page presents these as starting prices, so treat them as a floor, not a quote. Self-hosted Wazuh carries no license fee because the server and agent are GPL-2.0 and the indexer and dashboard are Apache-2.0, but that does not make it free to run. The cost moves to your infrastructure, storage for indexed alerts and archives, upgrades, and the staff who maintain the four components.
Self-hosting costs recur in several places. You pay for the hosts or cloud instances that run the Wazuh indexer, server and dashboard, and for disk sized to your retention targets, since indexed alerts and archives grow with agent count and event volume. Upgrade effort is also ongoing: Wazuh shipped six 4.14 patch releases in 2026, so someone has to schedule and test each one. Staff time covers rule tuning, agent rollout, backups and on-call response. Wazuh Cloud shifts most of that work to the vendor, including keeping environments on the latest Wazuh version without manual upgrades, but you give up shell access and rely on a read-only API unless Wazuh Support enables more.
When you request a quote, ask for the agent count and growth assumptions behind the tier, the indexed and archive retention each price covers, the regions you need from the nine available, what Standard support includes and its response expectations, and what the Custom tier adds. Ask whether archive data can be downloaded and re-indexed locally, since the Wazuh Cloud technical FAQ says it cannot be re-indexed into the cloud environment. Use the 14-day free trial, which requires no credit card, to measure real alert volume before committing. For the self-hosted side, build a costed model with your own hosts, storage, and staff hours, and confirm your compliance evidence needs with the Wazuh Cloud compliance reports and your assessor.
What your team runs in each model
This table shows who performs each operational task under Wazuh Cloud and under a self-hosted Wazuh deployment, with ownership marked as vendor, your team or shared. Read it as a checklist of duties to staff for, then confirm the exact service boundaries in writing before you sign. The main takeaway is that the managed service moves platform operations to the vendor, while self-hosting keeps every operational decision, schedule and log path with your own staff.
| Task | Wazuh Cloud | Self-hosted Wazuh |
|---|---|---|
| Installation and environment setup | Vendor provisions the environment in one of nine hosting regions | Your team (shared with DeployOpen if engaged) installs from packages, OVA, Docker, Kubernetes or offline media |
| Server and indexer upgrades | Vendor keeps environments on the latest Wazuh version with no manual upgrades | Your team, on your own change schedule, tested against your agent fleet |
| Patch cadence (4.14 line) | Vendor applies patch releases; confirm the window and notice period in your contract | Your team reviews each 4.14 patch release and decides when to apply it, with the Wazuh release notes as the source |
| Capacity planning | Shared: you choose the tier by agent count and retention, vendor operates the platform | Your team sizes indexer, server and dashboard hosts and storage for agent count and retention |
| Backup and restore | Confirm with the vendor what is backed up, how long it is kept and how restores are requested | Your team designs, runs and tests backups of indexer data and server configuration |
| Command-line and shell access | None: users work only through the dashboard and agent ports; server and indexer APIs are off by default and read-only when Wazuh Support enables them | Full administrative access to hosts, configuration files and APIs, held by your team |
| Offline vulnerability data | Vendor-managed vulnerability data; confirm how your data residency needs are met | Your team chooses between the Wazuh CTI platform and an offline vulnerability repository for air-gapped networks |
| Archive data access | Archive can be downloaded and re-indexed into a local environment, not back into the cloud | Archive data stays under your control and is re-indexed on your own infrastructure |
Moving data from Wazuh Cloud back on premises
This sequence moves archived Wazuh Cloud alert data into a local Wazuh environment you control, so you can search historical events on premises and decide how live agents will be handled before any cutover.
Confirm archive scope with Wazuh Support
Before any export, ask Wazuh Support which archive data your tier holds, how it is packaged for download, and whether your environment design allows agents to be re-pointed. The Wazuh Cloud technical FAQ documents that archive data can be downloaded and re-indexed locally, but it cannot be re-indexed back into the cloud environment. Record the answers in writing. The step is done when your team has a confirmed list of archive contents and a written decision on agent handling.
Export the archive from the cloud dashboard
Your cloud administrator requests the archive download through the channel Wazuh Support confirms, since Wazuh Cloud users work only through the dashboard and agent communication ports with no shell access. Store the export in a location that meets your data residency and access rules, and record a checksum or inventory of the files. The step is done when the export is stored, the checksum is logged, and someone other than the exporter has confirmed the file count matches what Support described.
Deploy a local Wazuh environment
Your platform team installs a self-hosted Wazuh environment inside your own infrastructure, using a documented deployment option that fits your sizing and network model, such as the offline installation guide for air-gapped networks. The indexer, server and dashboard all need to be running and reachable by your analysts. The step is done when the local dashboard loads, the indexer reports healthy, and the version matches the release line you intend to run.
Re-index archive data locally
Import the downloaded archive into the local indexer so historical alerts become searchable in the local dashboard. Keep the archive copy unchanged so you can repeat the import if a step fails. Check index names, time ranges and document counts against the export inventory, and confirm that dashboards and saved searches display the imported events. The step is done when counts reconcile with the inventory and a sample of known alerts appears with the original timestamps.
Map custom rules and decoders
Compare any custom rules, decoders, and integrations you configured in the cloud environment with what the local server loads. Cloud-managed configuration is not automatically portable, so each item needs a decision: recreate it, adapt it, or retire it. Validate that alerts generated from your rules still fire on test events in the local environment. The step is done when every custom item has a documented disposition and a passing test event.
Re-point agents only after a confirmed design
Moving live agents depends on your deployment design, and the transition must be confirmed with Wazuh Support before a cutover. Agents that report to the cloud manager need a planned change of manager address, communication settings and certificates, applied in batches so monitoring never has a gap. Keep the cloud environment running until the local environment is receiving events from each batch. The step is done when every agent batch shows a recent check-in on the local server and no batch is left reporting to two managers.
Validate detection and retention end to end
Run a set of known test events through a representative agent group and confirm that they produce alerts, appear in the expected dashboards, and carry the correct agent names and timestamps. Verify that your local retention and backup settings match your policy, since the local environment now holds the data retention obligations. The step is done when test events are detected on each agent group, retention settings are written down, and the cloud subscription is scheduled for an agreed end date with Wazuh Support.
Questions buyers ask before choosing a hosting model
What actually drives the effort of running self-hosted Wazuh?
The main drivers are how many agents you run, how long you keep indexed data, and how many components you operate. Wazuh has four central components: the indexer, the server, the dashboard and the agents on endpoints. Each one needs patching, certificate handling, backups and capacity planning on your side. Agent count and retention set the storage and node sizing, so they change the work more than the software does. Patch cadence matters too: Wazuh shipped six 4.14 patch releases between March and October 2026, so you should plan a recurring upgrade window rather than a one-off install. Confirm sizing guidance for your agent count and retention with Wazuh before you commit.
Can a small team run Wazuh on its own?
A small team can run Wazuh without a vendor if it has someone who owns Linux administration, certificate management and the indexer, and who can respond to alerts. Wazuh documents several installation paths, including an all-in-one install, a prebuilt OVA, Docker, Kubernetes, Ansible and Puppet, so the initial build is not the hard part. The harder question is ongoing ownership: tuning rules, keeping the ruleset current, handling agent upgrades and running the on-call process for alerts. If that capacity does not exist in-house, a managed service or an implementation partner for the build and handover may fit better. Ask Wazuh which support tier and documentation your team would rely on.
How long does a migration to Wazuh take, and what does it depend on?
No supplied figure gives a migration duration, so treat any number you hear as a question for the vendor or the implementer. The timeline depends on the number of agents and operating systems, whether you are coming from OSSEC or another SIEM, how many custom rules and decoders you need to carry over, and whether the target environment is air-gapped. Migrating from OSSEC is easier because OSSEC agents can report to a Wazuh server, which lets you run mixed agents during cutover. Moving from a SIEM with different log formats usually means rebuilding parsers and alerting logic. Ask for a written scope that lists agent counts, data sources and acceptance tests before you agree a schedule.
Does Wazuh Cloud meet our compliance needs?
Wazuh Cloud states that the service is compliant with PCI DSS and SOC 2 and links to PCI DSS and SOC 2 Type 2 reports, so start by reading those reports with your assessor. Self-hosting does not remove compliance work: you still need evidence that your own controls around the platform, such as access reviews, change records and backup tests, are in place. The Wazuh dashboard also includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, which help with mapping on either hosting model. Confirm with Wazuh which controls the cloud report covers, where your data resides within the nine regions, and how archive data leaves the service. Your auditor decides whether the evidence is sufficient.
What would an implementation partner scope for a self-hosted Wazuh deployment?
An implementation partner typically scopes the architecture, the build, the integrations and the handover, and each item should appear in a written scope before work starts. Typical items include sizing against your agent count and retention, the deployment method, hardening and certificate handling, agent rollout, custom rules and decoders, dashboards for your compliance frameworks, backup and restore testing, and documentation for your operators. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing. Ongoing support and upgrades can be handled through a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
What can we do with archived Wazuh data if we leave Wazuh Cloud?
Wazuh Cloud archive data can be downloaded and re-indexed into a local environment, but it cannot be re-indexed back into the cloud environment. This matters when you plan an exit or need historical data for an investigation that runs past the indexed retention window. The published tiers list different indexed and archive retention periods, so check which data you can reach directly and which requires the archive path. Before you rely on this route, confirm with Wazuh the format of the download, the size of the archive, the time it takes to restore and whether your local indexer can handle the volume. Test the restore once with real archive data during your evaluation.
What access do we lose with Wazuh Cloud compared with running it ourselves?
On Wazuh Cloud, users work only through the Wazuh dashboard and the agent communication ports, with no command-line or shell access. The server and indexer APIs are off by default and are read-only when Wazuh Support enables them. If your engineers rely on custom scripts, direct indexer queries or local configuration changes, that workflow will not carry over unchanged. Self-hosting gives you shell access, write access to configuration and full control of API use, but it also makes you responsible for securing those interfaces. List the automations and integrations your team uses today, then ask Wazuh which of them the managed service can support before you decide.
When a hybrid approach makes sense
A hybrid approach fits teams that must keep sensitive logs on premises but still want a managed Wazuh environment for a trial or for a limited group of agents. The supplied facts support one clear pattern: archive data can be downloaded from Wazuh Cloud and re-indexed into a local environment, but it cannot be re-indexed back into the cloud. That makes the local Wazuh deployment the place where long-term evidence lives, and the cloud service a place where a subset of endpoints is monitored. Before choosing this model, confirm with Wazuh which agents would report to the cloud environment, which agent communication ports must be open from those hosts, and whether your data classification allows any event data to leave your network at all.
The access model is the first tradeoff. On Wazuh Cloud, users work only through the dashboard and agent communication ports, with no command-line or shell access, and the server and indexer APIs are off by default and read-only when Wazuh Support enables them. Your analysts would therefore need two sets of access paths, two sets of roles and two places to investigate. Data location is the second tradeoff: each cloud region is a fixed place where alerts are indexed, so the region list on the cloud FAQ should be checked against your residency rules. Ask your compliance lead which events may be sent to the cloud and which must stay local, and document that split before any agent is enrolled.
Duplicated operations are the third cost. Rules, decoders, agent groups, retention choices and the upgrade cadence must be tracked in two environments, and a cloud tier that keeps environments on the latest Wazuh version still needs your local team to review what changed against your custom content. Illustrative example: a team with a few hundred endpoints might send one business unit's agents to a cloud trial while the rest report to a self-hosted server, then compare alert quality for a set period. If the trial produces findings your local deployment cannot reproduce, that gap is a reason to adjust local tuning. Price the cloud tiers against the agent count you actually need, and ask for a written quote that states who runs the upgrades and who answers alerts outside business hours.
How DeployOpen plans and runs self-hosted Wazuh
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Wazuh, that means working out whether the self-hosted deployment or the managed service fits your data residency, access and operating model, and then building the one you choose in your environment.
How we scope
- Written scope lists the agent counts, operating systems, log sources and retention periods the deployment must cover.
- Scope records where the indexer, server and dashboard will run, including any air-gapped or offline installation requirements.
- Scope states which compliance views, such as PCI DSS or HIPAA dashboards, your auditors will expect to see.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We install the indexer, server, dashboard and agents in your cloud accounts, data centers or isolated networks.
- Configuration covers agent enrollment, custom rules and decoders, and the integrations your SOC already uses.
- We harden the stack, configure backups and test archive and restore paths before go-live.
- Testing checks alert paths and access controls, with results recorded against the agreed scope.
How we hand over
- Handover documents architecture, sizing, upgrade steps and the operational runbooks your team will use.
- We document which licenses apply to each component, so procurement can confirm the terms it is accepting.
- Evidence for compliance assessments is prepared and organized, while independent auditors issue any reports.
- Your staff are shown how to run daily operations, so ownership moves to your team at a documented point.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should cover Wazuh patch releases, which the vendor ships on its own cadence, and tested upgrade windows.
- Ask for a written quote tied to scope, since DeployOpen does not publish a price list.
- Confirm response expectations and escalation paths in the retainer before signing, rather than assuming them.
