How a Large Private Cloud Deployment Gets Planned Around Your Go-Live Date

A prospect told us recently that their first question about private cloud was simple: “How fast can it be provisioned?” It is a reasonable thing to ask. Public cloud trained a generation of engineers to expect capacity on demand, and any other model gets measured against that.

For small deployments, the answer is short. For a large one, the honest answer starts with a different question: when do you need it, and what does it need to look like on that day?

Convesio, a WordPress hosting platform, came to us with a version of this worry. Their case study describes a team that thought private cloud would be too complicated to run and that needed at least two large clusters to make the move work. The conversation that followed was about design and sequencing. Nobody asked us to ship a box from a shelf.

This article covers how that planning works for large hosted private cloud deployments. It is written for infrastructure leads and engineers who are comparing approaches and want to know what working with us looks like before a single server is ordered.

Why We Plan Large Deployments Instead of Stocking Them

We do not keep a large pool of idle hardware waiting for orders. Holding that much inventory in every configuration would make no financial sense for us or for the buyers we work with, and it would push cost into every customer’s bill.

We work the other way around. A large order gets designed with you, ordered against your go-live date, and set up so the infrastructure is in place when you need it. We act as the deployment partner. You bring the workload requirements and the date. We bring the design, the ordering, and the build.

This model suits buyers who know that a large order needs advance planning and want a vendor that knows how to run that process well. It suits them less if the requirement is a 500-core cloud next week with no prior conversation. We will say so early rather than let a timeline slip later.

We also do not publish a blanket delivery timeline. The right one depends on the size and shape of the order, so we set it with you during planning.

The Seven Stages of a Large Private Cloud Deployment

Every large deployment is different, but the sequence is consistent. For each stage below, we note what gets planned ahead of time, what you decide, and what we hand over.

Stage 1: Scope the Workloads and Growth Path

Planning starts with what you run today and where it is heading. We look at VM counts and shapes, storage volume and access patterns, network needs, and the growth you expect over the next year or two.

You decide: which workloads move first, which stay where they are, and what growth to plan for.

We hand over: a first sizing view that the rest of the design builds on.

Growth matters at this stage because it shapes the order. Convesio’s published build is a good example. Their platform started on a three-server cloud and grew to five servers as they modeled their compute-to-storage ratios and tuned the platform. They settled on an all-Ceph storage layout of roughly 116 TB and reported savings of more than 50%. A sizing plan that had assumed a static workload would have missed that path.

Stage 2: Design the Cloud

A hosted private cloud on OpenMetal is built on OpenStack and Ceph. It starts with a three-server Cloud Core that is hyper-converged, meaning compute, storage, and control plane services run on the same three machines. From there, we expand with additional Storage+Compute or Compute Only nodes, or with dedicated Ceph storage clusters of three or more servers.

Large deployments add a few design questions that smaller ones skip.

• Node consistency. Ceph performance is limited by its slowest node, and a slower network card on one node caps traffic for the whole cluster. Keeping nodes in a cluster homogeneous avoids that.
• Control plane sizing. The control plane needs three nodes. Our engineering documentation notes that deployments reaching around 40 or more nodes may need additional control plane nodes. We cover this in our control plane sizing guide.
• Storage layout. Replication versus erasure coding, all-flash versus mixed, and where storage lives relative to compute all change how many servers you order.
• Network layout. VLANs, provider IP blocks, and links to existing environments get settled before ordering, since they affect the build.

You decide: performance targets, redundancy level, and how much headroom to buy up front.

We hand over: a bill of materials and a network plan you can review.

Stage 3: Order Against the Go-Live Date

This is where the plan separates from the stock-on-the-shelf model. Once the design is agreed, hardware is planned and ordered against the date you need the cloud running. Large orders get committed to in advance, and the delivery plan is built around your date.

The planning conversation covers staging. Large deployments rarely need every server on day one. A phased order can bring the Cloud Core and the first wave of nodes online for migration while later waves arrive on a schedule that matches the migration.

