what it is, before any of the blog posts make sense

About OpenEverest

Before the PR stories here make sense, you kind of need to know what OpenEverest actually is. So here's the plain version, from reading its README and source, not the marketing page.

Quick heads up: OpenEverest currently has two live versions. main is v2, a developer preview, not what most people run in prod yet. The actual production release is v1, on branch v1.x. Everything here is about v2 unless I say otherwise, because that's the branch I'm working against.

the problem it’s solving

Running a database properly on Kubernetes is more work than most teams want to do by hand: provisioning, backups, restores, monitoring, upgrades, who’s allowed to touch what. OpenEverest is an open source platform that installs into a cluster and takes that off your plate. You describe what you want, a database, a backup schedule, some permissions, and its controllers make the cluster match that and keep it that way.

You never touch Kubernetes directly. Three doors, same destination:

the web UI, if you want to click through it
everestctl, the CLI, for scripting
the REST API directly, if you’re building your own thing on top

All three hit the same API server, which is the only thing actually talking to Kubernetes for you.

the data model, aka what actually gets created

Here’s the part that took me the longest to get: OpenEverest doesn’t really have “features.” It has Kubernetes custom resources, and controllers that react when they change. Whatever you do through the UI or CLI eventually becomes one of these.

simplified. an Instance runs on a Provider. Backups and Restores point at a BackupStorage. MonitoringConfig watches an Instance. Plugins and Providers both get installed through InstalledExtension (dashed line: yeah, it can install a Provider too, not just a Plugin, naming is a little confusing).

If you know v1, the big change in v2 is right at the top of that diagram. v1 had one resource, DatabaseCluster, that assumed a small fixed list of supported databases. v2 swapped that for the generic Instance plus a pluggable Provider, so new engines can get added without touching core.

a Backup isn’t always handled the same way

Didn’t notice this until I was fixing an actual bug in one. Every Backup references a cluster-scoped BackupClass, and that class declares an executionMode that decides who’s actually driving the backup:

Job: the core’s own in-cluster job controller reconciles it directly, reading the Backup object itself and running the work.
ProviderManaged: the core steps back and hands it to the provider. The Instance has to explicitly register which BackupStorages it’s willing to use (spec.backup.storages), and from then on the provider’s own reconciler watches the Backup, talks to its database engine’s operator, and writes the real status back, including, this being the actual bug, the real start and completion time, not a guess.

Same CRD either way, from the outside a Backup looks identical. The execution mode is what decides whether core or the provider is the one actually doing the work and reporting on it.

the plugin system

Honestly the part I find most interesting, and it’s newer than the rest of this. OpenEverest lets you extend it without touching core code, on both ends:

backend: a Plugin resource declares a frontend bundle, an optional backend service, and the permissions it needs. The API server exposes GET /v1/plugins for discovery and proxies /v1/plugins/:name/* straight to that plugin’s backend, re-reading the Plugin object from Kubernetes on every request. So a change takes effect without restarting anything.
frontend: the web UI loads each plugin’s JS bundle and lets it register into specific slots, a route, a sidebar item, a tab, a settings panel, a dashboard widget. It doesn’t get free rein over the UI, just named places to plug into.

Basically the same idea Kubernetes uses for CRDs, one layer up: don’t hardcode every feature, give people a defined way to bolt their own on.

it’s not actually one repo

Took me a while to notice this, I’d been treating openeverest/openeverest as “the project” because it’s the one with the CONTRIBUTING.md I’d read. It’s one piece. The org has 30-plus repos: hub (where you discover installable providers and plugins), helm-charts, a separate provider-* repo for every database engine (Postgres, MongoDB, MySQL, ClickHouse, Milvus, and more), a family of plugin-* repos, the website, even a homebrew tap for the CLI. Each provider repo ships its own Tiltfile, its own CI, sometimes its own contribution norms, some don’t even run the same /assign bot the core repo does.

The Provider and Plugin CRDs from the diagram above are basically the technical expression of this: the core repo doesn’t know or care what’s in provider-percona-postgresql at compile time, it just knows how to install and talk to something that satisfies the provider contract. The org structure mirrors the plugin architecture. That’s either a nice bit of consistency or just what naturally happens when you build a plugin system and then actually use it for your own first-party integrations too.

what it’s built with

backend: Go 1.26. API server runs on echo. Controllers use controller-runtime, the standard for writing Kubernetes operators. Permissions go through casbin. CLI is built with Cobra.
frontend: React, TypeScript, Vite, MUI for components, TanStack Query for data.
packaging: installs via Helm.

More internals, with diagrams of how a request actually moves through the system, on the Architecture page.

written from reading /README.md, go.mod, api/, internal/server/plugins.go, and docs/process/generic-plugins-design.md in the repo. i’ll fix this page as i understand more instead of leaving a wrong first draft up.