Ceph implementation plan and cost

How to plan a Ceph implementation and what drives its cost

A Ceph build is scoped by five decisions: the hardware for each node, the network that carries replication and client traffic, the failure domains that decide what a lost disk, host or rack can take with it, the pools that serve block, file and object workloads, and the deployment method. Most teams keep day-to-day operation in-house and bring in a partner for the design and the initial build, so the plan should name who owns each of those five decisions before any hardware is ordered.

Teams usually start this work for one of four reasons: they are replacing a SAN or NAS that has reached the end of its support life, they are consolidating several storage silos into one pool, they need S3-compatible object storage for backups, analytics or application data, or they are moving off a commercial storage tool and want to remove a per-capacity license. Ceph is licensed under LGPL-2.1 or LGPL-3, and the project itself offers no paid edition. The cost of the platform is therefore the hardware, the people who build and run it, and any support agreement you choose to buy from a third party.

Hardware is the largest line in most builds, and the Ceph hardware recommendations set the layout rules that drive it. They advise a dedicated drive for each OSD, moving the WAL and DB of HDD-based OSDs onto shared SSDs, using enterprise-class SSDs for metadata, and bonding network links across two switches. They also advise sizing memory for peak use rather than quiet periods, and benchmarking before buying because no two clusters behave alike. Ask for a written list of drives, memory, network ports and switches, and confirm which of these items the quote includes and which your team must procure.

Recurring cost comes from capacity you cannot use. Replicated pools store several copies of each object and erasure-coded pools store data with parity, so raw capacity always exceeds usable capacity. Ask the partner to state the expected usable capacity per pool, the replication or coding scheme behind it, and the headroom kept free for recovery after a failure. Staff time for monitoring, upgrades and capacity expansion is the other recurring cost, and it is easy to undercount when the platform is first sized.

A fixed-scope quote should list the design deliverables, the build phases, the acceptance tests and what the client provides, such as racks, power, cabling access and staff for knowledge transfer. Confirm which deployment method is in scope: cephadm for a cluster that runs as containers on dedicated hosts, or Rook when the storage must run inside Kubernetes. Confirm the Ceph release to be installed as well, since the Squid release reaches its estimated end of life on October 31, 2026, and the Tentacle release is the newer maintained line. Any test plan should include failure and recovery drills, not only a functional check.

What a fixed-scope Ceph build includes and delivers

A typical fixed-scope Ceph build moves in a fixed order: review the workload and hardware, bootstrap the cluster, create the pools and services, prove it survives failures, then hand it over to your operators. Each work item below ends in a named deliverable you keep, so you can check progress against the written scope rather than against an open-ended timeline.

Workload and capacity review

We review the workloads that will use the cluster, their growth expectations, and the split between block, file and object demand. The output is a sizing record that states raw versus usable capacity, the replication or erasure coding assumption, and the memory sizing for peak recovery rather than calm periods. Ask for the sizing assumptions in writing so you can challenge them before hardware is ordered. Deliverable: a capacity and workload sizing document.

Hardware and network design review

We check the proposed drives, controllers, memory, metadata devices and switch layout against the Ceph hardware recommendations. Typical decisions include one dedicated drive per OSD, moving WAL and DB onto shared SSDs for HDD-based OSDs, enterprise-class SSDs for metadata, and bonded network links across two switches. We also recommend a benchmark before purchase, because no two clusters behave alike. Deliverable: a hardware and network design document with the open risks listed.

Failure domain and CRUSH layout

We define the CRUSH hierarchy that maps hosts, racks and rooms to failure domains, so a single host, rack or power feed loss does not take out more replicas than the design allows. This is the decision that most affects what a failure costs you, so it should be reviewed by your infrastructure team as well as ours. Deliverable: a CRUSH map description and failure domain table.

Cluster bootstrap with cephadm or Rook

