Fewer Than 3 Engineers? Run Managed OpenStack, Not In House

Choose managed OpenStack if your team has fewer than three dedicated infrastructure engineers or needs production workloads live within a quarter. Choose in-house if you need deep customization, already run a dedicated platform team, and can rehearse upgrades the way the OpenStack project and the OpenInfra user survey describe. We’ll walk through the cost, staffing, and operational evidence behind that split, using practical playbooks designed for operators in the field.

---

TL;DR:

• Managed onboarding often takes weeks, while internal production builds take two to six months; data transfer, API compatibility, and identity integration commonly delay migrations.
• An internal OpenStack team needs three to four engineers across Ceph, Neutron, the control plane, and on call; fewer can leave systems dependent on one person.
• Compare managed fees with annual internal costs for hardware, salaries, and on call coverage, then account for how often long incidents have consumed engineering time.
• SLURP lets operators skip every other upgrade, but internal teams still need rehearsals and rollback plans; ask providers for resolution times and runbook ownership.

---

Table of Contents

• Managed vs in-house: a side-by-side look at the real tradeoffs
• What in-house OpenStack actually costs once you count everything
• How much team do you actually need to run OpenStack yourself?
• The Day-2 workload nobody budgets for upfront
• How long does it really take to go live?
• Where OpenStack and Kubernetes meet
• A checklist to decide: managed or in-house?
• What practitioner playbooks teach us about running OpenStack well
• Our honest take on the managed versus in-house debate
• How we can help you run OpenStack with less risk
• FAQ
• Sources

Managed vs in-house: a side-by-side look at the real tradeoffs

The honest comparison isn’t managed versus in-house on price alone. It’s about who absorbs the operational risk, and when that risk shows up.

A small startup running three app teams on a single rack has very different math than a regulated enterprise running patient records across two data centers. The startup usually wants speed and low headcount. The enterprise usually wants control, audit trails, and a contract that names who owns an incident at 2 a.m.

Here’s how the main dimensions stack up:

• Time to production: managed onboarding often lands in weeks; in-house builds commonly take two to six months once hardware, networking, and identity integration are accounted for.
• Control and customization: in-house wins when you need custom Neutron plugins, nonstandard storage backends, or hardware you already own.
• Cost shape: managed is operating expense that scales predictably with usage; in-house is capital-heavy upfront, then lumpy as hardware ages and staff turn over.
• Operational risk: in-house concentrates risk in a small number of engineers who understand the stack; managed spreads that risk across a provider’s bench.
• Upgrade burden: in-house teams own every upgrade rehearsal and rollback plan; managed providers typically build that into their standard service.

The trap most teams fall into is comparing a managed quote against only the server cost of in-house, ignoring the hiring, on-call, and downtime costs that tend to flip the comparison once you add them up, as detailed in managed cloud solutions and migration services highlighting operational cost factors. That’s the gap we cover next.

What in-house OpenStack actually costs once you count everything

Capital costs are the easy part to estimate: servers, storage arrays, networking gear, rack space. Managed fees are also easy to read off a quote. The expensive surprises live in between.

Hidden costs that regularly blow past the original budget:

• Specialized hiring: engineers who know Ceph, Neutron, and Nova well enough to run production are hard to find and expensive to retain.
• On-call and overtime: nights and weekends covering storage rebalances or networking failures add real payroll cost that rarely appears in the original business case.
• Incident resolution time: a team without deep OpenStack experience can spend days diagnosing an issue a specialist would close in hours.
• Upgrade windows: every major version bump needs staging, rehearsal, and a rollback plan, which eats engineering time that doesn’t show up as a line item.

One practical way to model break-even: compare your fully loaded in-house annual cost (hardware amortization plus salaries plus on-call premiums) against the managed fee for the same workload, then weight it by how often your team has actually hit a multi-day incident in the past year. The University at Buffalo case study is a useful real-world anchor here: Day-2 operational strain, not sticker price, was what pushed that team toward a more supported model.

How much team do you actually need to run OpenStack yourself?

