Should you run Zabbix Cloud or self-host it?
Zabbix Cloud fits teams that can accept its fixed limits and weekly maintenance windows, while self-hosting fits teams that need control over backups, upgrades, data location, item types or migration. The deciding question is rarely the software itself, because Zabbix states that its open source software has no license fee, no device limits and no feature gates. What you pay for in the cloud is operation: hosting, backups, upgrades and the database. What you pay for when self-hosting is your own staff time, infrastructure and, if you want them, paid technical support subscriptions.
Lean toward Zabbix Cloud when your monitored estate is steady, your sizing fits a single NVPS tier, and nobody on the team wants to run a database, patch a server or design backups. Check your real new values per second against the tier maximum before signing, because values above the maximum are discarded at random. Also confirm that you do not need external checks or SNMP traps, which Zabbix Cloud does not support, and that you can accept a weekly backup you cannot schedule or export. If you need to move an existing Zabbix instance in, stop here: existing instances cannot be imported or migrated into Zabbix Cloud.
Lean toward self-hosting when you must control where monitoring data lives, when you need your own backup schedule and restore tests, when you need external checks, SNMP traps or a different ODBC scope, or when you already run a Zabbix instance you want to keep. Self-hosting also means you choose upgrade timing, while Zabbix Cloud applies the latest release in a weekly window you select, with upgrades that can be postponed but not cancelled. Ask a provider for a written scope that covers server and database sizing, proxy layout, backup and restore testing, and upgrade planning, since those drive the recurring effort on your side.
How Zabbix Cloud and self-hosted Zabbix compare on the factors that decide the model
This table sets Zabbix Cloud against self-hosted Zabbix on the factors that usually decide the deployment model, from sizing and item support to backups, upgrade control and migration. Read each row against your own monitoring scale, database skills and change-control rules. The main takeaway is that the cloud model trades operational work for fixed limits, and the constraints that matter most are the ones you cannot change later.
| Factor | Zabbix Cloud | Self-hosted Zabbix |
|---|---|---|
| Licensing and fees | Subscription billed by tier; starting monthly prices apply per tier | Open source under AGPL-3.0 from 7.0 with no license fee, no device limits and no feature gates; paid support is optional |
| Sizing unit | New values per second (NVPS) tier, with values above the maximum discarded at random | Sized by your hardware, database and polling design; confirm against the Zabbix requirements for your version |
| Starting prices | Nano $50 per month (50 NVPS) up to 2xLarge $5,000 per month (10,000 NVPS) | No Zabbix software fee; infrastructure, database and staff costs are yours to estimate in a quote |
| Item type support | All item types except external checks and SNMP traps | Full item type set on your own server, subject to your agent and network design |
| ODBC databases | ODBC monitoring limited to MySQL and PostgreSQL | Depends on the ODBC drivers you install; confirm supported databases in your environment |
| Backups | Automatic weekly backups that cannot be scheduled or exported | You design and test backups of the server database and configuration; schedule and retention are your decision |
| Storage limits | History and trend storage limited only by disk, which can grow once every 24 hours but never shrink | Limited by your database and disk; you can resize and retention policy is set by your team |
| Upgrade control | Nodes upgraded to the latest release in a customer-chosen weekly window of at least one hour; upgrades can be postponed, not cancelled | You choose the version and timing, including LTS tracks such as 7.0 with full support until June 30, 2027 |
| Proxies | Connects to active and passive proxies and proxy groups | Full proxy and proxy group design, including SQLite for proxies only |
| High availability | Managed by the vendor; confirm failover details in the service documentation | Native server HA cluster sharing one database, with failover delay set from 10 seconds to 15 minutes |
| Regions | Choice among 5 regions | Wherever your own infrastructure runs, including on-premises or air-gapped networks |
| Support tiers | Platform-level support for paid users; configuration help needs separate technical support or consulting | Paid technical support from Silver to Global, with response times from 1 day to 1 hour |
| Migration | Existing Zabbix instances cannot be imported or migrated into Zabbix Cloud | Upgrades and migrations stay under your control, with the database version matched to requirements |
Where Zabbix Cloud's NVPS limits and item restrictions change the design
Zabbix Cloud is sized in new values per second (NVPS), not in hosts, so the first design question is how many values per second your monitoring generates, not how many servers you watch. The Zabbix Cloud tiers run from Nano at 50 NVPS to 2xLarge at 10,000 NVPS, with starting monthly prices listed on the Zabbix Cloud page from $50 to $5,000. Values above a tier's NVPS maximum are discarded at random, not queued or rejected in order, so an undersized tier loses data unpredictably. Illustrative example: a team that adds high-frequency item polling for a fleet of network devices may push an existing tier past its ceiling without noticing until gaps appear in graphs. Before you choose a tier, count items, polling intervals and proxy-collected values across every host, add headroom for growth, and confirm the current NVPS definition and tier boundaries on the Zabbix Cloud page.
Disk growth is the second constraint. History and trend storage is limited only by disk space, and the disk can be increased once every 24 hours but never decreased. A retention plan that assumes you can shrink storage after a cleanup will not hold in the cloud. Self-hosted Zabbix lets you resize, partition and prune the database on your own schedule, so the cloud model requires you to forecast retention before go-live. Ask the vendor to confirm the disk increment rules and whether any cost changes with disk size.
Item restrictions decide whether some monitoring designs can move to the cloud at all. Zabbix Cloud supports all item types except external checks and SNMP traps, and it limits ODBC monitoring to MySQL and PostgreSQL. Teams that rely on external check scripts for custom probes, or on SNMP traps from network gear, must redesign those collections, perhaps as agent items or via proxies, before migrating. Teams that monitor databases through ODBC on other engines will also need a different approach. Inventory every item type and ODBC connection in your current instance, then confirm the cloud's supported list with Zabbix before you plan the cutover, because existing instances cannot be imported or migrated into the cloud.
How data location, access and compliance differ between the two models
Zabbix Cloud and self-hosted Zabbix split monitoring responsibility differently. The choice of model decides where history lives, who controls backups and access, and what evidence an auditor can request. Each card below is a question to settle before you commit to either model.
Where monitoring data lives
Zabbix Cloud lets you choose among 5 regions, so your history and trends sit in a region the vendor operates. Self-hosted Zabbix keeps data in your own data center or cloud account, under your network controls. Confirm with the vendor which region applies, where data is replicated, and whether any support access crosses borders. Agent and proxy traffic also needs mapping, because it crosses your perimeter in both models.
Who holds the backups
Zabbix Cloud runs automatic weekly backups that you cannot schedule or export. That means you cannot pull a copy into your own recovery process or hold it under your retention rules. Self-hosted Zabbix lets your team define backup frequency, encryption, offsite copies and restore tests. Ask the vendor how long backups are kept, how a restore is requested, and whether restore evidence can be provided to an auditor.
Access control and authentication
Zabbix authentication settings define how users sign in, including internal accounts and external directories. In self-hosted Zabbix, you configure these settings, control the server and database accounts, and decide how administrator access is logged. On Zabbix Cloud, confirm which authentication methods are available, who holds administrator rights at the platform level, and how your own user lifecycle and access reviews are supported.
Change timing and upgrade evidence
Zabbix Cloud upgrades nodes to the latest release during a weekly maintenance window you choose, which must be at least one hour. You can postpone an upgrade but not cancel it. Self-hosted Zabbix lets you approve each change, record it in your change management system and keep the prior version for rollback. Auditors often ask for change records, so confirm what upgrade notices and logs the vendor provides.
Compliance responsibility split
Under either model, the organization that operates monitoring holds accountability for its controls, and the auditor decides whether those controls meet a framework. Self-hosted Zabbix puts more evidence in your hands, but also more operating work. Zabbix Cloud shifts part of the infrastructure operation to the vendor, so you must request the vendor's own assurance documents and map them to your scope. Do not assume any certification from the product name. Confirm the vendor's current attestations and your auditor's requirements in writing before you decide.
Data retention and disk control
Zabbix Cloud limits history and trend storage only by disk space, and disk can be increased once every 24 hours but never decreased. Self-hosted Zabbix lets you set retention per item and move older data to separate storage. Plan retention against your regulatory and incident-review needs before onboarding hosts, because shrinking storage later is not possible on the cloud tier. Ask how deletion requests and data exports are handled for each model.
What to check in the Zabbix Cloud terms before you commit
This sequence turns the vendor's published Zabbix Cloud terms into a checklist you can verify before signing. Each step ends with a written answer or a trial result that either fits your environment or rules the service out.
Confirm the region your data must stay in
Start by listing where your monitored systems, staff and regulators require data to be processed and stored. Zabbix Cloud lets customers choose among 5 regions, so ask the vendor in writing which region hosts your tenant, whether that choice is fixed after provisioning, and where backups and support access are handled. Your security or compliance lead signs off on the answer. The step is done when the region and the data location statements are in writing and your compliance owner accepts them.
Map item types and external checks in use
Export a list of every item type, check and script your current Zabbix or monitoring estate uses, including external checks and SNMP traps. Zabbix Cloud supports all item types except external checks and SNMP traps, so any dependency on those becomes a blocker or needs a redesign. Ask the vendor to confirm the list against the current Zabbix Cloud page, and test the top items in the trial. The step closes when you have a signed-off gap list showing which checks move, which are rewritten and which stay on self-hosted collectors.
Confirm proxy topology and network paths
Document every active and passive proxy, proxy group and site that reports into your monitoring. Zabbix Cloud connects to active and passive proxies and proxy groups, but your firewall rules, certificate handling and site routing must match that design. Ask your network team to confirm which sites can reach the cloud endpoints and which must keep local collection. Use the 5-day free trial to connect one representative proxy and one remote site, then verify data arrives and alerts fire. The step is complete when the trial shows stable data flow from each proxy type you run.
Verify ODBC monitoring against your databases
List every database you monitor through ODBC. Zabbix Cloud limits ODBC monitoring to MySQL and PostgreSQL, so any Oracle, SQL Server or other ODBC target needs a different collection path or stays on self-hosted Zabbix. Ask the vendor to confirm how ODBC credentials and drivers are handled in the managed service. In the trial, point one MySQL or PostgreSQL item at a test instance and confirm the values match a direct query. The step closes when each ODBC target is marked supported, rerouted or retained.
Test backup and restore expectations
Zabbix Cloud runs automatic weekly backups that cannot be scheduled or exported, and existing instances cannot be imported or migrated into it. Write down the recovery point and recovery steps your change, audit and disaster recovery policies require, then ask the vendor how a restore is requested, how long it takes and who performs it. If your policy requires you to hold a copy of monitoring data or configuration outside the provider, the cloud option may not meet it. The step is done when you have a written restore procedure accepted by your operations and risk owners, or a documented decision to keep self-hosted backups.
Check the maintenance window against operations
Zabbix Cloud nodes are upgraded to the latest release during a customer-chosen weekly maintenance window of at least one hour, and upgrades can be postponed but not cancelled. Compare that window with your change freeze calendar, batch jobs, on-call rotations and any period when alerts must never be silent. Ask the vendor how postponements are requested, how far they can be pushed and how release notes are shared before each upgrade. Confirm in the trial that the window and upgrade notice work with your on-call process. The step closes when the window is accepted by operations and the postponement rules are written down.
Confirm sizing and growth limits against NVPS
Calculate your steady-state and peak new values per second (NVPS) and compare them with the tier maximum you plan to buy. Values above the tier's NVPS maximum are discarded at random, so undersizing creates silent data loss. Ask the vendor how disk growth works, since disk can be increased once every 24 hours but never decreased. Use the trial to measure real ingestion over a representative period, then confirm the chosen tier with a margin your team agrees on. The step is complete when the sizing sheet, the trial measurements and the vendor's written limits all agree.
Record the decision and the exit path
Summarize the results of the previous steps in a single decision record covering region, item and ODBC gaps, proxy design, backup position, maintenance window and sizing. Include what you would do if you later wanted to leave, because existing instances cannot be imported into Zabbix Cloud and the backups cannot be exported. Ask the vendor to confirm the offboarding process in writing. The step closes when the decision record is approved by the security, operations and procurement owners and the exit assumptions are stated.
How upgrade windows and high availability change operating risk
Zabbix Cloud takes upgrade timing out of your hands within a window you choose. Zabbix Cloud nodes move to the latest release during a weekly maintenance window that you select, lasting at least one hour. You can postpone an upgrade but not cancel it, so the risk you carry is less about whether a change lands and more about when it lands relative to your change calendar and on-call rota. Before signing up, confirm which release the vendor will move you to, how much notice you receive, and whether a failed upgrade is rolled back by Zabbix or by you.
Self-hosted Zabbix keeps that timing decision with your team. Standard releases arrive every 6 months and are supported for 12 months, while LTS releases arrive every 1.5 years and are supported for 5 years, three of them at full support. Zabbix 7.0 LTS has full support until 30 June 2027, so a team on it can plan its move to the next LTS on its own schedule, test the upgrade in a staging copy, and pick a quiet change freeze. The cost is that you own the calendar: a team that falls behind carries the patching and testing work itself.
High availability also shifts where risk sits. Self-hosted Zabbix offers a native server cluster in which several nodes share one database, one node is active and the others stand by, and failover occurs when the active node exceeds a configurable delay of 10 seconds to 15 minutes. Proxy groups add redistribution of hosts when a proxy goes offline. Whether the Zabbix Cloud platform runs an equivalent design, and how its database and failover are protected, is the vendor's to confirm in writing. Ask for its availability design and recovery objectives, and test a failover in your own environment before depending on either model.
What your team runs in each model
In Zabbix Cloud, the vendor runs the Zabbix nodes, applies upgrades and handles platform-level support, so your team is not responsible for the server host, its database engine or its patch cycle. Your side keeps the work that depends on your environment: host configuration, templates, item design, alerting rules and the proxies that sit at your sites. Upgrades arrive in a weekly maintenance window you choose, and that window is set as a customer decision, not a vendor one.
- Recurring: choosing and reviewing the weekly maintenance window, which must be at least one hour, and planning around postponed upgrades, since they can be postponed but not cancelled.
- Recurring: maintaining templates, host groups, triggers and notification routing as your estate changes.
- Recurring: operating active or passive proxies and proxy groups at customer sites, including their connectivity and host.
- One-time: designing the monitoring model and migrating checks, because existing Zabbix instances cannot be imported or migrated into Zabbix Cloud.
- Support: platform-level support is included for paid users, while configuration help requires separate technical support or consulting. Tiers run from Silver (8x5, 1 day response) to Global (24x7, 1 hour response).
Before you commit, confirm with Zabbix which item types and data limits affect your estate, and whether the weekly backups meet your recovery expectations.
In a self-hosted deployment, your team or a partner owns the whole stack: the Zabbix server, a database from MySQL, MariaDB or PostgreSQL with optional TimescaleDB, the web interface, proxies and any high availability layer. The work is heavier up front and recurs with every release, but you control the database engine, backup schedule, restore tests and the timing of every change. Zabbix server high availability is native: several server nodes share one database, one node is active and the others stand by.
- One-time: sizing the database, choosing between MySQL, MariaDB and PostgreSQL, and deciding whether to use TimescaleDB, which is supported with PostgreSQL 13 to 18 and TimescaleDB 2.13 to 2.29.
- One-time: designing HA. Failover triggers when the active node exceeds a failover delay configurable from 10 seconds to 15 minutes, and the database layer still needs its own redundancy.
- Recurring: patching the server, web frontend, agents and database, and planning upgrades against the life cycle of each release.
- Recurring: running and testing backup and restore, since you set the schedule and retention.
- Support: paid technical support subscriptions are optional. Zabbix open source has no license fee or feature gates, and tiers run from Silver to Global, with the same response windows listed for Zabbix Cloud support.
Before you commit, confirm the database versions your release supports and who on your team or partner's team will hold the on-call and patch duties.
Proxies appear in both models, but the operating burden differs. Zabbix 7.0 and later support proxy groups, which redistribute monitored hosts across proxies when one goes offline. Proxies buffer collected data and reduce load on the central server, which matters for sites with unreliable links. In Zabbix Cloud, the central server is outside your control, while in a self-hosted model you decide where proxies run and how they are monitored.
- One-time: placing proxies at each site and deciding whether each uses active or passive mode.
- One-time: defining proxy groups for load balancing and for high availability of monitored hosts.
- Recurring: keeping proxy versions aligned with the server and patching the hosts they run on.
- Recurring: watching proxy health, buffer state and connectivity to the central system.
- Compatibility: Zabbix Cloud connects to both active and passive proxies and proxy groups, so confirm that your proxy design matches the supported modes.
Before you commit, ask which proxy versions each model supports and how the vendor treats proxy upgrades in its maintenance window.
Why an existing Zabbix instance cannot move into Zabbix Cloud, and how to migrate the other way
This sequence explains why a self-hosted Zabbix instance cannot be carried into Zabbix Cloud, what a team rebuilds in a new tenant, and how to plan the reverse move while confirming export options with the vendor first.
Confirm that the import path does not exist
Before any design work, the team confirms with the vendor that existing Zabbix instances cannot be imported or migrated into Zabbix Cloud. The vendor's Zabbix Cloud page states this directly, so a move to the cloud starts from an empty tenant rather than from the current server. The owner of the monitoring platform records the answer in the migration file, along with the name of the vendor contact who gave it and the date. This step is done when the decision to rebuild, not migrate, is written down and signed off by the platform owner and the team that pays for the subscription.
Inventory configuration, templates and history
The platform engineer exports a full inventory from the current instance: hosts, host groups, templates, user macros, items, triggers, actions, maintenance periods, and the proxies that collect data. History and trend data are listed separately with their retention settings, because they will not follow the configuration. The team also notes any custom scripts, external checks and SNMP traps, since Zabbix Cloud does not support external checks or SNMP traps as item types. The inventory is complete when every host has an owner and every template has a documented purpose.
Map unsupported item types to alternatives
For each item that Zabbix Cloud does not support, the engineer decides how the signal will still be collected. External checks and SNMP traps may need to move to a self-hosted proxy, a different collection method, or a separate tool that remains on the team's own network. ODBC monitoring in the cloud is limited to MySQL and PostgreSQL, so other database checks need a separate answer. The output is a table that maps each unsupported item to a named owner, a decision, and a reason, which the security and operations leads review.
Redesign templates and proxy layout for Cloud
The platform team rebuilds templates in the new tenant from the inventory rather than copying an old server export. It confirms how active and passive proxies, and proxy groups, will connect to the cloud, and which sites need a local proxy to reach hosts behind their own firewalls. Template versions are documented so that later changes can be tested before they reach production. The step is complete when a test host in each network segment reports data into the new tenant through the planned proxy path.
Set retention and value limits against the tier
The team sets item intervals and retention expectations against the chosen tier's NVPS maximum, because values above that maximum are discarded at random. It also confirms that disk can be increased once every 24 hours but never decreased, so the initial storage size is a deliberate choice. Expected history needs for audit, capacity planning and incident review are written down and compared with what the tier provides. The step closes when a sample load test or calculation shows the planned NVPS sits below the tier limit with headroom the team has agreed on.
Plan the reverse path and confirm backup export
Because Zabbix Cloud backups cannot be scheduled or exported, the team asks the vendor in writing how data can leave the platform if the organization later moves back to self-hosted Zabbix. It asks which configuration export formats exist, whether historical data can be retrieved, and in what form. Until those answers are confirmed, the reverse path is treated as a configuration rebuild with history starting again. The output is a written exit plan that names what is confirmed, what is not, and who in the organization owns the follow-up.
Document the self-hosted target and cut over
If the decision is to move in the other direction, or to keep a parallel self-hosted instance, the team builds the target on its own infrastructure using the same template and proxy documentation. Cutover runs with both systems reporting for an agreed overlap period, and alerts are compared before the old source is switched off. The migration is done when the new system carries every host and alert the inventory lists, the overlap results are reviewed, and the decommissioned instance has its final configuration archive stored under the organization's own retention policy.
What buyers ask before choosing between Zabbix Cloud and self-hosted Zabbix
What drives the cost of Zabbix Cloud compared with self-hosted Zabbix?
Zabbix Cloud is a monthly subscription sized by new values per second (NVPS), and the published starting monthly prices run from $50 for the Nano tier (50 NVPS) to $5,000 for the 2xLarge tier (10,000 NVPS), according to the Zabbix Cloud page. Self-hosted Zabbix has no license fee, so your costs are the servers, storage, database, staff time and any paid support you choose. Ask the vendor for the exact tier that matches your measured NVPS, what disk costs as history grows, and whether the 10% annual saving applies to your term. For a self-hosted quote, ask a partner to price infrastructure, the database layout, proxies and an optional support subscription separately. Support subscriptions for self-hosted Zabbix come in Silver, Gold, Platinum, Enterprise and Global tiers according to the Zabbix support page.
How long does it take to move an existing Zabbix instance?
The duration depends on the size of your configuration, the volume of history you need to keep, the number of proxies and agents you must repoint, and how many item types you rely on. Existing Zabbix instances cannot be imported or migrated into Zabbix Cloud, so moving to the cloud means rebuilding hosts, templates and items in the new environment. Moving from self-hosted to self-hosted, by contrast, is a database and version upgrade project. No fixed duration applies to either path, so ask for a written scope that lists each host group, template, proxy and integration, and agree the timeline from that list.
Can a team run self-hosted Zabbix without outside help?
Yes, many teams do, because Zabbix is fully open source and the server, agents, proxies and web interface are available without a license fee. The team needs to own several areas: a supported database (MySQL, MariaDB or PostgreSQL, optionally with TimescaleDB), backups, proxy design, the high availability setup, and an upgrade schedule that follows the release policy. Zabbix 7.0 LTS has full support until June 30, 2027, so plan the next upgrade against that date. Teams without these skills in house often add paid technical support or a delivery partner for the initial build and then keep the platform in-house.
What skills does a self-hosted Zabbix deployment require from staff?
The work needs people who can operate the chosen database, design proxies for the network layout, and plan upgrades. Database skills cover tuning, storage growth, backup and restore testing, and failover of the database layer, which the Zabbix high availability cluster depends on. Proxy design covers how many proxies sit at each site, how proxy groups redistribute hosts when a proxy goes offline, and how buffered data reaches the server. Upgrade planning covers standard releases every six months with 12 months of support, and LTS releases with five years of support. Confirm that your staff can test these tasks before you commit to a design.
Does Zabbix Cloud include help with configuring templates and items?
No. Zabbix Cloud gives paid users platform-level support, but configuration help needs separate technical support or consulting, according to the Zabbix Cloud page. Platform support covers the service itself, while questions about which templates to use, how to build items for an application, or how to design triggers are handled as a different service. Ask the vendor to show the scope of each support path in writing, including response times for the tier you buy. Compare that cost with the consulting hours you expect to need for the initial template build and the monitoring changes you will make later.
Which item types and limits should I check before choosing Zabbix Cloud?
Zabbix Cloud supports all item types except external checks and SNMP traps, and it limits ODBC monitoring to MySQL and PostgreSQL. It connects to active and passive proxies and proxy groups. Check your current item inventory against these limits before you price a tier. Values above a tier's NVPS maximum are discarded at random, so an undersized tier can lose data without an obvious error. Self-hosted Zabbix does not carry these item type exclusions, which makes it the better fit for teams that depend on external checks or SNMP traps.
What should I confirm with Zabbix about backups, regions and compliance?
Confirm five points in writing. First, the cloud backups run weekly, cannot be scheduled and cannot be exported, so ask how you would recover data if the service fails and whether you need your own copy of history. Second, ask which of the five available regions hosts your data and whether that matches your data residency rules. Third, ask whether the vendor holds the certifications or attestations your regulator or auditor expects, and request copies rather than assuming them. Fourth, ask how the weekly maintenance window is chosen and how postponed upgrades are tracked. Fifth, confirm how disk increases are billed, since disk can grow every 24 hours but never shrink. DeployOpen does not issue audit reports or certifications, so the compliance answer comes from the vendor and your assessor.
Is Zabbix Cloud or self-hosted Zabbix easier to change later?
Switching in either direction is a rebuild, because Zabbix Cloud does not accept an imported instance. Moving out of the cloud means exporting what you can through the interface and rebuilding the rest, since weekly backups cannot be exported. Moving from self-hosted Zabbix to the cloud also means rebuilding hosts, templates and items. Self-hosted Zabbix keeps the data in your own database, which makes later moves between your own servers or to another database version an upgrade project. Ask any provider how it will carry your templates, history and proxy design, and ask for that plan before you sign.
How DeployOpen scopes, delivers and supports a self-hosted Zabbix deployment
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including self-hosted Zabbix. For Zabbix Cloud vs self-hosted Zabbix, the work starts with the monitoring requirements you already have, not with a platform decision made in advance.
How we scope
- Inventory of hosts, item types, SNMP and ODBC checks, and external checks that a Zabbix Cloud tier could not monitor
- Estimated new values per second and retention needs, so sizing reflects your environment rather than a tier guess
- Written, fixed scope with deliverables and timelines agreed before any work starts, with a quote following from that scope
How we build
- Deployment of Zabbix server, database, proxies or proxy groups, and web frontend inside your cloud accounts, data centers or air-gapped network
- Configuration of templates, authentication, user roles and backup schedules, with settings confirmed against the Zabbix documentation for your version
- Testing of failover behavior, proxy outage handling and upgrade steps in a non-production environment before cutover
How we hand over
- Written runbooks covering backups you control, upgrade windows you schedule, and database maintenance on the platform you choose
- Documentation of architecture, data flows, access paths and the configuration decisions behind each setting
- Knowledge transfer to your operations team so the platform stays under your control after the engagement ends
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build
- Upgrade planning that tracks the Zabbix support windows for your release, so you can plan moves ahead of end of support
- Confirmation with Zabbix, through its own support subscriptions, of any vendor-side question that falls outside DeployOpen's scope