We bootstrap the cluster with cephadm on bare metal or VMs, or with Rook when the cluster runs inside Kubernetes, then add hosts and services in the order the design sets. cephadm starts from a single node with one Monitor and one Manager and grows from there. The deployment method is a scope decision you should confirm early because it shapes upgrades later. Deliverable: a bootstrapped cluster with host inventory and configuration recorded.

First pools and services for RBD, CephFS or RGW

We create the first pools and services for the workloads in scope: RBD pools for block devices, a CephFS file system with its metadata pool, or RGW zones and users for S3-compatible or Swift-compatible access. Each pool gets its replication or erasure coding profile and device class set from the design. Ask which services are excluded from the first build so later additions stay separate. Deliverable: a pool and service register with client access tested.

Failure and recovery testing

We run planned failures against the live cluster, such as stopping an OSD, taking a host out of service, and failing a Monitor, then record how long recovery takes and whether client I/O continues. Results are compared with the design targets agreed in scope. These tests show the cluster behaves as designed under your hardware, which a benchmark alone does not. Deliverable: a test report with results, observations and any tuning changes.

Monitoring and alert setup

We configure metrics collection and alerting for cluster health, OSD state, capacity thresholds, Monitor quorum and client latency, and route alerts to the channels you name. Alert thresholds are set from the sizing record and the test results, not defaults alone. Confirm who receives each alert class before go-live. Deliverable: a monitoring configuration with an alert list and owners.

Runbooks and handover

We write runbooks for the operations your team will perform: adding a host, replacing a failed drive, responding to a full pool, and running a maintenance window. We then walk your operators through them and hand over the configuration, credentials handling and open items. Ask for the handover session to be scheduled into the written scope. Deliverable: runbooks and handover notes signed off by your operations lead.

What drives Ceph implementation cost and duration

This table lists the choices that most change the effort and duration of a Ceph build, with one way to keep each one contained. Read each row as a question to settle in the scoping stage, because the answers set the hardware, network and test work that a quote must cover. Fixing these inputs early in writing is the most direct way to keep a fixed-scope quote accurate.

Driver	Why it changes effort	How to keep it contained
Raw and usable capacity target	Usable capacity depends on the replication or erasure-coding scheme, so the raw figure drives OSD count, host count and rebalancing time. Ask for both numbers in writing.	Fix the usable target and protection scheme first, then size raw capacity from them and keep a headroom margin agreed in the scope.
Number of hosts and OSDs	Each host adds bootstrap, networking, monitoring and failure-domain work, and each OSD adds configuration and recovery testing. Small clusters carry the same design work as large ones.	Standardize host hardware so the same build repeats across nodes, and avoid mixing drive counts within a failure domain.
Device mix (HDD, SSD, NVMe)	Ceph hardware guidance favors a dedicated drive per OSD and shared SSDs for WAL and DB on HDD-based OSDs, which adds layout and benchmarking work. Each media tier needs its own device class and pool design.	Limit the number of media tiers to those with a clear workload need, and benchmark each tier once against the chosen layout.
Network design	Public and cluster traffic, bonded links across two switches and MTU settings all need to be designed and validated before deployment. Network faults are a common source of slow recovery and rework.	Document the addressing and bonding plan in one diagram, and have the network team sign off before hosts are racked.
Number of interfaces (block, file, object)	Each interface adds its own pools, authentication, client configuration and tests. RBD, CephFS and RGW do not share the same tuning or failure handling.	Phase interfaces and deliver the first one fully before adding the next, with a named owner for each.
Tenants or users for RGW	Each tenant, user and bucket policy adds identity mapping, quota setup and access testing. Authentication choices such as LDAP, Keystone or STS change the integration effort.	Agree the tenant model and authentication source before build, and limit the first release to a defined set of tenants.
Deployment method	cephadm and Rook follow different operating models. Choosing one changes the host preparation, upgrade process and the skills the operations team must have.	Pick the deployment method in the design stage and record the reason, so the build does not switch methods midway.
Environments (test, production, disaster recovery)	Each environment repeats the build, validation and runbook work. A disaster recovery site also needs replication design and failover testing.	Build the test environment with the same hardware pattern as production, and scope disaster recovery as a separate phase.
Compliance evidence needs	Assessors may ask for configuration baselines, access records, encryption settings and change history. Collecting this evidence while building is far cheaper than reconstructing it afterward.	List the evidence the assessor expects before build, and capture it as part of each phase's acceptance tests.
Existing cluster or SAN to migrate	Data movement, cutover windows, rollback planning and validation of copied data add work that is separate from the new build. The size of the source data sets the copy effort.	Scope migration as its own phase with a defined source inventory, and agree the cutover method in writing before work starts.