OpenStack in-house is a staffing decision before it’s a technology decision. Running a production cluster reliably takes a small set of roles, and skipping any of them is how outages turn into multi-day incidents.

• Platform engineer: owns the control plane, Keystone, and the overall architecture.
• Storage specialist (Ceph): keeps OSDs healthy and handles rebalances before they become outages.
• Network engineer (Neutron): manages overlays, security groups, and the inevitable routing edge cases.
• SRE on-call rotation: someone has to answer the page, and it can’t always be the same person.

Below roughly three to four dedicated engineers, most teams end up with single points of failure: one person who understands the Ceph cluster, one who remembers why a Neutron rule exists. That’s the point where a contractor retainer, fractional ops arrangement, or a blended managed setup tends to reduce risk more cheaply than a fifth hire.

Pro Tip: If you can’t name who covers a Ceph outage when your storage lead is on vacation, you don’t have in-house coverage yet, you have a single point of failure with a title.

The Day-2 workload nobody budgets for upfront

Standing up OpenStack is the easy part. Running it for three years is where the real operational cost lives.

Day-2 work includes patching hypervisors without downtime, live-migrating workloads off failing hardware, healing Ceph after a disk failure, and rolling out network changes without breaking tenant isolation. None of that shows up in a deployment diagram, and all of it recurs on a schedule you don’t control.

Recent OpenStack releases have tried to ease this. The Gazpacho release focuses on operational simplification and workload mobility, and the project’s SLURP cadence (Skip Level Upgrade Release Process) lets operators skip every other upgrade, cutting the number of disruptive jumps per year. That helps, but it doesn’t remove the need for rehearsal.

Ask any managed provider directly about:

• Upgrade cadence and whether they follow SLURP or a faster internal schedule.
• Incident response SLAs, specifically response time and resolution time, not just acknowledgment time.
• Who owns the runbook when something goes wrong at 3 a.m.

A predictable upgrade model matters more than raw feature speed for most production teams.

How long does it really take to go live?

Timelines differ sharply depending on path, and migration risk is the part most project plans underestimate.

1. In-house build: typically two to six months from hardware delivery to a production-ready cluster, depending on network complexity and how much automation you adopt.
2. Managed onboarding: often measured in weeks rather than months, since the provider already owns the deployment tooling and standard topology.
3. Migration risk points: data movement at scale, API compatibility between old and new environments, and identity/auth integration with existing directories are the three places timelines slip.
4. Automation impact: tools like OpenStack-Ansible and Kolla-Ansible turn a manual, error-prone build into a repeatable one, which is often the single biggest lever on both timeline and reliability.

Where OpenStack and Kubernetes meet

Most production environments today aren’t pure OpenStack or pure Kubernetes, they’re both. OpenStack handles the private cloud layer (compute, storage, networking) while Kubernetes orchestrates applications on top, either through Magnum or an externally managed cluster.

• Burst capacity: hybrid patterns let workloads move to public cloud or a separate Kubernetes pool when private capacity runs short.
• Workload mobility: containers on Kubernetes migrate more easily than VMs tied to specific hypervisor configurations.
• Ownership split: OpenStack admins typically own the infrastructure layer, while a separate platform team owns the Kubernetes layer, and the boundary between them needs to be explicit before an incident forces the question.

A checklist to decide: managed or in-house?

Run through this before committing either direction.

• Do you have at least three to four dedicated infrastructure engineers with Ceph and Neutron experience? If no, lean managed.
• Do you have compliance or data residency rules that require full control over hardware location and access? If yes, lean in-house.
• Have you rehearsed an upgrade on a staging environment that mirrors production? If no, that’s a red flag for going in-house right now.
• Do you have a documented runbook with named owners for storage, network, and control plane incidents? If no, fix that before scaling either path.

Questions worth asking a managed provider directly: what’s the SLA on upgrade windows, what’s the response time for a Sev-1 incident, and who owns the runbook after onboarding.

