When Hyperswitch Cloud fits and when self-hosted Hyperswitch fits
Choose Hyperswitch Cloud when your payments team wants Juspay to carry the hosting, uptime and compliance workload and you are willing to buy that outcome through a sales-priced contract. The Hyperswitch pricing page positions Cloud for businesses that want to fully outsource payments and compliance overhead, with hosting costs covered, and it offers a 99.999% uptime guarantee and a PCI DSS 4.0 compliant stack out of the box. Cloud also bundles more connectors (210+ against 90+ in the self-hosted editions) and includes revenue recovery, cost observability and reconciliation, which are paid add-ons when you self-host. This fits a team with a small platform group, no appetite to run Kubernetes and Postgres for a card-handling system, and a roadmap that depends on connectors Cloud already lists.
Choose self-hosted Hyperswitch when data residency, network placement or control over the card path is a requirement that a hosted service cannot meet. Self-hosting means your team owns the Rust app server, Router and Scheduler, the PostgreSQL and Redis tiers, and the Helm deployment, so the case rests on having the platform engineers to run them. It also means you decide the vault model. Under the in-house PCI model, the merchant is fully responsible for PCI DSS certification and data handling, so confirm with your QSA whether that scope is acceptable before you deploy. Before deciding, ask Juspay to confirm in writing which connectors and modules your target processors need, the sizing of your self-hosted uptime commitments, and whether a support tier is included or priced separately.
Self-hosted versus Hyperswitch Cloud: factor by factor
This table sets Hyperswitch Cloud beside a self-hosted Hyperswitch deployment across connectors, bundled modules, uptime, compliance, licensing, SDKs and pricing. Read each row against your own edition and contract, since several cells depend on whether you buy Community, Enterprise or Cloud and what the sales quote includes.
| Factor | Hyperswitch Cloud | Self-hosted Hyperswitch |
|---|---|---|
| Connector coverage | 210+ payment integrations, per the Hyperswitch pricing comparison | 90+ payment integrations in the Community and Enterprise editions, per the same comparison; confirm the current list for your processors |
| Revenue recovery, cost observability and reconciliation | Included in the Cloud offering | Paid add-ons when self-hosting; confirm pricing and availability with Juspay for your edition |
| Uptime commitment | 99.999% uptime guarantee, per the Hyperswitch pricing page; confirm how it is measured and credited in your contract | No vendor uptime guarantee; availability depends on your Kubernetes, PostgreSQL, Redis and network design |
| PCI DSS responsibility | Stack described as PCI-SSS certified and PCI DSS 4.0 compliant as an out-of-the-box service; ask for the current Attestation of Compliance and your responsibility matrix | You carry PCI DSS scope for the systems you run; in the in-house vault model the merchant is fully responsible for PCI DSS certification |
| Other attestations | ISO 27001:2022 and SOC 2 Type 2 listed on the Hyperswitch website footer; request the reports and scope | Not provided by Juspay for your deployment; you produce evidence for your own environment with your assessor |
| Licensing | Hosted service; the open source repository is licensed under Apache 2.0, but Cloud terms come from your contract | Apache 2.0 for the open source repository, per its GitHub repository; Enterprise terms apply if you buy that edition |
| SDKs | Client SDKs for web, Android, iOS, React Native and Flutter are part of the platform, per the repository | Same client SDKs from the repository; you own their integration and upgrade cycle |
| Pricing model | Quoted through sales; the pricing page says all hosting costs are covered | Free Community Edition software, plus your own hosting, staffing and any Enterprise or add-on fees, which depend on your quote |
| Who runs upgrades and incidents | Juspay operates the service under the contract | Your team or a partner runs upgrades, scaling, backups and incident response |
Who holds card data, keys and PCI DSS responsibility
In Hyperswitch Cloud, Juspay operates the stack that holds card data, keys and the controls around them. Self-hosted Hyperswitch moves those duties into your own environment, so the questions below decide who answers for each one.
Where card data lives
Card data is stored in the Hyperswitch card vault (locker), a separate Rust service. In Hyperswitch Cloud, Juspay hosts that storage. Self-hosted, the vault runs in your infrastructure unless you choose an external PCI vault provider or the SaaS Hyperswitch Vault. Ask which model applies to each cardholder data flow and confirm where every copy of the data, including logs and backups, resides.
The card vault as a separate service
The vault is its own service rather than a module inside the Router, which narrows the scope that must be secured and monitored. In a self-hosted deployment, you own its network placement, access paths, patching and restore procedures. Confirm with your assessor whether the vault's network segment and administrative access fall inside your cardholder data environment.
Encryption service and key management
A separate encryption service handles key management for Hyperswitch. Self-hosting makes you responsible for generating, storing, rotating and backing up those keys, and for controlling who can reach them. Ask Juspay how the encryption service is delivered in Hyperswitch Cloud, which key custody model applies, and what evidence you receive about key handling.
Cloud compliance posture as described
Juspay describes the Hyperswitch Cloud stack as PCI DSS 4.0 and ISO 27001:2022 compliant, and its website footer lists SOC 2 Type 2. These are vendor descriptions, not evidence you can file. Request the current Attestation of Compliance, ISO certificate and SOC 2 Type 2 report directly from Juspay, check their scope and dates, and confirm which services each covers.
Uptime and compliance in self-hosting
Juspay states that Hyperswitch Cloud carries a 99.999% uptime guarantee. Self-hosted deployments have no such guarantee from Juspay, so availability, failover and the operating records that support your PCI DSS assessment depend on your own team or your implementation partner. Ask what contractual uptime applies to Cloud and what operational evidence you would produce yourself.
Responsibility in the in-house PCI model
When you self-host with the native vault, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling. Your assessor will treat the full stack as in scope. DeployOpen can prepare systems, controls and evidence for that assessment, but it does not issue audit reports, attestations or certifications. Independent assessors and certification bodies do that work.
Which vault model keeps card data out of your PCI scope
This model keeps the card vault (locker) inside your own infrastructure. Hyperswitch's Rust card vault stores the card data, and the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling. This is the closest option to running everything yourself, so the cardholder data environment, its network segmentation, key handling and evidence collection all fall to your team and your assessor.
- Full PCI DSS responsibility: Your organization owns certification and the evidence for every control that touches stored cards.
- Largest cardholder data environment: The vault, its database, the encryption service and the hosts around them are in scope.
- Key management: The encryption service that protects vault data is part of your key lifecycle and rotation process.
- Hosting and operations: Kubernetes or cloud hosting, patching and backups for the vault remain your responsibility.
- Control over data residency: Card data never leaves your environment, which can matter for specific regulators or contracts.
Before choosing this model, confirm the full scope with your QSA or assessor and ask Juspay which vault controls the open-source release includes.
In this model Hyperswitch still orchestrates payments inside your infrastructure, but the card data is stored with an external PCI vault provider such as VGS or Tokenex. Your systems handle tokens rather than raw card numbers, which typically shrinks the cardholder data environment. The provider's own PCI DSS status and the integration boundary then become part of your assessment.
- Reduced card data footprint: Your orchestration services work with tokens, so raw card data sits outside your hosts.
- Shared responsibility: The vault provider's attestation covers its side, and your assessor still reviews the integration and token flows.
- Provider contract: Pricing, data location, exit terms and attestation delivery are set in your agreement with the vault provider.
- Ongoing dependency: Availability of the vault becomes a dependency on the payment path, so plan for its outage behavior.
- Your hosting effort stays: You still run the Hyperswitch services, databases and Redis, so the operating work of self-hosting remains.
Ask the vault provider for its current attestation and a written responsibility matrix, then confirm with your assessor how the tokenization flow affects your scope.
This model keeps the orchestration layer self-hosted while the card vault runs as Juspay's SaaS Hyperswitch Vault. Your application and routing services stay in your infrastructure, and card storage moves to a service Juspay operates. It is a middle position between full self-hosting and Hyperswitch Cloud, because you keep control of routing and data flows but hand off the vault.
- Vault operated by Juspay: Card storage and its compliance program sit with the vendor, not your hosts.
- Self-hosted orchestration: Routing, retries, the Control Center and your application integration remain in your environment.
- Scope depends on the contract: Which PCI and attestation evidence applies to the SaaS vault must come from Juspay in writing.
- Dependency on the vendor's service: Vault availability and data location depend on the vendor's terms and regions.
- Migration path: Moving card tokens between vaults later is a separate project that needs planning.
Request Juspay's current compliance documentation for the SaaS vault and confirm with your QSA how it changes your responsibility matrix.
Who pays for hosting, licenses and operations in each model
Hyperswitch Cloud bundles hosting into a sales-priced contract, while self-hosting moves every infrastructure line onto your budget. The Hyperswitch pricing page describes Cloud as the option for businesses that want to outsource payments and compliance overhead, priced through sales with all hosting costs covered, unlike the self-hosted editions. Self-hosting, by contrast, means you pay for the cloud accounts or data center capacity, the Kubernetes clusters the Helm charts deploy onto, the PostgreSQL primary and replica that the architecture docs describe, the Redis instances used for caching and the scheduler queue, and the staff who run them. The Router and Scheduler services scale independently, so these are separate line items to estimate, not one platform fee. Self-hosting also carries recurring costs that do not appear on the infrastructure invoice. The pricing comparison shows that revenue recovery, cost observability and reconciliation are paid add-ons when you self-host, while Cloud includes them and offers 210+ payment integrations against 90+ in the self-hosted editions. Ask whether each connector you need is in your self-hosted edition or requires a licence, and whether add-on modules are priced per year, per volume or per seat. Staff time for upgrades, backups, on-call coverage and PCI DSS evidence is recurring too, and it grows with the number of vault models you run.
Build your quote request around the cost components that differ between the two models, not around a headline price. For Cloud, ask for the written scope of hosted uptime (the pricing page cites a 99.999% uptime guarantee), which connectors and modules are included, how volume is metered, what the contract says about PCI DSS and ISO 27001:2022 responsibility, and what exit assistance costs if you later move in-house. For self-hosting, ask each vendor or partner to separate one-time costs (architecture, deployment, connector integration, vault setup, penetration testing and initial compliance preparation) from recurring costs (hosting, database and cache operations, upgrades, support and add-ons). Confirm whether the in-house PCI model adds assessment costs that a Cloud contract would carry for you, and check whether a support tier is separately priced. The main cost drivers are transaction volume, connector count, the vault model you choose, and how many environments you need for testing. Cloud pricing is set by sales, so confirm which of these it scales with before comparing totals. Hyperswitch does not publish self-hosted support prices in the material supplied here, so confirm the current Community and Enterprise terms directly with Juspay before budgeting.
What your team runs in each model
This table lists the recurring operating tasks for each model so you can size the in-house workload against the hosted service. Read the self-hosted column as the work your staff, or a partner you pay, will carry every month. The main takeaway is that hosting, uptime and PCI evidence move to Juspay under Hyperswitch Cloud, while the rest of the platform work stays with you in either model.
| Operating task | Self-hosted Hyperswitch | Hyperswitch Cloud |
|---|---|---|
| Initial deployment | Helm charts on Kubernetes, with guides for Minikube, AWS, GCP and Azure. Your team sizes clusters and networking in your own accounts. | Provisioned by Juspay. Your team integrates against the hosted service and sandbox. |
| Database and cache operations | Run PostgreSQL with a master and replica setup and Redis for caching and the scheduler queue. Backup, failover and capacity planning sit with you. | Operated by Juspay as part of the service. Confirm backup, restore and data residency terms in the contract. |
| Upgrades | Track the Hyperswitch releases page, test each release in staging, then roll it out. Budget time for connector and schema changes between versions. | Applied by Juspay. Ask how release timing and any customer-facing changes are communicated. |
| Monitoring and incident response | Build dashboards, alerts and on-call rotations for the Router, Scheduler, PostgreSQL and Redis. You own the first response and the post-incident review. | Juspay runs the platform monitoring. Confirm escalation paths, response windows and what your team still watches on the merchant side. |
| Uptime management | Uptime depends on your cluster design, failover and capacity. No uptime commitment comes from the software itself. | The pricing page states a 99.999% uptime guarantee. Ask for the contractual wording, measurement method and service credits. |
| PCI evidence collection | You gather evidence for the controls in your PCI DSS scope, including card data handling in the in-house vault if you use it. The docs state the merchant is fully responsible for PCI DSS certification in that model. | Juspay's pricing page describes a PCI DSS 4.0 compliant stack. Ask for the current attestation package and which responsibilities remain with you. |
| Connector onboarding | Your team configures each processor and wallet, handles credentials and tests flows. The README lists more than 100 processors, while the pricing comparison lists 90+ integrations in the self-hosted editions. | The pricing comparison lists 210+ integrations for the hosted service. Confirm which connectors you need are available before committing. |
| Control Center SSO setup | OpenID Connect only, with no SAML, JIT or SCIM provisioning. Users must be invited first, and roles are managed inside Hyperswitch, so access reviews are manual work for your identity team. | Confirm with Juspay which identity options and role controls the hosted dashboard supports before you plan the integration. |
Moving between self-hosted Hyperswitch and Hyperswitch Cloud
This sequence shows how a team would move Hyperswitch workloads in either direction, from inventory through vault decisions, routing cutover and data handoff, so the switching cost is visible before a contract is signed.
Inventory connectors, modules and volumes
Start by listing every payment processor connector, wallet and module you use today, including routing rules, retry logic and any revenue recovery, reconciliation or cost observability workflows. Hyperswitch Cloud lists more than 210 payment integrations against 90+ in the self-hosted editions, so confirm in writing with Juspay that each connector you depend on is available on the hosted service before planning further. Record which modules are paid add-ons when self-hosting, since they may be included on Hyperswitch Cloud. The step is done when you have a signed-off matrix showing each connector and module, its owner, and whether it exists on the target platform.
Decide where card data will be vaulted
Choose the vault model before any data moves, because it determines what can be exported and what the migration costs. The documented options are the native in-house vault that keeps you in PCI DSS scope, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. Under the in-house model, the merchant is fully responsible for PCI DSS certification and data handling. Ask Juspay whether card tokens can be exported and in what format. The step is complete when the vault decision and its PCI DSS responsibility split are documented and approved by your compliance lead.
Map identity, roles and access
Confirm how operators will sign in to the Control Center on the target platform. Self-hosted Control Center supports single sign-on through OpenID Connect only, with no SAML, no JIT or SCIM provisioning, and roles managed inside Hyperswitch rather than mapped from your identity provider. Document every user to be invited and every role to be recreated manually. The step is done when your identity team has signed off on the access model and the invitation list is ready for the target environment.
Plan routing and reconciliation cutover
Define the cutover sequence for traffic. Most teams move connectors in stages, shifting a small share of transactions first, comparing authorization rates and reconciliation outputs between the old and new stacks, and then completing the switch. Agree with Juspay how in-flight payments, scheduled retries and open disputes will be handled during the change. Set a rollback trigger that your payments and finance teams agree on in advance. The step is done when a written runbook names each owner, each checkpoint and the condition for reverting traffic.
Test in the hosted sandbox or local Docker
Validate the target configuration before any production traffic reaches it. Hyperswitch documents a hosted sandbox for testing and a Docker-based local setup, which lets you rehearse routing rules, connector credentials, webhooks and reconciliation exports. Run the same test scenarios against both environments where possible. Note which tests can only run in production-like conditions, such as live processor responses, and schedule those carefully. The step is complete when every test case in the matrix has a recorded result and any gaps are assigned to an owner.
Plan data export and token migration
Plan how transaction history, merchant configuration and any stored tokens will leave the source platform and enter the target. Ask Juspay to confirm, in writing, the export formats, the availability of historical data, and whether vaulted tokens can be transferred or must be re-collected from customers. Data portability terms and the migration path must be confirmed in writing before you commit, and they vary with the vault choice you made earlier. Keep an audit trail of every export, including who ran it and where the files were stored. The step is done when the export and token plan is signed off and a dry run has produced a verified sample.
Execute cutover and verify reconciliation
Carry out the planned traffic shift according to the runbook, watching authorization outcomes, webhook delivery and settlement files in real time. Reconcile a full settlement cycle between the old and new platforms before decommissioning anything. Keep the source environment available in read-only mode until finance and the compliance team confirm that all records are complete. The step is complete when reconciliation reports balance, the rollback window has closed without use, and the cutover record is filed.
Decommission and document the cost of switching
Retire the old environment only after the evidence is archived, including keys, logs and the PCI DSS scope reduction or expansion from the vault change. Record the costs your team actually incurred: connector rework, testing time, vault migration, and any paid add-ons or support tiers now included or newly required. Note which costs were one-time and which recur, such as hosting, patching and compliance evidence for self-hosted operation or subscription fees for the hosted service. The step is done when a closure report exists that a future buyer or auditor could follow.
Questions buyers ask before choosing a hosting model
How much does self-hosted Hyperswitch cost compared with Hyperswitch Cloud?
Hyperswitch Cloud is priced through sales, and the Hyperswitch pricing page says all hosting costs are covered in that price. No public figure is published for either option, so you cannot compare the two on list price alone. Self-hosting shifts costs to your side: cloud or data center infrastructure for the Router, Scheduler, PostgreSQL, Redis and card vault, the engineers who run them, and any PCI DSS assessment work you own. The Hyperswitch pricing comparison lists revenue recovery, cost observability and reconciliation as paid add-ons when you self-host. Ask Juspay for a written quote for each option, and ask which modules and connectors are included in each price. Ask DeployOpen for a fixed-scope quote covering the implementation work, which is separate from any licence or hosting cost.
How long does it take to set up a self-hosted Hyperswitch stack?
No setup timeline is published for self-hosted Hyperswitch, so treat any duration you hear as an estimate to verify. The main drivers are the target platform, the number of connectors you need, whether you use the in-house vault or an external PCI vault provider, and how much identity, logging and backup integration your environment requires. Hyperswitch documents Helm charts on Kubernetes, with guides for Minikube, AWS, GCP and Azure, and a Docker-based local setup, which help a team reach a working test environment. Production readiness takes longer because it includes security review, key management, and evidence collection. Ask your team and any implementation partner to break the plan into milestones with written acceptance criteria.
What skills does a team need to run self-hosted Hyperswitch?
Running Hyperswitch yourself needs skills in several areas at once. Your team should be comfortable operating Kubernetes, since the documented deployment path is Helm charts. It should also manage PostgreSQL with a master and replica setup, and Redis, which the architecture docs describe as used for caching and the scheduler queue. Someone must own the card vault, the encryption service for key management, and the Control Center configuration. Payment and PCI DSS skills matter as well, because the docs say that with the in-house vault the merchant is fully responsible for PCI DSS certification and data handling. Identity skills are needed for the Control Center, which supports OpenID Connect single sign-on only. Confirm these gaps with a skills review before you commit.
Can our team run Hyperswitch alone, or do we need outside help?
Your team can run Hyperswitch alone if it already has the skills described above and enough capacity to own on-call work, upgrades and security review. Many teams start with the Docker-based local setup or the hosted sandbox to build familiarity before they go to production. Outside help is most useful when the gaps are specific, such as a one-off architecture review, a PCI scope assessment, identity integration work, or a hardened production build. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Ongoing support and upgrades are available as retainers. Ask any partner to show who holds the keys and the runbooks after handover.
Does Hyperswitch Cloud still need a compliance review from our side?
Yes, a Cloud subscription does not remove your own compliance obligations. The Hyperswitch pricing page describes Cloud as a way to outsource payments and compliance overhead, and it lists a PCI DSS 4.0 compliant stack and ISO 27001:2022 compliance as out-of-the-box. You should still ask Juspay for the current attestation reports and the scope of each, and then confirm how your own cardholder data flows, integrations and access controls fit within that scope. The Hyperswitch website lists PCI DSS 4.0 for the US and EU, ISO 27001:2022 and SOC 2 Type 2 attestations. Only the independent assessors and certification bodies that issue them can confirm their current status, so check the documents directly.
What does a DeployOpen engagement cover for self-hosted Hyperswitch?
A DeployOpen engagement is fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For a self-hosted Hyperswitch project, the work can include planning the target architecture, implementing the deployment in your cloud account, data center or air-gapped network, integrating identity and logging, hardening the stack, setting up backup and restore, and documenting operations. It can also include security testing of the application and APIs and preparing systems and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies do that work. Ask for a written scope that lists which vault model, connectors and modules are in and out before you sign.
What does Hyperswitch Cloud not give us that self-hosting does?
Cloud gives you less direct control over where the stack runs, how it is upgraded and what the data path looks like. Self-hosting gives you control over the deployment location, the vault model, and the release cadence, which matters if you must keep card data inside your own perimeter or meet data residency rules. Hyperswitch documents three self-hosted vault models, including the native vault in your PCI scope and an external PCI vault provider, so you can choose how much card handling you keep. Cloud also includes the 210+ payment integrations listed on the pricing comparison, against 90+ in the self-hosted editions, so connector breadth is a point in Cloud's favour. Weigh these trade-offs against your regulatory position before you decide.
When a self-hosted Hyperswitch team should bring in outside help
Outside help reduces risk most when a self-hosted team lacks depth in one of three areas: PCI DSS, Kubernetes operations, or the vault decision itself. Self-hosted Hyperswitch runs a Rust core app server, Router and Scheduler services, PostgreSQL with a master and replica setup, Redis, and the card vault, and the documented deployment paths use Helm charts on Kubernetes. If nobody on the team has operated that combination under production load, or has carried a PCI DSS assessment before, an implementation partner can help set up the environment, harden it, and document what the assessor will ask to see. DeployOpen plans, implements, hardens and documents self-hosted platforms in the client's own infrastructure, but it does not issue attestations or certifications. The assessor and the card brands still decide scope.
The vault choice is the decision most worth bringing expertise to early. Hyperswitch documents three self-hosted models: the native vault in your own PCI scope, an external PCI vault provider such as VGS or Tokenex, and orchestration with the SaaS Hyperswitch Vault. In the in-house model, the docs state that the merchant is fully responsible for PCI DSS certification and data handling. Before you commit, get the scope analysis in writing and show the proposed data flows to your QSA or assessor. Confirm with Juspay which model its current documentation supports for your region and connector set. A readiness review of the network segmentation, key handling and logging around the chosen vault can surface gaps before an assessment starts.
A move from Hyperswitch Cloud to self-hosting is the third case, and it carries its own risks. Cloud customers have the 99.999% uptime guarantee and the hosted PCI stack from Juspay, so the team taking that work over must rebuild uptime engineering, backups, patching and evidence collection. Plan the cutover with an outside reviewer, test token and connector migration in a staging environment, and confirm with Juspay what data and configuration can be exported. Ask any partner for a written, fixed scope with named deliverables and timelines before work starts. Ask for a clear statement of which controls remain with your team after handover, and whether ongoing support is a retainer or a separate engagement.
How DeployOpen scopes, delivers and supports self-hosted Hyperswitch
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so for Hyperswitch the work starts with a decision on who holds card data and who carries PCI DSS responsibility. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we scope
- Confirm whether the team needs Hyperswitch Cloud, self-hosted orchestration, or a self-hosted vault model before any build starts.
- Record the connector list, wallets and modules in the written scope, since connector coverage differs between Cloud and self-hosted editions.
- Agree in writing who owns PCI DSS scope, key management, uptime targets and incident response for each option.
How we build
- Deploy the Router, Scheduler, PostgreSQL, Redis and Control Center components on Kubernetes using Helm charts in your cloud account or data center.
- Integrate the chosen vault model and each agreed payment connector, then test routing, retries and failure paths against sandbox credentials.
- Configure identity for the Control Center, noting that it supports OpenID Connect only and that roles are managed in Hyperswitch.
How we hand over
- Deliver architecture, configuration and runbook documentation covering the vault model, network boundaries and backup procedures.
- Provide a compliance evidence pack that maps your controls to the PCI DSS scope you hold, prepared for your assessor rather than issued by DeployOpen.
- Walk your platform, security and finance teams through operations, reconciliation and the upgrade path for new Hyperswitch releases.
How we support
- Offer ongoing support, upgrades and continuous security testing as retainers, with terms defined in a separate written agreement.
- Include periodic review of connector changes, release notes and vault configuration so the stack stays aligned with your scope.
- Ask us to confirm in your quote which uptime, response and escalation terms apply, since DeployOpen does not set vendor SLAs.