Hardware and network choices that set the quote

The hardware and network design is the largest single driver of a Ceph quote, and most of its choices are already spelled out in the Ceph hardware recommendations. The reference model is one dedicated drive per OSD, so a server with twelve data drives runs twelve OSD daemons rather than sharing a drive between them. Where the OSDs sit on spinning disks, the recommendations point to moving the BlueStore write-ahead log (WAL) and database (DB) onto shared SSDs. That choice changes the bill of materials: the SSDs need enough capacity and endurance to absorb the DB and WAL writes for every HDD behind them, and a failed SSD takes all of its attached OSDs down with it, so it belongs in the failure-domain plan.

Metadata is the other place where the recommendations push toward enterprise-class SSDs. This matters most for CephFS, where the metadata pool serves every directory and file operation, and for RGW bucket indexes. Consumer-grade drives tend to be cheaper per unit, but their write endurance and power-loss protection often fall short under sustained metadata load. Confirm the endurance rating and power-loss protection of each candidate drive against the expected write rate, and ask the vendor to put those figures in writing.

On the network side, the recommendations call for bonded links spread across two switches, so that the loss of one switch or one cable does not isolate a host. The quote should state the bond mode, the number of ports per host, the switch model and whether the design separates client traffic from replication and recovery traffic. Memory is the third lever. The recommendations size RAM for peak use, including recovery and backfill periods when OSDs work much harder than in normal operation, not for the quiet average. A cluster sized for calm periods can slow down badly during the first failure, which is exactly when the business notices.

The same guidance says to benchmark before buying, because no two clusters are alike. Drive models, controller firmware, CPU generation, network latency and the mix of block, file and object traffic all change how a given design performs. A credible quote therefore includes a benchmark step on representative hardware or a staged pilot, with the results used to confirm or change the bill of materials before purchase orders go out. Ask for that step to be a named line item with its own deliverable, not an assumption buried in the hardware cost.

To make the design review productive, bring three things. First, workload profiles: the expected block, file and object split, the I/O size and read-to-write ratio where known, and which applications are latency sensitive. Second, growth expectations over the planned life of the hardware, including how much capacity you expect to add and how quickly. Third, the hardware already in the racks, with server models, drive types, NIC speeds, switch models and available rack units and power. Reusing existing servers can lower the hardware line, but it may not meet the design rules above, and the review should show that trade-off explicitly.

Phases of a Ceph implementation and the output of each

A Ceph build moves in gated phases, from workload discovery through hardware design, deployment, pool creation and failure testing to handover, and each phase ends with a written output that the client approves before the next one starts. The schedule for each phase is set in the written scope.

