What OpenStack customization services cover and when teams hire them
Teams usually look for OpenStack customization help once a private cloud is running or being built and the business rules start arriving: a flavor catalog that matches approved hardware, project quotas tied to budget owners, Nova or Keystone policy changes, a branded Horizon dashboard, Heat templates for standard application stacks, and hooks into the ticketing, billing or CMDB systems the company already uses. In practice, customization means configuration, extensions and thin integration layers kept close to upstream, so that a later upgrade is a routine exercise rather than a rewrite. If a change cannot be expressed as configuration, an extension point or a small separate service, it is usually the wrong change.
Licensing is rarely the constraint. Official OpenStack projects must be licensed under the Apache License, Version 2.0, which permits the internal modification and extension most organizations need. The practical limits come from the project's own interfaces and release process. Customizations that patch core service code tend to break at each upgrade, while changes made through documented policy files, configuration options, Heat templates and Horizon plugin mechanisms are easier to carry forward. Ask any partner to show, for each planned change, which mechanism it uses and what would have to be re-tested when the target release changes.
Two inventory checks help scope the work before anyone quotes it. First, list every requested change and classify it as configuration, extension, integration or core modification. Second, identify the owner of each business rule, such as who approves quota increases or which team defines a compliant flavor. Many customization projects expand because rules are undecided, not because the code is difficult. Keep a version-controlled record of every change, including the release it was tested against, so the next upgrade starts from known facts rather than from memory.
The in-house versus partner question comes down to capacity and continuity. An internal team that already operates OpenStack, reads upstream release notes and can run tests against a staging cloud can often handle configuration and small plugins alone. Partner help is most useful for a fixed set of integrations, for an initial design that sets the extension pattern, or for a time-boxed backlog that the internal team cannot absorb while also running production. Whichever route you choose, confirm who owns the code after handover, where it is stored, and who will keep it working through the next upgrade.
What OpenStack customization work includes and what you receive
OpenStack customization is a set of bounded work packages, each tied to a specific service and a configuration you can inspect. Every package ends in artifacts your team owns, such as configuration in version control, policy documentation, tested templates, runbooks and a handover session. The exact scope of each package is fixed in writing before work starts.
Compute flavors and host aggregates
This package defines the Nova flavors your users can request and the host aggregates that place them on suitable hardware, such as hosts with particular CPU, memory or accelerator profiles. The main check is that each flavor maps to a host aggregate that actually exists and has capacity. You receive the flavor and aggregate definitions in version control, with a short note on which workloads each flavor is intended for.
Project quotas and default limits
This package sets compute, block storage and network quotas per project, along with the defaults applied to new projects. Quotas are the main guardrail against one tenant exhausting shared capacity, so they need to match the capacity plan and the chargeback or approval model. You receive the quota settings as code, a table of defaults and the procedure for requesting exceptions.
Keystone and service policy files
This package adjusts the policy rules that decide what each role can do in Keystone and the other API services, such as limiting who can create projects or change images. Policy changes are where OpenStack upgrades most often break, so each override is recorded with its reason and reviewed against the release notes of the version you run. You receive the policy files under version control and a policy reference document that lists each change and its owner.
Horizon branding and dashboard panels
This package applies your branding to the Horizon dashboard and adds or hides panels for your users, such as a custom landing page or a link to a service catalog. Horizon customizations are kept as an overlay so the upstream code is not edited directly. You receive the theme and panel files in version control, plus a list of the template paths you overrode so that upgrade testing can cover them.
Heat templates and a template library
This package writes Heat orchestration templates for repeatable stacks, such as a standard application tier with networks, security groups and instances, and organizes them into a library. Each template is tested against the target release before it is published to users. You receive the templates, their parameter documentation, test results for the release you run and a short guide for adding new templates to the library.
Integrations with ticketing, CMDB, billing and monitoring
This package connects OpenStack to your ticketing system, configuration management database, billing platform or monitoring stack through the service APIs, such as opening a request when a quota is exceeded or syncing project records. Each integration depends on the exact data you need and on the API version your tools support, so the scope starts with a data-flow list. You receive the integration code or scripts in version control, a description of each data flow and a runbook for failures.
What drives OpenStack customization cost and duration
This table lists the factors that most change the effort of an OpenStack customization project, why each one matters, and how to keep it contained. Read it before requesting a quote, because each driver maps to a line of the written scope. The main takeaway is that changes kept in configuration and limited to few services usually cost less to build, test and carry through upgrades than custom code spread across the platform.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of customizations | Each flavor, quota rule, policy, Horizon change or Heat template needs design, testing and documentation, and each adds upgrade checks later. | Agree a numbered list of customizations in the written scope and drop requests that do not serve a stated need. |
| Number of OpenStack services touched | Changes to Nova, Neutron, Cinder, Keystone or Glance each require service-specific testing, and cross-service changes multiply regression work. | Confine customization to the fewest services that meet the requirement and document why each one is touched. |
| Deployment method (Kolla-Ansible or OpenStack-Ansible) | Changes must fit the chosen tooling's override and role structure, and the two methods differ in how config and containers are managed. | Decide the deployment method before design starts and build overrides in the supported mechanism for that tool. |
| Config changes versus custom code | Configuration overrides are cheaper to build, review and roll back, while custom code must be rebuilt, tested and maintained against every upstream release. | Prefer configuration, policy files and Heat templates, and require a written justification for any patch to upstream source. |
| Number of environments (dev, test, production) | Each environment needs its own deployment, data set and test runs, and promotion between them adds validation steps. | Keep environments as close as practical in tooling and version, and automate promotion from one environment to the next. |
| Compliance evidence needs | Assessors may ask for change records, access controls, configuration baselines and test results, which take time to produce and keep current. | Agree the evidence list before build, and generate configuration and test records as part of the normal pipeline. |
| Number of integrations and their APIs | Each integration with identity, ticketing, billing, monitoring or CMDB systems needs interface design, credentials, error handling and tests against the external API. | Count integrations in scope early, use the supported APIs and standard protocols, and limit integrations to those with a defined owner. |
| Upstream upgrades planned during the period | Each upstream release can change options, policies or APIs that customizations depend on, so every planned upgrade adds regression and rework. | Plan upgrades around SLURP releases, keep customizations in version control, and budget upgrade testing as a separate work item. |
How an OpenStack customization project moves from scope to handover
The sequence turns a list of wanted changes into customizations that run in your cloud, stay traceable in version control, and can be upgraded later with a known impact. Each phase closes with a named output that you can review before the next one starts. The schedule for each phase is set in the written scope.
Inventory requirements and current state
DeployOpen works with your cloud, platform and business owners to list each requested change: flavors, quotas, Keystone policies, Horizon branding, Heat templates and external integrations. For each item we record the business reason, the users affected, the OpenStack release and deployment tooling in use, and the acceptance criteria. The output is a requirements inventory signed off by your owners, with out-of-scope items named explicitly. The phase is done when every requirement has an owner and a testable acceptance criterion.
Design each change and review upstream impact
Each customization is designed against the documented extension point for the release you run, such as a policy file, a Horizon plugin, a Heat template or an integration API, rather than an edit to service code. Every design goes through an upstream-impact review that asks whether the change touches files or interfaces that upstream projects may alter, and how it would behave on a SLURP or adjacent release. The output is a design record per change with its impact rating and an agreed fallback if the change cannot be carried forward. Design is complete when your architects have accepted each record.
Build changes in version-controlled repositories
Configuration, templates, plugins and deployment inputs are written in repositories under your version control system, with code review and a change log entry for each merge. Where the cloud is deployed with Kolla-Ansible or OpenStack-Ansible, customizations are kept alongside the deployment inventory so that a rebuild from the repository reproduces the same cloud. The output is a tagged release of the customization set and a build record that names the commit tested. The step closes when a clean deployment from that tag succeeds in the build environment.
Test against the running release in non-production
The tagged build is deployed to a non-production environment that matches the production OpenStack release, service versions and identity setup as closely as your infrastructure allows. Test cases come from the acceptance criteria in the inventory, and cover API behavior, policy decisions for each role, quota enforcement, Horizon rendering and integration calls. Failures return to the build step with a defect record. The output is a test report that shows each acceptance criterion with its result and the environment it ran in. The phase is complete when all criteria pass or have an approved exception.
Roll out in controlled stages
The approved release is applied to production through the same deployment tooling used for tests, in the change window and order agreed in the written scope. Before the rollout, a rollback procedure is rehearsed, and backups or configuration snapshots are confirmed. After each stage, DeployOpen checks the service health and the acceptance tests that are safe to run on live tenants, and your operators confirm they can see the expected behavior. The output is a rollout log recording what changed, when, and what was verified. The step is done when the post-rollout checks pass and your operations team accepts the state.
Hand over runbooks and the upgrade-impact register
The handover package includes runbooks for operating each customization, the steps to rebuild it from source, and the troubleshooting paths your operators will use. It also includes an upgrade-impact register that lists every customization, the upstream files or interfaces it depends on, the release it was tested against, and the test cases to rerun before any future upgrade. Your team walks through the package and runs a supervised change to confirm the handover is usable. The output is the accepted handover package and the register. Handover is complete when your operators have performed a supervised change without DeployOpen involvement.
Which OpenStack customizations stay upgrade-safe and which create upgrade debt
The most useful question to ask about any OpenStack customization is what it attaches to. Changes that attach to supported configuration options and documented policy files usually survive a release change with a review. Extensions built on documented plugin points survive with a targeted test. Changes that patch service code or call internal APIs are the ones that turn each upgrade into a rebuild. Before approving a customization, ask the team which of these three categories it falls into and write that answer into the change record.
Configuration options and policy files are the lowest-risk layer. Flavors, quotas and per-service settings are set through supported options, and policy rules are written against documented policy targets. The main upgrade risk here is drift: an option that was renamed, deprecated or given a new default in the target release. Release notes flag these changes, and the deployment tooling should show the effective value for each setting so the reader can compare old and new defaults. Keep these files in version control so the diff for an upgrade is readable.
Extensions built on documented plugin points, such as Horizon panels and dashboards, Heat resource plugins, and service-side driver or extension interfaces, carry more risk because they depend on an interface contract. Upstream maintainers generally keep documented interfaces stable across a release, but they can change them with a deprecation period. Each extension should have a named owner, a list of the interfaces it uses, and a test that exercises it against the target release in a staging environment before any production change is scheduled.
Patches to service code and calls into internal APIs create upgrade debt. The patch conflicts with upstream changes to the same file, and an internal function can change without notice because it was never promised to remain stable. The cost of each upgrade then grows with the number of patches, and the team may end up pinning an old release to avoid the work. Ask whether each patch can be replaced by a supported option or a plugin, and if not, record the patch, its purpose and the date it will be reviewed for removal.
The release window sets how long any customization needs to remain valid. OpenStack stable branches are maintained for approximately 18 months, and only SLURP releases may later enter the unmaintained phase, which has no releases and reduced CI before end of life. Confirm the current status of 2025.1 Epoxy and 2025.2 Flamingo on the OpenStack releases site, and plan the target release so it stays within the maintained window. Before each upgrade, read the release notes for every service in use, search for deprecations and removed options, and run each customization against the target release in staging. The output should be a list of changes the team must make before the cutover date.
Which OpenStack customization tasks your team keeps and which a partner takes
This table compares, for each common customization task, what teams usually keep in-house, what they usually hand to a partner, and the skills the work needs. The split shifts with your team's existing skills, how often your customizations change and what your auditors will ask to see, so use it as a starting point and confirm each row against your own staff and change plan.
| Task | Usually kept in-house | Usually outsourced | Skills needed |
|---|---|---|---|
| Policy decisions and tenant model | Deciding who owns projects, which roles exist and how tenants are separated | Drafting policy files, mapping the decisions into Keystone and Nova policy and documenting the result | Cloud governance, Keystone roles and project design, OpenStack policy syntax |
| Flavor and quota design | Choosing the workload sizes and chargeback rules the business will pay for | Building flavor sets and quota defaults, scripting their application and testing edge cases | Capacity planning, Nova flavors, quota behavior across services |
| Horizon branding | Approving logos, colors, wording and any user-facing changes | Packaging the theme, testing it against each upgrade and fixing breakage in later releases | Python, Django templating, CSS, Horizon plugin structure |
| Heat template authoring | Owning the catalog of stacks users are allowed to deploy and their approval process | Writing and reviewing templates, adding tests and handling parameter edge cases | HOT template syntax, Heat resource types, infrastructure as code practice |
| API integrations | Owning the systems that call OpenStack and the data they are allowed to read or change | Building the connectors, service accounts and error handling for ticketing, CMDB or billing feeds | REST and OpenStack SDK use, authentication with application credentials, integration testing |
| Testing and rollout | Signing off on acceptance criteria and the change window for production | Building the test environment, running regression suites and staging the rollout plan | CI pipelines, test environments, change management, evidence collection |
| Ongoing upgrade impact review | Deciding when to upgrade and which customizations stay or go | Reviewing each customization against new release notes and fixing what changed | Release note analysis, service-level knowledge, regression testing across the affected services |
What goes wrong in OpenStack customization projects and how to prevent it
Most OpenStack customization problems do not appear on the day of the change. They surface at the next upgrade, the next dashboard release or the first tenant who hits a locked-out API. The cards below cover the failure modes we see most often and the checks that keep each one visible before it reaches production.
Patches to service code break at upgrade
Editing Nova, Neutron or Cinder source in place works until the next release changes the function being patched. Each local patch becomes a rebase task that someone must repeat for every upgrade. Prevention: keep an upgrade-impact register listing every patched file, the reason for the change, the owning team and the upstream change that would make it obsolete, and review it before each upgrade planning cycle.
Policy changes lock out operators or tenants
Editing policy files without a staged rollout can remove access that operators and tenants rely on, often in a way that only shows up for one role or one API call. Policy defaults also change between releases. Prevention: stage each policy change in a non-production cloud, run role-based API smoke tests for admin, member and reader personas, and keep the previous policy file ready for rollback.
Quota models do not match billing
Custom flavors and quota sets can be configured in a way that the chargeback system cannot read, so usage is billed to the wrong project or not at all. Quotas set per project may also drift from the approved allocation. Prevention: define the billing unit first, map each flavor and quota to it, and reconcile a sample of project usage against the chargeback export before go-live.
Horizon changes break after dashboard updates
Custom panels, templates and branding overrides often depend on Horizon internals that move between releases. A theme that looks correct on one version can hide panels or fail to load on the next. Prevention: keep Horizon customizations in a separate plugin or theme package, pin the Horizon version it was tested against, and run the login and core project workflows after every dashboard update.
Heat templates tested against one release
Heat templates that pass on the release they were written for can fail when resource types, property names or default values change. Stacks that run today may not update or delete cleanly later. Prevention: keep a test suite for each template that creates, updates and deletes the stack on every OpenStack release the cloud will run, and record the tested release in the template metadata.
Undocumented changes outside version control
Configuration edited directly on controllers, or dashboard settings changed through the GUI, cannot be reproduced on a new control plane. Recovery and upgrade work then depends on memory. Prevention: store inventories, service configuration, policy files, Horizon overrides and Heat templates in version control, require a reviewed change for each modification, and rebuild a test environment from the repository at least once per release cycle.
Integrations depend on unstable API behavior
Scripts and external systems that parse undocumented response fields, rely on default microversions or call internal endpoints will break when a service changes. Prevention: document each integration's API version and microversion, pin them explicitly in client code, list the fields the integration reads, and include the integration in the upgrade test plan.
How OpenStack customization changes by deployment method and starting point
Kolla-Ansible deploys OpenStack services as Docker containers driven by Ansible. The 2026.1 deployment guides for this tool place most customization in the global settings, per-service override files and, when code or packages must change, custom container images. Each custom image becomes a build artifact that has to be rebuilt and retested whenever the upstream base changes.
- Configuration overrides: service settings such as policy or service options go into override files that are merged into the generated configuration, which keeps them out of the image.
- Custom images: patches or extra packages are built into images with a tag, a build record and a rollout plan.
- Build pipeline: rebuild images against a pinned upstream base so that updates to the base are a planned step, not an emergency.
- Test path: deploy the same image tags to a staging inventory before production, and run functional checks for each changed service.
- Ownership of artifacts: confirm who controls the image registry and build hosts, since they hold every custom layer.
Confirm that each custom image has a documented rebuild trigger and that the inventory and override files are in version control.
OpenStack-Ansible deploys OpenStack in LXC containers or directly on bare metal, depending on how the deployment configuration is set. The 2026.1 deployment guides for this tool direct most adjustments into the deployment configuration files, so the first question is whether a change can be expressed as an override before anyone edits a role or playbook. Changes to roles are code that the team must carry forward.
- Deployment configuration overrides: user variables and service-specific override files set options per service and are the first place to make a change.
- Container or bare metal model: LXC containers isolate service processes on controller hosts, while bare metal changes where packages land and how host-level settings are applied. The chosen model changes the test path.
- Role and playbook changes: edits to upstream roles or playbooks should be kept on a tracked branch, rebased for each release and retested.
- Test path: run playbooks against a lab built from the same configuration, and check that a repeat run makes no unintended changes.
- Scope of forks: list every role or playbook that differs from upstream, because each one adds review work at every release.
Confirm where your overrides are stored, whether any role has been forked, and whether your team can run the playbooks against a copy of production configuration.
Many production clouds already carry customizations that were made over time: edited policy files, patched service code, changed Horizon templates, hand-edited Heat templates or undocumented database changes. The cleanup task is to inventory what differs from the release the cloud deploys and decide, item by item, whether each change is kept as a documented override, moved into the deployment tooling or retired. This inventory is also the input for upgrade planning, because a difference that is manageable on one release can block the next.
- Inventory: compare running configuration, installed package versions and container images against the release the cloud is meant to run.
- Classification: mark each difference as keep, move into tooling or retire, with an owner and a reason.
- Patched code: patches to service code are the hardest to carry forward, so check whether the change is still needed or has been fixed in a later release.
- Test path: run existing functional checks on a copy of the cloud before and after each cleanup change, so regressions appear before a production window.
- Undocumented changes: look for edits made outside the deployment tooling, since these are the ones most often lost during an upgrade.
Confirm which release is running today, whether configuration is generated or hand-edited, and whether someone can explain why each change was made.
In a new build, customization is designed in from the start. Flavors, quotas, policies, Horizon branding, Heat templates and integrations are declared in the deployment code before the first production deployment, so every change has one home. The build path is simpler than in an existing cloud because no legacy differences need to be inventoried, but the release choice and the limits placed on forks determine how the cloud will be upgraded later.
- Declare in code: keep overrides, policy files, branding and Heat templates in the same repository as the deployment inventory.
- Limit forks: prefer configuration over patched code, since each fork adds work at every upstream release.
- Release choice: 2026.1 Gazpacho is a SLURP release, released 2026-04-01, so it is one of the releases the upgrade plan can be built around. Confirm this against the current release schedule before committing.
- Test path: build a lab from the same repository, run deployment and functional checks on every change, and promote the same tagged state to production.
- Approval: name who approves changes to policies, quotas and templates before the first production workload arrives.
Confirm which customizations are required at launch, which can wait for a later change window, and who signs off on each one.
What you need to provide before OpenStack customization work starts
Before customization starts, name the people who can make decisions for the cloud and for each business rule it enforces. The cloud owner approves changes to shared services such as Keystone, Nova scheduling, Cinder back ends and Horizon branding. Each business rule, for example a quota ceiling for a team or a restriction on who can create external networks, needs its own named owner who can state the intent and sign off the test result. Also provide the OpenStack release currently in production, the version of the deployment tooling, and read access to the deployment repository that holds inventories, overrides and any custom Heat templates. If the release is near or past the end of its maintained window, say so now, because the customization scope will depend on the upgrade path.
Next, supply a written requirements list with named approvers. Each item should state the outcome wanted, the projects or tenants affected, and the test that proves it works. Some decisions shape the design and must be made before build begins: the tenant model (one project per team, application or cost center), which Keystone roles map to which operations, the flavor catalog, the default quotas for each project, and which service policy changes are permitted. Each policy change should trace back to a numbered requirement and an approver. Without these decisions, no one can confirm whether a flavor rule or a policy override is correct, and the usual result is rework late in the project.
Provide access to a non-production environment that matches production closely enough to test the changes. Confirm that it runs the same OpenStack release, the same deployment method (Kolla-Ansible or OpenStack-Ansible), the same identity backend, the same storage back end including Ceph if it is used, and comparable network segmentation. Differences in these areas are where customization tests pass in staging and fail in production. Ask the team to list in writing every known difference that remains. Agree how the environment is refreshed, who can grant access to it, and which test accounts exist for each role. Confirm that it can run full Heat stack create, update and delete cycles for the templates you plan to change.
Integrations need API documentation for every external system the customization touches, such as a ticketing system that triggers Heat stacks, a billing export, or a configuration database feed. For each one, supply endpoint specifications, the authentication method, sample request and response payloads, and test accounts with the least privilege the integration needs. Also provide the change windows: the days and hours when production changes are allowed, any freeze periods, and the emergency change path with its named approver. The length and frequency of the windows set how many production rollouts the plan can include in a quarter, so check them against the test cycle before the schedule is fixed.
Agree the evidence process before work starts. Decide which controls the customization affects, where change records, test results, approval records and configuration diffs will be stored, who retains them, and for how long. DeployOpen prepares the evidence, the control descriptions and the documentation of how each control operates. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies determine the outcome of any assessment. Ask your auditor early which evidence formats they accept and how they plan to sample changes, so the evidence process is designed for their review rather than retrofitted after the work is complete.
How much does OpenStack customization cost and how long does it take?
What determines the cost of OpenStack customization?
The cost follows the number and depth of changes, not the size of the cloud. The main drivers are:
- How many items are customized: flavors, quotas, Keystone policies, Horizon branding, Heat templates and external integrations each carry their own design, build and test work.
- How far each change reaches: a flavor definition is small, while a policy change that affects several services needs more review and regression testing.
- How many environments must match: a single lab is cheaper than separate development, staging and production environments that must stay in step.
- How many integrations touch external systems, such as ticketing, billing or identity, and how well those systems are documented.
Ask for each item listed separately in the written scope, with the work and the test evidence for each.
How does DeployOpen build a quote for OpenStack customization?
A quote comes from a written scope agreed before work starts. DeployOpen does not publish a price list. The scope names each customization, the services and versions it touches, the environments involved, the integrations and the acceptance tests. Most engagements are fixed-scope, so deliverables and timelines are written down with the scope. When you request a quote, ask for:
- A line item for each customization with its deliverable and test.
- The OpenStack release and deployment method the work targets, such as Kolla-Ansible or OpenStack-Ansible.
- Which items are one-time build work and which are recurring, such as policy reviews or support.
- Assumptions about your access, change windows and who approves changes.
- Any change to scope that would alter the price or the timeline, and how it is priced.
Can our own team customize OpenStack without outside help?
Yes, if your team has the skills and time for the work, and many do. The upstream code is licensed under the Apache License, Version 2.0, so you can change and run it inside your own environment. The harder question is whether the team can keep those changes working through later releases. Check these before deciding:
- Whether you have people who can read Keystone policy, Heat templates and Horizon customization code.
- Whether you can test each change against every service it touches before it reaches production.
- Whether someone owns the changes after the project ends, including the upgrade work that follows.
If any answer is no, a partner can build the customizations and hand over documentation and tests your team can run.
What does DeployOpen need from our team during customization?
The work moves faster when your team provides decisions, access and review early. DeployOpen implements inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks, so you control the access. Expect to provide:
- A named owner who approves requirements and signs off each change.
- Access to the development or staging cloud, source control and the systems each integration uses.
- Your current policy, quota and flavor standards, so the design matches what your users already rely on.
- Scheduled review sessions and change windows for testing against production-like data.
Confirm these items in the written scope so delays are visible and their effect on timing is agreed.
How does customization affect our OpenStack upgrades?
Customization is the main reason upgrades become slow, so it should be designed for upgrades from the start. Each change to a policy file, a template or a Horizon override can break when the upstream code changes. Keep changes close to upstream, document each one, and keep the configuration in version control. Plan for these points:
- Changes made through supported configuration options usually survive upgrades better than edits to upstream files.
- Each customization needs a test that runs after every upgrade, service by service.
- OpenStack releases follow a six-month cycle, and SLURP releases allow upgrades between them, so the upgrade path should be planned around those releases.
Ask for the upgrade impact of each customization to be recorded in the scope.
Does DeployOpen customize OpenStack deployed with Kolla-Ansible or OpenStack-Ansible?
Yes, DeployOpen works with both deployment methods, and the method you use changes where customization lives. Kolla-Ansible deploys OpenStack in Docker containers with Ansible. OpenStack-Ansible deploys in LXC containers or on bare metal. The OpenStack 2026.1 deployment guides cover both. The method affects the work in these ways:
- Kolla-Ansible customizations are usually made through configuration overrides and custom container images.
- OpenStack-Ansible customizations are usually made through role variables and overrides in the deployment repository.
- Either way, inventories and configuration should live in version control so changes can be reviewed and rolled back.
Tell us which method you run, or which one you plan to use, so the scope names the correct files and procedures.
Is ongoing support for customized OpenStack available as a retainer?
Yes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, in addition to fixed-scope projects. A retainer suits customizations that need regular review after each upstream release, policy change or new integration. Ask the following when you compare options:
- Which services and customizations the retainer covers, and which items are billed separately.
- How upgrade testing for each customization is scheduled around SLURP and non-SLURP releases.
- How requests are logged, prioritized and reported back to your team.
- What happens to customizations when the retainer ends, including documentation and handover.
The retainer terms should be written with the scope so the recurring cost and its boundaries are clear before work begins.
How DeployOpen scopes, builds and hands over OpenStack customization
DeployOpen plans, implements, documents and supports OpenStack customization inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. We keep changes close to upstream so that later upgrades remain a planned task rather than a rebuild of your customizations.
How we scope
- The written scope lists each customization: flavors, quotas, policies, Horizon branding, Heat templates and integrations.
- We record which upstream services and APIs each change touches, so reviewers see the upgrade impact before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work begins.
How we build
- Customizations are built as declarative configuration and templates kept under version control, not as edits to upstream code.
- Policy and quota changes are tested against representative projects and roles before they reach production tenants.
- Horizon branding and Heat template changes are checked in a non-production environment that mirrors your deployment tooling.
How we hand over
- You receive the configuration repository, change records and a written map of each customization and its owner.
- Runbooks explain how to apply, roll back and re-test each customization during a routine OpenStack upgrade.
- Your operators are walked through the handover, and open questions are logged with an agreed owner and next step.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that covers your customizations after handover.
- Before each upgrade, we re-test each customization against the target release notes and the maintained branch in use.
- Ask in the quote which customizations the retainer covers, how change requests are logged and how upgrade testing is scheduled.