Ramp pricing is available for some migrations that move in phases. Our write-up on ramp pricing for VMware migrations explains how it works.

You decide: the go-live date and whether to phase the build.

We hand over: an order plan tied to your dates.

Stage 4: Delivery and Rack

Hardware arrives, gets racked, and gets cabled to the design. For hosted private cloud, this is our work, which is a large part of the reason buyers choose a hosted model. Your team does not need to touch a rack.

Hardware that is reserved for your organization shows up in the node selection list inside the platform, and the Add Hardware screen in OpenMetal Central lists delivery time for nodes you add later. That visibility helps when you are planning a second wave.

You decide: nothing at this stage, other than answering questions that come up.

We hand over: racked, cabled, tested hardware.

Stage 5: Deploy the Cloud

With hardware in place, the cloud itself deploys quickly. We describe that part of the process as taking around 45 seconds, and the figure applies to the cloud software deploying on hardware that is already racked. Hardware delivery follows the plan we built in the earlier stages. We call this out because the 45-second number gets quoted as a total provisioning time, and for a large order it covers only this stage.

Nodes added later follow the same playbook that built the original cloud. Our operators manual describes adding a node to an existing cloud as taking around an hour.

You decide: access, tenancy, and identity setup.

We hand over: a running OpenStack cloud with OpenMetal Central for the GUI and API.

Stage 6: Validate Before Migrating

Before production workloads move, we recommend a proof of concept. Our PoC program offers a cloud for up to 30 days at no charge. For large deployments, a PoC is the cheapest place to find out whether your storage layout performs the way the model says it will.

A useful PoC has written success criteria. Define the workloads to test, the performance numbers that matter, and the failure scenarios you want to see handled before you start.

You decide: what success looks like.

We hand over: a working environment and engineering support during the test.

Stage 7: Migrate and Expand

Migration plans vary by source environment. For public cloud sources, our AWS to OpenMetal migration playbook covers the sequence. For VMware sources, our VMware alternatives page is the starting point.

After launch, growth follows the same process on a smaller scale. You add nodes or storage clusters as demand shows up, and the sizing work from stage 1 tells you when.

Management is a choice too. You can run the cloud with your own staff, or use Assisted Management or Complete Management so our engineers carry more of the operations load.

What Four Published Builds Show

The stages above are easier to judge against real deployments. These four come from our published case studies.

Convesio: Starting Small and Growing With Data

Convesio’s case study shows a build that evolved after launch. The team began with a three-server cloud, expanded to five servers, modeled compute and storage ratios, and moved to an all-Ceph layout of roughly 116 TB. They also reported using TRIM to reclaim space efficiently. The study reports savings of over 50%.

The takeaway for planning is that the first order is a starting point. Good design leaves room to change the ratio of compute to storage as you learn how your workloads behave.

MyMiniFactory: Storage Growth on a Short Timeline

MyMiniFactory’s case study describes a storage cluster that grew from 0.5 PB to 1.9 PB across nine nodes in under a year, using 7/2 erasure coding. Storage-heavy growth like this is why the Ceph layout gets settled during design. Erasure coding profiles and node counts are connected, and changing them after the fact is more work than choosing well up front.

RamNode: Consolidation

RamNode’s case study reports that eight OpenMetal servers replaced roughly 40 nodes, and that density per node rose from 4 customers to 64. This is a consolidation story. A consolidation plan sizes the order to the capacity the new servers need to carry, and the old node count does not enter into it.

An AI Chat SaaS: Compute-Heavy Scale

One anonymized customer, an AI chat software company, runs around 140 compute instances on OpenMetal. Compute-heavy deployments like this are why the compute-to-storage ratio gets modeled before the order is placed.

Where Large Deployments Go Wrong

These are the failure modes that the planning stages above are built to prevent.