Run discovery and workload sizing
DeployOpen interviews the platform owners and reviews current capacity, growth expectations and performance needs for each workload that will use block, file or object storage. The team records which workloads map to RBD, CephFS or the Ceph Object Gateway (RGW), the data protection expectations and the compliance or residency constraints that affect placement. The output is a sizing workbook with usable capacity targets, growth assumptions, performance requirements and a list of open questions. Sizing covers memory for peak use rather than average load, because Ceph's hardware guidance advises sizing memory for peak conditions. The client approves the sizing assumptions before any hardware work starts.
Produce the hardware and network design
Using the approved sizing, DeployOpen drafts the node layout, drive choices, metadata device plan and network topology. Ceph's hardware recommendations call for a dedicated drive per OSD, moving WAL and DB to shared SSDs on HDD-based OSDs, enterprise-class SSDs for metadata and bonded network links across two switches, and the design applies those points to the client's environment. The design also sets failure domains across hosts, racks or rooms as the client's risk model requires. The output is a design document with a bill of materials, network diagram, failure domain layout and a benchmarking plan. The client's procurement team or the client confirms hardware availability and vendor support terms before purchase, and the client signs off the design.
Decide the deployment method
The team chooses between cephadm, which manages Ceph as containers on non-Kubernetes hosts, and Rook, which runs Ceph inside Kubernetes. cephadm was introduced in Octopus (v15.2.0) and does not support older releases, so the release choice is made here as well. The decision depends on where the client already runs compute, which operations team will own the cluster and how storage classes will reach workloads. The output is a short decision record covering the chosen method, the release line, the reasons and the operational consequences. The client approves the record. Choosing Rook for an environment without Kubernetes, or cephadm where the platform team expects Kubernetes-native operations, is the kind of mismatch this step is meant to catch.
Bootstrap the cluster and onboard hosts
DeployOpen bootstraps the cluster in a staging environment, which creates an initial Monitor and Manager on one node, and then adds hosts and daemons in the order the design defines. Each host is checked for kernel settings, time synchronization, network bonding, drive identification and firmware versions before it joins. The output is a healthy cluster with the expected host count, OSDs and monitor quorum, plus a build record that lists host configuration, versions and the commands used. The client reviews the health report and the build record. The team confirms that the Dashboard and any administrative access paths follow the client's access policy before moving on.
Create pools and services for RBD, CephFS and RGW
The team creates the replicated or erasure-coded pools defined in the design, configures placement group settings, and deploys the services each workload needs: RBD for block devices, CephFS for shared file systems and RGW for S3-compatible or Swift-compatible object storage. Test clients connect to each interface and perform create, read, write and delete operations with the access controls the client specified. The output is a pool and service inventory, a test log for each interface and a list of client connection settings. The client approves the test results and the naming and access model before any production workload is connected.
Test failure and recovery
DeployOpen runs a defined set of failure scenarios against the cluster, such as taking a host offline, failing an OSD, isolating a network link and stopping a monitor, and records how Ceph detects the event, how recovery proceeds and how long client I/O is affected. The client's operations team observes the tests and practices the runbook steps they will use in production. The output is a failure test report with observed behavior, recovery times as measured in the environment, any tuning changes made and a set of runbooks for common incidents. The client signs off the report. Results from one environment do not transfer to another, so the report is specific to the tested configuration.
Hand over the cluster
DeployOpen transfers operational control to the client's team through documentation, training and a supervised move of production workloads or a final cutover checklist. The handover package includes the architecture record, configuration and version inventory, access model, backup and monitoring setup, runbooks, the failure test report and a list of open items with owners. The client's team runs a supervised period in which DeployOpen is available for questions according to the written scope. The output is a signed handover record. Ongoing support, upgrades and testing after handover are separate agreements, and the client decides whether to retain them.

Which parts of a Ceph build your team keeps and which a partner takes

This table maps each part of a Ceph build to the skills it needs and whether teams usually keep it in-house or buy it. Read it against your own operator bench: a team with existing Ceph operators often keeps most of the build and buys only design review and testing. The main takeaway is that the parts most likely to be bought are the ones where a wrong early decision is expensive to reverse.

