# OpenEverest put its v2 preview on main and moved the released v1 line to v1.x

> A Kubernetes platform for provisioning and managing databases, storage and model endpoints, installed either with a Helm chart or with a CLI that has embedded Helm since version 1.4.0. The branch you clone decides which product you get, and the page says so before it says anything else. The server ships with a default admin account and no external exposure by default.

**openeverest/openeverest** — OpenEverest is an open-source platform for automated database, storage and LLMs provisioning and management. It supports multiple technologies and can be hosted on any Kubernetes infrastructure, in the cloud or on-premises.

- Repository: https://github.com/openeverest/openeverest
- Website: https://openeverest.io/
- Stars: 945 · Forks: 220
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/openeverest-openeverest

## The branch swap is the first thing the page tells you

The status block at the top of the file is a branch map, not a feature list. The branch you are reading carries v2, which is a developer preview, explicitly not feature-complete and explicitly not for production. v1 is the current released version, it is unchanged by any of this, it lives on a branch called v1.x, and it continues to receive releases. The mechanics are dated: on 18 August 2026 the two lines swapped branches, with v2 moving from release-2.0 to main and v1 moving to v1.x. Both lines are still developed, and the page is emphatic that only the branch names changed and that this is not a statement about what to run. The consequence for existing users is the last line of the block: if you cloned or forked before that date, your main still holds v1 code, and there is a section in CONTRIBUTING.md called Which branch to target that you are pointed at before you branch. What the project claims to be is seven short lines: launch a database instance with a few clicks, let the team develop faster and reduce time to market, scale without ceremony, simplify maintenance, monitor and optimize, automate backups, and keep the data secure. The framing above them is about regaining control of data, database configuration and DBaaS costs, which is the same claim the name makes about taking back a managed service.

## Two install routes that both end in the same chart

Helm is the recommended route and the CLI is the alternative, but they are not really two mechanisms any more. The chart repository is added with a helm repo add pointing at a GitHub Pages index, and the release is installed as a chart named everest-core into a namespace called everest-system with the namespace created on the fly:

```bash
helm repo add openeverest https://openeverest.github.io/helm-charts/
helm repo update
```

```bash
helm install everest-core openeverest/openeverest \
  --namespace everest-system \
  --create-namespace
```

The CLI reached the same place by growing into Helm. Starting from version 1.4.0, everestctl uses the Helm chart to install OpenEverest, and its parameters are chart parameters, set individually with a helm.set flag or supplied wholesale through a values file. The prerequisites are the same for both: an existing Kubernetes cluster such as Amazon EKS or Google GKE, and, for the CLI, working cluster access verified with kubectl get nodes and a kubeconfig at the default path or pointed at with the KUBECONFIG environment variable.

## The chart is also a Go dependency, pinned by a pseudo-version

The go.mod file is where the relationship between the server and the chart becomes concrete. The module path is github.com/openeverest/openeverest/v2, so the major version is part of the import path even though the v2 line is a developer preview. Among the direct requirements sits github.com/openeverest/helm-charts/charts/everest at a pseudo-version rather than a tag, which means the chart is consumed as a library by the server build and its exact contents are pinned to a specific commit from late September 2026. helm.sh/helm/v3 appears in the same list, at 3.22.0, which is the Helm SDK rather than the command line binary, and it is what lets everestctl perform a chart install from inside the CLI. That pairing is the mechanism behind the 1.4.0 change, and it is why the two install routes cannot drift: they run the same chart from the same dependency graph.

## The default account is admin, and the UI is not published by default

Two defaults shape the first ten minutes. The first is the account. The default username is admin, and a different default admin password can be set during installation with a server.initialAdminPassword parameter, so the password is configurable at install time rather than only after. The Helm route reads the generated secret out of the cluster by pulling the users.yaml key out of the everest-accounts secret in the everest-system namespace, base64 decoding it and pulling the admin password hash with a YAML query tool. The second default is exposure. By default OpenEverest is not exposed via an external IP, and the documented access route is a port forward of the everest service to 127.0.0.1 on port 8080. The CLI route offers the same port forward, and adds an optional patch that changes the service type to LoadBalancer if you do want it published. The CLI path checks cluster access before anything else with kubectl get nodes, and expects the kubeconfig at ~/.kube/config or an explicit KUBECONFIG export if it is elsewhere. The header badges tell you what kind of project is aiming at what: a CNCF landscape entry, a best practices listing, an OpenSSF scorecard view, a clomonitor project page, a Snyk test and an Artifact Hub package search.

## Three CLI binaries, none of them for Windows