Pro Tip: A single engineer who understands your OpenStack deployment is not a team, it’s a dependency. Treat it like one.

What practitioner playbooks teach us about running OpenStack well

We built DevOps AI ToolKit around the gap between academic OpenStack documentation and what actually happens in production. Our guides come from working through real builds, real upgrades, and real incident timelines, not from theory.

A few resources that map directly onto the decisions in this article:

• Our production-ready OpenStack build guide walks through the checklist we use before a cluster goes live.
• Our OpenStack troubleshooting guides cover the Day-2 incidents that actually eat engineering time.
• Our upgrade strategy runbook lays out rehearsal steps: freeze changes, snapshot critical databases, validate rollback paths, and rehearse against a staging topology that matches your control plane and storage layout.

That last point is worth repeating as a standalone checklist: freeze, snapshot, validate rollback, rehearse against matching topology. Skipping any one of those four steps is how a routine upgrade turns into a weekend incident.

Our honest take on the managed versus in-house debate

The decision rarely fails because a team picked the “wrong” option. It fails because teams pick in-house without the staffing to support it, or pick managed without reading the SLA closely enough to know who owns a 2 a.m. page. Our rule of thumb: if you can’t name three people who could independently diagnose a Ceph failure tonight, you’re not ready for in-house, regardless of how the TCO spreadsheet looks.

Revisit the decision whenever headcount changes, compliance requirements shift, or workload grows past what your current storage design was sized for.

— James

How we can help you run OpenStack with less risk

Whether you lean managed or in-house, we offer a way to close the gap between the two. Our OpenStack / Kolla-Ansible Review ($450 one-off) gives an in-house team a second set of eyes before a risky upgrade, and our Managed OpenStack and Kolla-Ansible Services take the operational burden off your plate entirely when you’d rather not hire a fourth engineer.

• Choose an audit when you want to keep ownership but reduce risk on a specific upgrade or deployment.
• Choose managed services when staffing is the real blocker, not the technology itself.
• Check current plans and pricing on our pricing page before deciding which engagement fits.

FAQ

Is OpenStack still relevant in 2026?

Yes. Recent releases like Gazpacho continue to focus on operational simplification and predictable upgrade cadences, and the OpenInfra user survey shows continued hybrid cloud usage among operators. It remains a common choice for organizations that need private cloud control alongside public cloud flexibility.

Does a major research university use OpenStack in production?

Yes, documented case studies describe universities running OpenStack for research computing. The University at Buffalo case study describes how Day-2 operational challenges led that team to modernize its approach with more professional support.

What are the main alternatives to OpenStack for private cloud?

Organizations evaluating private cloud generally weigh OpenStack against other open-source private cloud platforms, container-native platforms, and public cloud hybrid extensions. The right choice depends on whether you need VM-centric infrastructure, container orchestration, or a mix of both.

What are the main types of cloud architecture?

Cloud architectures are generally grouped into public cloud, private cloud, hybrid cloud, and multi-cloud. OpenStack is most often deployed as the foundation for private cloud or as the private side of a hybrid cloud setup paired with Kubernetes or public cloud services.

How much does managed OpenStack cost compared to hiring in-house?

Managed OpenStack pricing varies by provider and scope, so it is best confirmed directly, for example through our work-with-me services page which lists audit and review pricing starting at $250 one-off. In-house costs are harder to pin to a single number since they depend on hardware, salaries, and on-call structure, but they should be compared on a fully loaded basis, not hardware cost alone.

Sources

• OpenStack Gazpacho: Built by a Global Community, Designed for Real-World Infrastructure | OpenStack Blog | Open Infrastructure Foundation
• OpenStack user survey / OpenInfra Foundation
• How the University at Buffalo Modernized Its Research Cloud with OpenStack
• OpenStack-Ansible deployment guide (2026.1)

Recommended

• OpenStack Troubleshooting Guides
• How to Build a Production-Ready OpenStack Cloud (2026 Guide)
• Managing Quotas and Capacity Planning in OpenStack
• Before an Outage: OpenStack High Availability Checks