Which OpenMetadata deployment fits: Docker, Kubernetes or bare metal
Use Docker for evaluation, and choose Kubernetes or bare metal for production. Picture a platform team that has trialed OpenMetadata locally and now needs a catalog that business users can rely on, with a named owner, backups and an upgrade path. The OpenMetadata deployment documentation lists a hosted sandbox and local Docker as quick start options, and it lists AWS EKS, Azure AKS, Google GKE, on-premises Kubernetes with Helm charts, and bare metal on physical or self-managed servers without Kubernetes as production options. The choice between the two production paths depends mainly on whether your organization already operates Kubernetes well and whether that platform meets your cluster hardening and secrets standards. Kubernetes fits better when your platform team already runs clusters in EKS, AKS, GKE or an on-premises distribution and has people who can manage Helm releases, namespaces, network policies and secrets. The OpenMetadata Kubernetes guide runs the application from Helm charts on ports 8585 and 8586 and connects it to an external database, search engine and orchestration tool, so you inherit the cluster's upgrade, scaling and observability practices. Kubernetes assumes skills in cluster administration, and a control plane you must keep current: the Kubernetes project maintains only the three most recent minor releases, so confirm which version your provider supports before you pin a chart.
Bare metal fits better when you have no Kubernetes platform to build on, or when a compliance boundary is easier to document on a small set of servers you control. The bare metal documentation requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, plus Airflow for metadata ingestion, so your team must install, patch and back up each service directly. Ask your team who will own OS patching, JVM and database upgrades, and restore tests before you commit. Whichever path you choose, confirm the exact versions against the current release notes, since OpenMetadata 2.0 introduced breaking changes that affect ingestion images and upgrade order.
Kubernetes and bare metal side by side for OpenMetadata
This table compares the two production paths for OpenMetadata, Kubernetes with the official Helm charts and bare metal on self-managed servers, across ownership, dependency placement, versions, sizing and upgrades. Read each row as a question to answer for your own team: who runs the control plane or host, and who carries the upgrade work. Docker is documented for local trials only, so it is noted in the last row rather than compared as a production target.
| Factor | Kubernetes with Helm charts | Bare metal or self-managed servers |
|---|---|---|
| Platform license | OpenMetadata is Apache-2.0. Kubernetes is also Apache-2.0, so there is no license fee for either layer; managed Kubernetes services bill separately. | OpenMetadata is Apache-2.0 with no license fee. There is no orchestration layer to license or operate beneath it. |
| Control plane or host ownership | Your team or your cloud provider runs the cluster. Managed services such as EKS, AKS and GKE handle the control plane, while you still own node pools, networking and upgrades. | Your team owns every server, operating system, service process and its patching. No cluster layer sits between the application and the host. |
| Database and search placement | MySQL or PostgreSQL and Elasticsearch or OpenSearch are connected as external services. Confirm whether you run them in the cluster or use managed offerings. | Database and search run on separate hosts or the same hosts as the application, configured by you. Confirm the placement that your data protection policy requires. |
| Dependency versions | Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x are the same requirements as bare metal. Confirm the chart version pins each one. | Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x (minimum 9.0.0, recommended 9.3.0) or OpenSearch 3.x (minimum 3.4.0) per the bare metal docs. The 9.x Elasticsearch client does not work with 8.x or older servers. |
| Minimum sizing | Minimum sizing is 2 vCPUs and 4 GB memory for one application replica, plus 2 vCPUs, 2 GB RAM and 30 GB storage each for search and the database, per the bare metal docs. Node pool capacity must cover these requests. | Minimum server sizing is 2 vCPUs, 4 GB RAM and 20 GB storage for the application, with the database and search each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. |
| Upgrade path | Helm chart upgrades are applied to the release, but the Kubernetes minor version must also stay supported. Kubernetes 1.37, 1.36 and 1.35 are the currently maintained minors, so plan cluster upgrades around those dates. | Application upgrades are performed by your team on each host, with ingestion images and Airflow pairings reviewed per release. Plan for a rolling restart of services you manage yourself. |
| Operating effort | Your team needs Kubernetes operations skill, including RBAC, secrets handling and cluster upgrades. Managed services reduce the control plane burden but not application-level work. | Your team needs Linux administration, service management and backup scripting. There is less platform abstraction to learn, but more manual host work. |
| Docker | Docker is documented for local trials only and is not compared here as a production target. | Docker is documented for local trials only and is not compared here as a production target. |
How each option runs in practice: evaluation, cluster or server
Local Docker suits evaluation. A single engineer or a small group can explore the catalog, connectors and lineage views on one host before committing to a production design. The OpenMetadata deployment docs list local Docker as a quick start option alongside a hosted sandbox, and they place the production options separately.
- Who it suits: Data stewards and platform engineers who want to see the UI, run a few connectors and judge fit.
- What you operate: One host running the containers, with no designed high availability, no backup routine and no upgrade procedure.
- What to have ready: A host with enough memory for the application, search and database containers, a sample data source to connect, and a decision on the Java 21 and search versions you will carry into production.
- When to move: When a team depends on the catalog, when SSO and access controls are required, or when more than one person needs to rely on the metadata.
Treat the trial as disposable until you confirm with the vendor whether trial configuration, connector definitions and metadata can be carried into a production install. Check the image tag against the release you plan to run, because the 2.0 line includes breaking changes listed in its release notes.
Kubernetes suits platform teams that already operate clusters on AWS EKS, Azure AKS, Google GKE or on-premises infrastructure. The OpenMetadata Kubernetes docs install the application through Helm charts on ports 8585 and 8586 and connect it to an external database, search engine and orchestration tool. Your team owns the release, but the cluster and its dependencies sit in your platform.
- Cluster lifecycle: Upgrade the kube-apiserver one minor version at a time, and expect kubelets to trail by up to three minor versions. As of September 2026 the maintained minor releases were 1.37, 1.36 and 1.35.
- Control plane design: Self-managed clusters need a highly available control plane, typically three control plane nodes with a TCP load balancer on port 6443. Managed services shift part of this to the provider, so confirm the responsibility split in writing.
- Secrets handling: Kubernetes Secrets are stored unencrypted in etcd by default, so configure encryption at rest or an external secrets store before loading database and search credentials.
- Identity: Kubernetes authenticates administrators through certificates, OpenID Connect or JWT tokens, webhooks or an authenticating proxy. Confirm separately how OpenMetadata user login will integrate with your identity provider.
Choose this model when you need repeatable upgrades, separate environments and a named owner for the cluster. Confirm that the database, search and Airflow services in your design meet the versions and sizing listed for OpenMetadata before you request cluster capacity.
Bare metal suits teams with fixed physical or self-managed servers, strong Linux administration skills, or a data center standard that does not use Kubernetes. The OpenMetadata bare metal docs describe a direct install with no orchestrator, so the server team owns every component and every failure path. Confirm the exact layout for your release in the bare metal deployment documentation before procurement.
- Prerequisites: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x (9.3.0 recommended) or OpenSearch 3.x (3.4.0 minimum), plus Airflow for ingestion.
- Sizing floor: At least 2 vCPUs, 4 GB of RAM and 20 GB of storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB of RAM and 30 GB of storage.
- Search compatibility: The 9.x Elasticsearch client does not work with 8.x or older servers, so check the search version before any in-place change.
- Version pairing: Match the OpenMetadata release to the Airflow version its docs list. The 2.0 ingestion images use Python 3.12 and Airflow 3.3.0.
- Operations: Restart behavior, failover, backups of the database and search data, patching and certificate handling all become your responsibility.
Move from bare metal to a clustered model when availability targets outgrow a single server design. Ask the vendor whether the minimum sizing covers your connector count and metadata history before you order hardware.
Four dependencies every production install connects to
A production OpenMetadata install is more than one container. Four components connect to the application, and each one carries its own version floor and its own operating burden. Who owns each piece changes between Kubernetes and bare metal, so check the ownership split before you choose a deployment path.
Application runtime on Java 21
The OpenMetadata server runs on Java 21, which is the documented requirement for bare metal installs. On Kubernetes, the Helm charts package the runtime inside the container image, so your team mainly tracks chart and image versions. On bare metal, your team installs the JDK, patches the operating system and manages the service process. Confirm the Java version against the release you plan to deploy before you build the host image.
Relational database: MySQL or PostgreSQL
The database stores OpenMetadata's entity and configuration data. The documented floor is MySQL 8.0.42 or later, or PostgreSQL 15 or later. On Kubernetes, the database is an external dependency you connect to, so it can be a managed cloud service or a cluster you operate. On bare metal, your team owns installation, backups, point-in-time recovery, patching and failover. Ask who restores the database and how often that restore is tested.
Search: Elasticsearch 9.x or OpenSearch 3.x
Search powers discovery across catalog assets. Use Elasticsearch 9.x (minimum 9.0.0, recommended 9.3.0) or OpenSearch 3.x (minimum 3.4.0). The Elasticsearch 9.x client does not work with 8.x or older servers, so an upgrade of the search cluster must happen before the client changes. Kubernetes teams usually run search as a managed or operator-managed service; bare metal teams size heap, shards and disk themselves and watch index health.
Ingestion orchestrator: Apache Airflow
Metadata ingestion runs as Airflow-driven pipelines, and OpenMetadata's bare metal docs pair each release with a specific Airflow version. OpenMetadata 2.0 moved ingestion images to Apache Airflow 3.3.0, and Airflow 2 has reached end of life, so older Airflow 2 pipelines need planning. On Kubernetes, Airflow is another workload to deploy and upgrade. On bare metal, your team manages the scheduler, workers, connections and secrets. Confirm the Airflow pairing for your release before you schedule connector jobs.
What the Kubernetes option adds to your platform workload
Choosing the Kubernetes path means the cluster becomes a dependency you must keep current, because the OpenMetadata Helm charts run the application pods on ports 8585 and 8586 and expect an external database, search engine and orchestrator. Kubernetes releases arrive about three times per year on a cycle of roughly 14 weeks, and the project maintains only the three most recent minor versions. As of September 2026 those were 1.37, 1.36 and 1.35, so plan a recurring upgrade window rather than a one-time build. Upgrade the kube-apiserver first, one minor version at a time, then the controller manager, scheduler and kubelets, since kubelets may trail the API server by up to three minor versions. Confirm your managed service's upgrade cadence (EKS, AKS, GKE or an on-premises distribution) against the version you run.
The control plane brings etcd into your scope. A kubeadm high availability setup needs at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443, and the stacked or external etcd topology is your decision. Kubernetes guidance says etcd should run with an odd number of members, with five members recommended in production, and it requires a tested backup plan using etcdctl snapshot save with restores through etcdutl. Managed services handle much of this for you, so ask the provider exactly what they back up and what you must back up yourself, such as application manifests and Helm values.
Secrets need specific attention. Kubernetes stores Secrets unencrypted in etcd by default, so the database credentials and search credentials OpenMetadata needs are exposed to anyone who can read etcd backups unless you configure encryption at rest. Restrict list and watch access with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver. Review the Kubernetes Secrets good practices guide with your security team before the first install, and confirm how your cluster's identity provider maps users to roles.
Upgrades, backups, monitoring and skills for each production option
This table compares who owns upgrades, backups, monitoring and day-two skills for OpenMetadata on Kubernetes versus bare metal. Read it as an operating checklist: the production option you pick decides which team carries each duty. Use it to size the staffing conversation before you commit to an architecture.
| Operating duty | Kubernetes with Helm charts | Bare metal on self-managed servers |
|---|---|---|
| Upgrade sequence | Plan a chart and image upgrade, then apply it to the application, ingestion and cluster components in order. Confirm the sequence with the OpenMetadata 2.0 release notes first. | Upgrade Java, database, search and the OpenMetadata services on each host in a planned order. Confirm the sequence with the OpenMetadata 2.0 release notes first. |
| Breaking changes in 2.0 | Read the 2.0 breaking changes before any upgrade, including the llmConfiguration move, the Databricks auth format and the Python 3.12 ingestion image rebuild. | Read the same 2.0 breaking changes, then rebuild custom ingestion images and migrate Great Expectations to 1.3 before upgrading. |
| Airflow version pairing | Pin the Airflow release that matches your OpenMetadata version, since the ingestion tier is a separate deployment you must version and test. | Pair the Airflow release with your OpenMetadata version, as the bare metal docs do (for example, OpenMetadata 1.6.5 with Airflow 2.10.5). |
| Application database backups | Back up the external MySQL or PostgreSQL database on the schedule your managed or self-run database service provides. Confirm restore testing with the database owner. | Back up MySQL or PostgreSQL directly with your own tooling and test restores on a separate host. |
| Search index backups | Snapshot Elasticsearch or OpenSearch. The index can usually be rebuilt from metadata sources, but confirm rebuild time with your own test. | Snapshot Elasticsearch or OpenSearch on the same schedule as the database, with the snapshot repository set up on the server. |
| Cluster state and configuration | Back up etcd if you run self-managed control planes, along with Helm values and Secrets, since Secrets are stored unencrypted in etcd by default. | No etcd to back up. Keep the OpenMetadata configuration files and service unit definitions under version control and in backups. |
| Monitoring ownership | Platform team monitors nodes, pods, the control plane and the ingestion schedule. Application health relies on the OpenMetadata endpoints and logs. | Operations team monitors host CPU, memory and disk, service status, database and search health, and ingestion runs on the Airflow host. |
| Skills required | Kubernetes administration, Helm, RBAC, certificate and secrets handling, and etcd operations if you run the control plane. | Linux service management, Java runtime tuning, MySQL or PostgreSQL administration, Elasticsearch or OpenSearch operations and Airflow administration. |
What bare metal asks of your server team
Choose bare metal only if your server team will own every layer that Kubernetes would otherwise handle for you. The OpenMetadata bare metal documentation lists Java 21 as the runtime requirement, MySQL 8.0.42 or later or PostgreSQL 15 or later for the metadata store, and Elasticsearch 9.x (minimum 9.0.0, recommended 9.3.0) or OpenSearch 3.x (minimum 3.4.0) for search. It also notes that the 9.x Elasticsearch client does not work with 8.x or older servers, so check the search version before you install anything. Ingestion runs on Airflow, and the docs pair each OpenMetadata release with a specific Airflow version. The pairing shown in the docs, OpenMetadata 1.6.5 with Airflow 2.10.5, is an older example. Confirm the current pairing for your release in the bare metal page and in the OpenMetadata releases before you size the ingestion host.
The documented minimum for the application server is 2 vCPUs, 4 GB of RAM and 20 GB of storage. The database and the search service each need at least 2 vCPUs, 2 GB of RAM and 30 GB of storage. These are floors for a trial-scale install, not a capacity plan. Real catalog volume, profiler runs and ingestion concurrency will raise them, and the docs should be read for the exact service layout, including whether the search and database hosts are separate machines. Ask your server team to size from your expected number of assets and ingestion schedule, and to treat the documented minimums as the lower bound.
On bare metal, nothing restarts a failed Java process, rotates logs, applies patches or fails a database over to a standby unless your team builds it. Plan process supervision for the OpenMetadata server and ingestion scheduler, a patching window that covers the OS, Java, the database and Elasticsearch or OpenSearch, and tested backups of the metadata database and search indexes, since the search index can be rebuilt but the metadata store cannot. Failover for the database and search tiers is your design decision. Write down who restores a backup, how long that takes in your environment, and who approves upgrades that move the Elasticsearch or OpenSearch version.
How to choose a deployment model and size it before installing
This sequence moves a team from checking its own skills to a sized, backed-up and upgrade-ready OpenMetadata deployment, with each step confirming the release notes first.
Check the release notes for your target version
Before any other step, pick the OpenMetadata release you intend to run and read its release notes. The 2.0 line changed several things that affect planning, including ingestion image rebuilds for Python 3.12, a new llmConfiguration block for embedding credentials, a new Databricks auth format and a required Great Expectations migration to 1.3 before upgrading. Owner: the platform lead with the data engineering lead. Done when the team has written down the release, its breaking changes and the dependency versions that release names, so every later step uses those numbers.
Confirm operating skills for each deployment path
Ask who will run the system day to day. Bare metal means someone must manage Java 21, a database, a search cluster and an Airflow tier directly on Linux servers. Kubernetes means someone must run Helm releases, ingress, persistent volumes and cluster upgrades. Docker is suitable for evaluation, not for a production install. Owner: the head of platform engineering, with a named operator for each component. Done when each component has an owner who has already run similar services, or a training gap is recorded and assigned.
Decide whether a container platform already exists
If your organization already runs a managed Kubernetes service such as AWS EKS, Azure AKS or Google GKE, or an on-premises cluster with its own support model, the Helm-based path usually fits existing tooling, monitoring and access control. If no cluster exists, building one for OpenMetadata alone adds a second system to operate, so compare that cost against a bare metal install. Owner: the architecture lead. Done when the decision and its reason are recorded, with the cluster's support owner named.
Confirm database and search versions for the release
Check the bare metal prerequisites for your chosen release: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The documentation notes that the 9.x Elasticsearch client does not work with 8.x or older servers, so an existing older search cluster cannot be reused without a plan. Owner: the database and search administrators. Done when each version is written against the release notes and any gap is scheduled for upgrade before installation.
Place the Airflow ingestion tier
Decide where metadata ingestion runs and which Airflow version it uses. The bare metal documentation pairs OpenMetadata releases with specific Airflow versions, and the 2.0 notes mention Airflow 3.3.0 for ingestion images. Ingestion needs network access to every source system, so placement determines firewall rules and credentials. Confirm this with the vendor documentation for your release. Owner: the data platform engineer. Done when the Airflow host or cluster, its network paths and the service accounts for each connector are documented.
Size the application, database and search tiers
Start from the documented minimums: 2 vCPUs and 4 GB of memory for one application replica, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and the search service. The bare metal page also lists a 20 GB storage minimum for the server. Treat these as floors, not targets, and add headroom for your catalog size, ingestion frequency and number of users. Ask the vendor or your own load test to confirm the production figures. Owner: the platform engineer with the database administrator. Done when a sizing sheet lists each tier with its CPU, memory and storage and the test or vendor source behind it.
Plan backups for every stateful tier
List each stateful component: the metadata database, the search index and any ingestion state. The search index can be rebuilt from its source, but the database holds the catalog configuration and must be backed up on a schedule you test by restoring. Define retention, restore steps and who can run them. If you choose Kubernetes, also confirm how persistent volumes are snapshotted. Owner: the database administrator with the backup operator. Done when a restore has been rehearsed on a non-production copy and the runbook is stored with the deployment record.
Schedule the first upgrade window
Before go-live, set the cadence for upgrades and the change window that will hold them. OpenMetadata maintenance releases arrive every one to two weeks in the 2.0 line, so the team should decide which releases it will track and test each one in a staging copy first. Confirm the Kubernetes cluster's own upgrade schedule separately if you use that path. Owner: the change manager with the platform lead. Done when a written upgrade policy, a staging environment and a named approver exist, and the first window is on the calendar.
What buyers ask before choosing an OpenMetadata deployment model
Is Docker enough to run OpenMetadata in production?
Docker is well suited to local evaluation, and it is the quickest way to see the product work. For production, the question is less about the container and more about what surrounds it: a database, a search engine, an ingestion orchestrator, backups, upgrades and monitoring all need owners. The OpenMetadata deployment docs list local Docker as a quick start option and place production on Kubernetes or on bare metal, so plan for one of those two models before you put business metadata or access controls into the platform. Confirm with DeployOpen or your own platform team which production model your operations standards support.
What drives the cost difference between Kubernetes and bare metal?
The software licenses are the same, since OpenMetadata is Apache-2.0 licensed. The difference is operating labor and infrastructure overhead. Kubernetes adds a control plane, etcd, ingress, certificate handling and cluster upgrades that your team must run or pay a managed provider to run, while bare metal puts service management, OS patching and failover on your server team. Cost drivers include:
- Infrastructure: nodes or servers, storage and load balancers, plus any managed Kubernetes fees from your cloud provider.
- Skills: existing Kubernetes experience versus Linux and Java service operations.
- Backup and monitoring tooling for the database, search and application tiers.
Ask each option to be priced with the same components and the same recurring operations duties.
How much of the deployment can our own team handle?
A capable internal team can run OpenMetadata in its own infrastructure, provided it covers the full dependency chain. Bare metal requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for metadata ingestion, all of which need patching and capacity planning. Kubernetes adds cluster operations on top. Be honest about on-call coverage and about who owns version pairing between OpenMetadata and Airflow. A common split is for the internal team to keep day-to-day operations while an implementation partner handles design, hardening and upgrade runbooks. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope.
How long does a production OpenMetadata installation take to plan?
The honest answer depends on the number of environments, the dependency choices, network and identity integration, and how many data sources your ingestion must reach. No planning duration is published here, so ask for one in writing rather than relying on a general figure. Planning normally covers sizing, the chosen deployment model, database and search configuration, identity integration, backup and restore testing, and an upgrade path. For a fixed-scope engagement, the written scope should state the deliverables and the timeline before work begins. Your own change approval and security review cycles will often be the longest items.
What should a written quote for an OpenMetadata deployment include?
A useful quote states its scope in writing, names every component in the target architecture, and separates one-time work from recurring work. Ask for these items:
- The deployment model and environments covered, with the OpenMetadata release and dependency versions named.
- Sizing assumptions, including the minimum documented figures of 2 vCPUs and 4 GB memory for one application replica and 2 vCPUs, 2 GB RAM and 30 GB storage each for search and the database, and the sizing you actually plan to use.
- Deliverables for backup and restore testing, documentation and handover.
- Upgrade support, retainer terms and what happens during a breaking release.
- Assumptions about client responsibilities, such as cloud accounts, network access and identity provider details.
DeployOpen does not publish a price list, so a quote follows from this written scope.
Which Kubernetes version and support window should we plan around?
Plan around a version that your Kubernetes distribution or managed service still supports. The Kubernetes project maintains the three most recent minor releases, and as of September 2026 those were 1.37, 1.36 and 1.35, with end-of-life dates of October 28, 2027, June 28, 2027 and February 28, 2027 respectively. Because releases arrive about three times a year, you will upgrade the cluster regularly. The version skew policy requires the API server to be upgraded one minor version at a time before the other components. Confirm which Kubernetes version your target EKS, AKS, GKE or on-premises platform offers, and confirm the OpenMetadata Helm chart version it supports.
Does the deployment model change our security and compliance evidence?
Yes. Each model creates different controls to document. On Kubernetes, Secrets are stored unencrypted in etcd by default, so you need encryption at rest, least-privilege RBAC, and possibly an external secrets store through the Secrets Store CSI Driver. Cluster authentication, pod security settings and etcd backups also become part of your evidence. On bare metal, the same concerns shift to OS hardening, service accounts, file permissions and backup handling. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do. Ask your auditor which evidence they expect before you finalize the design.
Can we move from a Docker trial to production later without rebuilding?
Not automatically. A Docker evaluation is useful for testing connectors and workflows, but its configuration rarely maps directly onto a production database, search cluster and external orchestrator. Plan for the migration explicitly: export or recreate connection configurations, validate ingestion jobs against the production dependencies, and test restore from backup. Also check breaking changes between releases before you upgrade, since OpenMetadata 2.0 changed items such as embedding credential configuration and custom ingestion image requirements. Treat the trial as a learning environment and build the production environment from a written design.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenMetadata, that means choosing the deployment model with your team against your constraints, then building and handing over the full stack, including the database, search and ingestion dependencies.
How we scope
- Engagements are fixed-scope, with deployment target, deliverables and timelines agreed in writing before work starts.
- We confirm which OpenMetadata deployment model fits your environment, whether Docker, Kubernetes or bare metal, before any build begins.
- The written scope lists the database, search engine and Airflow ingestion components each option requires in your environment.
How we build
- We install and configure OpenMetadata with the database, Elasticsearch or OpenSearch, and Airflow version pairings your release requires.
- Sizing, storage and network settings are set against the minimum requirements in the official docs and your expected catalog load.
- Authentication, secrets handling and access controls are configured and tested against the security posture your organization has defined.
How we hand over
- Handover includes runbooks for installation, upgrades, backups and restores, covering each dependency in the chosen architecture.
- Deliverables are documented so your own platform or data team can operate the deployment without relying on DeployOpen day to day.
- Compliance evidence, such as configuration records and access settings, is prepared for your auditors, who issue any assessment outcome.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial fixed-scope work.
- Upgrade planning reviews release notes and breaking changes for each OpenMetadata version before your environment moves.
- Ask any provider to confirm response expectations and what a retainer covers in writing before you sign.