The everestctl download instructions cover three targets and no others: Linux and WSL on amd64, macOS on Apple Silicon, and macOS on Intel. Each one is a curl of a release asset, an install with mode 555 into /usr/local/bin, and a removal of the downloaded file, and the asset names are everestctl-linux-amd64, everestctl-darwin-arm64 and everestctl-darwin-amd64. There is no Windows binary and no Linux arm64 binary in that list, so a Windows workstation and an Apple Silicon or ARM Linux machine without an existing binary both have to go through the Helm route or build from source. The CLI itself is a Go program built on spf13/cobra, with terminal output from the charm libraries, so the wizard and the headless flags are the same code path underneath.

## Headless mode is one flag, and the operators are named explicitly

The wizard asks which namespaces OpenEverest should manage, and the headless path asks the same question as a flag, together with the operators you want:

```bash
everestctl install --namespaces <namespace-name1>,<namespace-name2> --operator.mongodb=true --operator.postgresql=true --operator.mysql=true --skip-wizard
```

So the operator set is opt-in and enumerated rather than discovered, which means a fresh install is a specific set of database engines rather than whatever the cluster happens to have. Namespaces can be added later with a namespaces add subcommand, so skipping the question at install time is not permanent. Credentials are then retrieved with an accounts initial-admin-password subcommand, which is the CLI counterpart of reading the secret by hand in the Helm route. The rest of the top-level tree follows the same separation: api/, client/, cmd/, commands/ and internal/ for the server, ui/ for the interface, provider-runtime/ for the provider layer, and separate api-tests/ and cli-tests/ directories, which is why the repository's primary language is TypeScript while its module and dependency graph are Go.

## Two dev images share one tag, and the operator is a development build

The Makefile is where the build surface is declared. Images go to ghcr.io under the openeverest organisation, and there are two of them, a server image and a controller image, named openeverest-dev and openeverest-controller-dev. Both are built from a single IMAGE_TAG variable whose default is 0.0.0, and the two image variables are assembled as that one tag appended to each name, so a local build produces two distinct repositories that happen to share a version string. Tool versions are pinned alongside: controller-tools at v0.18.0, kustomize at v5.7.0, and the VictoriaMetrics operator version at 0.66.1, which matches the VictoriaMetrics operator API dependency in go.mod. The same file derives the envtest version from the controller-runtime major and minor and the envtest Kubernetes version from the k8s.io/api version, rather than hardcoding either, and the percona/everest-operator dependency is itself pinned to a 0.6.0 dev build.

## Conclusion

OpenEverest fits a team that already runs Kubernetes and wants database provisioning, monitoring, backups and operator management in one namespace-scoped tool, with a chart they can read and a CLI for the rest. It is a poor fit for anyone who installs from a fork created before 18 August 2026, because that main branch still holds v1 code, and a poor fit for production on the v2 line, which is described as a developer preview that is not feature-complete. Before installing, confirm which branch your mirror tracks, change the default admin password with the server.initialAdminPassword parameter, and remember the UI is not published to an external IP unless you do it yourself.

## FAQ

### What is on the main branch of OpenEverest?

OpenEverest v2, which is a developer preview that is not feature-complete and not for production. The released v1 line lives on the v1.x branch. The two swapped branches on 18 August 2026 and both are still developed.

### My fork of OpenEverest predates 18 August 2026, what does main hold?

Your main still holds v1 code, because the branch swap happened after your clone. The page points you at the Which branch to target section of CONTRIBUTING.md before you branch from it.

### How do I install OpenEverest with Helm?

Add the chart repository with helm repo add, update it, then helm install everest-core from it into the everest-system namespace with the namespace created. Helm is the recommended method and needs an existing cluster plus Helm installed locally.

### What is the default admin account for OpenEverest?

The default username is admin. A different default admin password can be set at install time with the server.initialAdminPassword parameter, and the generated secret can be read from the everest-accounts secret in the everest-system namespace.

### Is the OpenEverest UI exposed outside the cluster by default?

No. By default it is not exposed via an external IP. The documented access route is a kubectl port-forward of the everest service, and the CLI route also offers an optional patch that changes the service type to LoadBalancer.

## Sources

- [License: Apache-2.0](https://github.com/openeverest/openeverest/blob/main/LICENSE)
- [openeverest/openeverest on GitHub](https://github.com/openeverest/openeverest)
- [Project website](https://openeverest.io/)
- [README](https://github.com/openeverest/openeverest/blob/main/README.md)
- [Releases](https://github.com/openeverest/openeverest/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openeverest-openeverest