Build part	Skills needed	Usually kept in-house or bought
Capacity and workload analysis	Storage architecture, workload profiling with your application owners	Often bought when no one has sized Ceph before; kept in-house when workload owners are already documented
Hardware and network design	Storage architecture, Linux and networking, bonded links across two switches	Usually bought for first builds; design review is a common middle option for teams with operators
Bootstrap and configuration (cephadm or Rook)	Linux, container orchestration, cephadm or Kubernetes operator experience	Often kept in-house where the team already runs containers; bought when Rook on Kubernetes is new to them
Pool and CRUSH layout	Storage architecture, failure domain design, replicated versus erasure-coded trade-offs	Usually bought for the first design; kept in-house for later pool additions by trained operators
Interface setup for RBD, CephFS and RGW	Linux, identity administration for RGW users and Dashboard SSO, storage client configuration	Split: client-side mounts often kept in-house; RGW identity and authentication often bought
Testing and failure drills	Storage architecture, load generation, fault injection, recovery monitoring	Often bought as an independent exercise, since the team that built the cluster is poorly placed to judge it alone
Monitoring and handover	Linux, alerting configuration, runbook writing, operations training	Usually kept in-house so operators own the runbooks; handover documentation is commonly a deliverable in the written scope

What usually goes wrong in a Ceph build and how to prevent it

Most Ceph projects that struggle do not fail on the software. They fail because hardware was bought before anyone measured the workload, or because recovery, networking, release choice, testing and ownership were treated as afterthoughts. Each card below names one of these failure points and the step that prevents it, tied to the phase where that step belongs.

Buying hardware before benchmarking

Ceph's hardware recommendations advise benchmarking before buying, because no two clusters are alike. Buying drives, servers and switches from a generic sizing sheet often leaves the cluster short on IOPS for block workloads or short on throughput for large object transfers. Prevention: during the design phase, run a benchmark on representative drives and a test host, record the workload profile, and make hardware purchase conditional on those results. Ask any partner to show the benchmark method in the written scope.

Undersizing memory for recovery

The Ceph hardware recommendations say to size memory for peak use, not calm periods. Memory needs rise during recovery and backfill after a drive or host failure, which is exactly when the cluster is already under stress. Prevention: in the hardware phase, size RAM per OSD for recovery peaks rather than steady state, and confirm the per-OSD memory target with the release you plan to deploy before ordering hosts.

Sharing networks without separation

Client traffic, replication and recovery traffic compete on a shared network, so a rebuild can slow every application using the cluster. The hardware recommendations advise bonding network links across two switches to avoid a single point of failure. Prevention: in the network design phase, plan separate public and cluster networks, bond each link across two switches, and document the VLANs, MTU and addressing before any host is racked.

Choosing a release near end of life

Squid has an estimated end of life of October 31, 2026, and Tentacle is the newer line, first released November 18, 2025. A cluster built on a release close to end of life will need an upgrade within a short window, often while in production. Prevention: at the platform decision stage, check the active releases page at quote time, pick the line with the longest remaining support, and make the upgrade path part of the scope and cost.

Skipping failure tests

A cluster that has never lost a drive, host or rack in a test has an untested recovery procedure. Failure domains in the CRUSH map only prove their value when a host is removed and the cluster rebalances as designed. Prevention: in the testing phase, pull a drive, power off a host and fail a switch path in a staging or acceptance window, then record recovery time and any client impact. Require these results as an acceptance criterion in the written scope.

Leaving no owner for alerts

Ceph reports health through its status output and dashboard, but an alert that reaches no one is equivalent to no monitoring. Clusters often go degraded for weeks because warnings land in a mailbox nobody reads. Prevention: during the operations handover, name one accountable team for each alert class, connect health notifications to on-call tooling, and write a runbook for degraded, near-full and recovering states. Confirm who answers at 2 a.m. before go-live.

How the Ceph build changes by starting point and environment

This is the most direct path. Ceph runs as containers on hosts you control, and cephadm bootstraps the first Monitor and Manager, then adds hosts and services. The main design work is hardware and network planning, because each OSD needs its own drive and the cluster's behavior depends on how those drives, the metadata devices and the switches are arranged.

Extra work for this environment:

Confirm that every host has a dedicated drive per OSD, and decide whether WAL and DB move to shared enterprise-class SSDs for HDD-based OSDs.
Plan bonded network links across two switches, and keep client and cluster traffic on networks you can separate.
Size memory for peak use, not calm periods, and benchmark representative hardware before purchase.
Set up SSH access and host inventory so cephadm can reach every node, and document who holds administrative credentials.
Confirm the cephadm release support: the documentation states it was introduced in v15.2.0 and does not support older releases.