• Sizing for today. A design that fits current load and ignores growth forces an early second order, well before it was budgeted.
• Mixed hardware inside one cluster. The slowest node sets the pace for Ceph, so mixing generations or network speeds costs performance that is hard to diagnose later.
• Treating the go-live date as flexible. If a migration deadline is real, such as a contract renewal, the order has to be planned back from that date.
• Skipping validation. Skipping the PoC leaves storage and network surprises for production.
• Ordering everything at once. A phased plan often fits a migration better than a single large delivery.

Mapping This to OpenMetal Products

Here is how the pieces fit together, along with the caveats.

• Hosted private cloud: the core product. Three-server Cloud Core, expandable. Best for production workloads that need dedicated infrastructure and a predictable operating model.
• Expansion nodes and Ceph clusters: the growth path. Order sizing matters here, and so does keeping nodes consistent.
• Bare metal: available for workloads that need a dedicated server rather than a virtualized one, with shared VLANs to the rest of your environment.
• OpenMetal Central: the GUI and API for managing the cloud.
• Assisted Management and Complete Management: options when you want our engineers to carry more of the operations work.

Two caveats apply. First, the planning model means large orders involve more conversation up front than clicking a button in a console. Second, the cloud is yours to operate, so someone on your side or ours needs to own day-two operations.

Where Public Cloud Is the Better Choice

Public cloud wins when demand is spiky or short-lived, when you need capacity within minutes and cannot plan ahead, or when you rely on a long list of provider-specific managed services. If your workload scales up for a week and drops back, paying for capacity by the hour is the right model. We would rather tell you that than sell you a planned deployment you will not fill.

A private cloud fits when load is steady or growing and you can forecast it. The planning effort is the cost of entry, and it pays back when the same infrastructure runs for years.

Who This Fits

• Teams moving a large, steady workload off public cloud or VMware, with a target date.
• Hosting providers, SaaS companies, and platform teams that expect to keep adding capacity.
• Buyers who value a vendor that plans the order with them and stays accountable through the build.
• Organizations that want to size storage and compute independently as they grow.

Who This Does Not Fit

• Teams that need a large cloud within days and have no lead conversation.
• Workloads with short, unpredictable bursts.
• Projects that depend on managed services specific to one hyperscaler.

A large private cloud arrives on time when the order is designed and committed against your go-live date, and the hardware and the plan are built together.

Plan Your Deployment With Us

If you have a workload and a date, the next step is a planning conversation. Contact our team to scope the design and the order. If you want to validate the architecture first, apply for a proof of concept.

Frequently Asked Questions

Does OpenMetal keep large amounts of hardware in stock?

No. We plan large deployments with the customer and order hardware against the go-live date. That keeps idle inventory out of the cost structure and lets the design match your workload.

How long does a large private cloud deployment take?

It depends on the size and shape of the order, so we set the timeline during planning and do not publish a single figure. The cloud software itself deploys in around 45 seconds once hardware is racked. Hardware delivery follows the plan we agree with you.

Can I add servers after the cloud is running?

Yes. You can add Storage+Compute nodes, Compute Only nodes, or Ceph storage clusters. Our operators manual describes adding a node as taking around an hour, and delivery time for new hardware appears on the Add Hardware screen.

Why does node consistency matter in a large cluster?

Ceph performance is limited by the slowest node, and a slower network card on one node caps traffic for the cluster. Keeping nodes homogeneous avoids that ceiling.

How many control plane nodes does a large cloud need?

The control plane needs three nodes. Our engineering documentation notes that deployments around 40 or more nodes may need additional control plane nodes, and we size that during design.

Can I phase a large migration?

Yes. Customers can bring the Cloud Core and a first wave of nodes online for migration and add later waves on a schedule. Ramp pricing is available for some phased migrations.

Should I run a proof of concept before a large order?

We recommend it. A PoC runs for up to 30 days at no charge and gives you a working environment to test storage layout, network behavior, and migration steps against written success criteria.