Ask the vendor documentation for the current hardware recommendations for your drive types, since these guidelines change between releases. Do not assume a host configuration that passed in a lab will hold under your workload until you have benchmarked it.

What your team must provide before a Ceph quote is fixed

Missing inputs are the most common reason a fixed-scope Ceph quote moves. A quote can only be fixed against a defined set of hosts, networks, workloads and decisions, so the first thing your team should do is collect those inputs before a scope is written. If a host model, switch port count or capacity target is unknown when the quote is prepared, the work is priced on assumptions, and those assumptions tend to become change requests once the environment is opened up. Start with the hardware and the physical environment. For each proposed OSD host, list the chassis model, CPU, memory, drive count and drive type, HBA or RAID controller behavior, and the NICs and their speeds. Ceph's hardware recommendations call for a dedicated drive per OSD and, on HDD-based OSDs, shared SSDs for WAL and DB, so the number of SSD slots and their endurance matter as much as the spinning disks. Provide rack locations, available power feeds and per-rack power budget, cooling capacity, and any floor or weight constraints. These details determine whether the design fits your facility at all, and they are often the first thing that changes once real measurements are taken. Network and addressing come next. Provide the switch models, port speeds, the planned bonding across two switches, the VLAN plan for the public and cluster networks, and the IP address ranges reserved for monitors, managers, OSDs and gateways. Name the people who approve firewall rules, DNS entries and change windows, and confirm how access to the environment will be granted and logged. Also state the current storage being replaced, the workloads that will move (block, file or S3 object), their expected growth over the planning period, and the peak load figures your team already measures. The hardware recommendations say to size memory for peak use and to benchmark before buying, so peak figures are not optional. Finally, record the decisions that only your organization can make: the deployment method (cephadm on hosts or Rook inside Kubernetes), the Ceph release line to target, how Dashboard and Object Gateway users will authenticate, which backup targets will hold copies, and who the data owners are and who signs off design choices. Assign one accountable person for each decision and agree on a date for it. A decision left open at quote time is usually priced as a contingency, so closing these items early is the most direct way to keep the fixed scope fixed.

Questions buyers ask before hiring help for a Ceph build

Does Ceph have a license fee I need to budget for?

No. Ceph's source is licensed under LGPL-2.1 or LGPL-3, according to the COPYING file in the Ceph repository, and the project does not sell a paid edition. Your costs sit elsewhere: hardware (drives, servers, memory, network switches), people (your staff time or an implementation partner), and any support agreement you choose to buy from a commercial distributor or service provider. Some bundled components carry other licenses, so have your legal team review the components list for your deployment. Ask any vendor quoting a Ceph support contract to state exactly what it covers and what it excludes.

What drives the cost of a Ceph implementation?

Scope and environment drive most of the cost. The main factors are the number of hosts and drives, whether you deploy HDD-based OSDs with separate WAL and DB devices on shared SSDs, the network design (bonded links across two switches is the recommended pattern), how many pools you need for block, file and object, whether you run cephadm on bare metal or Rook inside Kubernetes, and how much integration you need with identity, backup and monitoring. Testing and benchmarking before purchase also add effort, because the Ceph hardware recommendations advise benchmarking before buying since no two clusters are alike. A fixed-scope quote should list each of these as a line item so you can see what changes the price.

Is a Ceph build a one-time project or an ongoing cost?

Both, and it helps to separate them when you compare quotes. The one-time items are design, hardware procurement, deployment, initial configuration, testing and knowledge transfer. The recurring items are hardware refresh, power and data center space, staff time for operations, upgrades to maintained releases, monitoring and any support agreement or retainer. Ceph releases are maintained for a limited period, so an upgrade cycle is a predictable recurring task rather than a surprise. Ask the provider which items are included in the fixed-scope build and which are offered later as a retainer for upgrades, testing or continuous support.

How long does a Ceph implementation take, and what sets the schedule?

The schedule depends mostly on lead times and decisions, not on the software install itself. The longest items are usually hardware delivery, network changes, and approval of the failure domain and pool design. Other factors include how many services you enable (RBD, CephFS, RGW with multisite), whether you integrate single sign-on or LDAP, how much benchmarking you run before go-live, and how many environments you need (lab, staging, production). The date-driven milestone that often shapes the plan is the end of life of your chosen release, so check the Ceph releases page when you start. Ask for a written timeline that names the dependencies on your side, such as racking, cabling and access approvals.

What does my team need to provide before a Ceph engagement starts?

Plan to provide the physical and access inputs first, then the design decisions. On the infrastructure side, you need the server and drive specifications you intend to buy or have bought, rack space and power, the switch and VLAN plan, DNS and time sources, and a jump host or access path into the cluster network. On the decision side, you need owners who can approve the failure domain layout, the replication or erasure coding policy for each pool, the authentication model for the Dashboard and RGW, and the backup and recovery targets. Name a technical contact who can make decisions within the engagement. Missing inputs are the most common reason fixed-scope timelines slip.

Can an internal team build and run Ceph without outside help?

Yes, many teams do, provided they have engineers who understand storage failure modes, networking and Linux operations. Ceph documents cephadm, which manages a cluster as containers and bootstraps a single-node cluster before you add hosts and services, so the first deployment is well documented. The harder parts are sizing memory for peak use, choosing failure domains that match your racks, tuning recovery so it does not starve client traffic, and planning upgrades. Assess your team honestly against those tasks. Many organizations use an outside partner for the design and first deployment, then operate the cluster internally, and that split is worth pricing as a separate option.

How is a fixed-scope quote for a Ceph build produced?

A fixed-scope quote follows from a written scope, which is agreed before work starts. Expect the scope to name the hosts and drives in the design, the network topology, the release and deployment method (cephadm or Rook), the pools and services to configure, the integrations, the testing and acceptance criteria, and the documentation and handover you will receive. Each item should map to a deliverable and a responsibility split, showing what you provide and what the provider does. DeployOpen does not publish a price list, so the quote comes from the written scope. Ask any provider to state assumptions, exclusions and change-request terms in the same document.

How DeployOpen scopes, builds and hands over a Ceph cluster

DeployOpen plans and builds Ceph inside your own infrastructure, starting from a written scope that covers hardware, network, failure domains, pools and deployment method. Each phase ends with tested results and documentation your team can keep and run.

How we scope

Review your workloads, capacity targets and whether block, file or S3-compatible object storage is needed
Agree in writing which hardware, network design and failure domain layout the fixed scope covers
Decide with you between cephadm on bare metal or VMs and Rook on Kubernetes before build starts
Confirm the release line you will run, checking the Ceph releases page for current end of life dates

How we build

Validate hardware against Ceph recommendations, including a dedicated drive per OSD and benchmarks before purchase
Lay out bonded network links across two switches and separate client and cluster traffic
Bootstrap the cluster with cephadm, add hosts and services, then create replicated or erasure-coded pools as scoped
Test failure scenarios such as drive loss, host loss and network faults, and record the observed recovery behavior

How we hand over

Deliver configuration, CRUSH map, pool and client access documentation tailored to your environment
Provide runbooks for routine tasks, health checks, capacity growth and recovery procedures your operators will use
Walk your team through test results and agree on the operational responsibilities that transfer at handover
Record the final configuration and open items so future changes can be reviewed against a known baseline

How we support

Ongoing support, upgrades and continuous testing are available as a retainer alongside the fixed-scope build
Plan upgrades to a maintained release, such as moving from Squid before its estimated end of life
Ask any quote to state what the retainer covers, response expectations and who performs upgrades and testing
Confirm with us in writing which items recur after handover and which are one-time build costs