yeke.io · pricing
Two tiers: Community and Enterprise.
Start free with Community. Choose Enterprise for higher capacity, enterprise identity and approval workflows. Enterprise is licensed per cluster.
Tiers
Choose the tier that fits your needs.
Community
Community is free and does not expire. Installation requires no account, email address or license key.
- Complete operation flow. Plan, dry-run, guardrails, approval and apply, including built-in policies and your own policy files.
- Audit trail. Read and filter operations with both the YEKE user and Kubernetes identity.
- Your AI provider. Use your provider key or an internal OpenAI-compatible endpoint.
- Both cluster connection modes. The agent tunnel and direct kubeconfig; neither is gated.
- Terminal and logs. Everyday operation tools are included in Community.
- Monitoring, diagnosis and KubeWorld. Node, pod and workload series with nothing extra to install in the cluster (in agent mode; no Prometheus, no metrics-server). “Diagnose” opens the chat with context, “Run scan” produces a root-cause report, and KubeWorld shows the cluster as a city. Included in Community.
- Backup and restore. Database backup steps are documented for every tier.
Enterprise
Enterprise is priced per cluster, not per user or node. Capacity, support scope and price are set in your contract. Contact us for a quote.
Enterprise includes identity integrations, SIEM export, PostgreSQL, HA, governance and GitOps, with higher capacity and SLA-backed support in Turkish. Planned features are marked separately below.
Explore the features and product screens on the Enterprise page.
E1 Identity and compliance
- In the product today LDAP / Active Directory binding
- In the product today Group → Kubernetes identity mapping
- In the product today OIDC SSO (Keycloak, Entra ID)
- In the product today Audit trail export to a SIEM
- On the roadmap SCIM
- On the roadmap SAML
E2 Scale and continuity
- In the product today PostgreSQL driver
- In the product today YEKE core running highly available (HA)
- In the product today Air-gapped install bundle
- In the product today Long retention and archiving
- In the product today SQLite → PostgreSQL migration tool (yeke-migrate)
E3 Governance
- In the product today Dual approval (four eyes)
- In the product today Maintenance windows / change freeze
- In the product today Central policy management
- In the product today Terminal session recording
- In the product today Compliance reports
E4 GitOps
- In the product today GitOps repo reflection
- In the product today Drift visibility
- In the product today ITSM integration
E5 Monitoring: alerting and anomalies
- In the product today Notification channels (e-mail, webhook, chat, ITSM)
- In the product today Alert rules and routing
- In the product today Scheduled scans and reports
- On the roadmap Anomaly detection
E6 Access and Secret management
- In the product today Install-wide Secret display ceiling
- In the product today Key-level Secret access for permission groups
- In the product today Per-user effective access view
Community limits
Community includes everyday management tools for up to 3 clusters and 5 active users.
- 3 clusters, 5 active users. Limits apply to cluster records and YEKE accounts that can sign in. There is no node, vCPU or Pod limit.
- Limits apply from installation. There is no trial period followed by additional restrictions.
- Existing environments keep working at the limit. Only new cluster or user creation is blocked. Reads, changes, approvals, reverts and audit access remain available for existing clusters.
- No license key required. Community makes no activation or periodic license calls and sends no usage telemetry.
- Environment settings cannot lower the limits. There is no variable that reduces Community capacity.
3 and 5 are a starting point and may grow with what we hear from the field.
Enterprise: what exists, what is planned
Available features are marked “In the product today”; planned features are marked “On the roadmap”. No release dates are committed for roadmap items.
- Available and planned features are separate. Badges and solid or dashed borders identify their status.
- The roadmap sets an order, not dates. Base your purchase on the features available today.
- Features are grouped by use case. Identity, continuity, governance, GitOps, monitoring and AI.
E1 Identity and compliance
- In the product today LDAP / Active Directory bindingVerified against a real Active Directory (0.13.0). How it works.
- In the product today Group → Kubernetes identity mappingShipped in the same round as LDAP/AD: an AD group flows into a Kubernetes group through a list defined per cluster.
- In the product today
OIDC SSO (Keycloak, Entra ID)Shipped in 0.14.0 under
the same license item (
sso); it can run alongside LDAP. Verified against a real Keycloak; not measured against Entra ID. No SAML. - In the product today
Audit trail export to a SIEMShipped in 0.14.0
(
audit-export): TLS syslog (CEF) and a signed webhook. Reading the trail is free in every tier — what is sold is the export. - On the roadmap
SCIMA sibling of
sso— it connects the organization's own identity system to YEKE. It was under E6 until 23.09.2026. The name is reserved in the dictionary; no gate reads it yet. - On the roadmap SAMLMoved to E1 in the same decision. The name is reserved in the dictionary; no gate reads it yet.
Connect users to your identity system and send audit records to your SIEM.
E2 Scale and continuity
- In the product today
PostgreSQL driverA second backend next to the
single-file SQLite. YEKE connects to a PostgreSQL your organization already runs — it
does not install, cluster, back up or operate PostgreSQL itself. Supported connections:
a direct connection to postmaster, or a
session-mode pooler;transaction/statementpooling is not supported. - In the product today HA for YEKE core. Multiple replicas on PostgreSQL keep the console and API available during upgrades. Cluster access may briefly disconnect while an agent reconnects. Your organization operates PostgreSQL.
- In the product today
Air-gapped install bundleA single-machine install
for network-isolated environments: the compose bundle needs only
docker— no internal registry, no outbound network call at any step. The package is signed with Ed25519, verified out-of-band against a separately published public key. Boundary: core itself runs on one machine via compose, but the agent and toolbox images still need a registry the target Kubernetes cluster can reach — YEKE manages remote clusters through the agent tunnel, it does not run one itself. - In the product today Long retention and archivingRuns only in PostgreSQL mode: a deleted operation is copied into an archive table in the same transaction as the delete, and stays readable through a dedicated API. SQLite mode is unchanged.
- In the product today
SQLite → PostgreSQL migration tool (
yeke-migrate) Moves an existing SQLite installation into PostgreSQL: offline (core stopped) and one-way only. Verified with a synthetic fixture, not against real production volume.
Database and high-availability options for production.
E3 Governance
- In the product today Dual approval (four eyes)A policy-matched rule asks for the consent of a second user who is not the plan's owner and holds an identity on that cluster; the approver only consents, the owner still applies the plan.
- In the product today Maintenance windows / change freezeAn approved plan's apply waits inside a defined window; every window's time zone is required and the plan record stays unmutated.
- In the product today Central policy managementThe policy set can also be loaded from a single Ed25519-signed package instead of a file; it takes effect immediately but never touches a plan already in flight.
- In the product today
Terminal session recordingOpt-in per cluster
(off by default): once enabled, terminal sessions are stored as full encrypted pty
recordings and downloaded as asciinema (
.cast). - In the product today Compliance reportsA single endpoint produces a cluster × period change report; the report is derived from the audit trail and carries its own integrity proof.
Add a second approval, scheduling restrictions and auditable records to changes.
Phase E3 is complete (0.26.0/0.26.1, 04.09.2026). All five items are in the product and passed acceptance against a real PostgreSQL; setup steps and operator behaviour are on the Governance page.
E4 GitOps
- In the product today GitOps repo reflectionA console change is applied AND its YAML counterpart in the repo is updated; what will change is shown before you approve.
- In the product today Drift visibility
- In the product today ITSM integrationNot a ready-made connector: an example endpoint built on the hook (iTop), its documentation and setup support — no licence gate.
Repo and change-process integration for teams using Argo CD or Flux.
Repo reflection and drift visibility are available. Inserting into the middle of a list can shift neighboring lines; references in files that cannot be parsed cannot be scanned. ITSM integration provides an example iTop endpoint, documentation and setup support.
E5 Monitoring: alerting and anomalies
- In the product today Notification channelsE-mail, webhook, and chat (Google Chat, Slack, Teams) are in the product today. ITSM connects over the webhook — not a ready-made driver, a stable contract. A crossed threshold, a data outage, and a scheduled scan's report summary (finding counts, the first 10 findings, a link to the report) come to you.
- In the product today Alert rules and routingThreshold, duration and scope; who hears, over which channel, and when.
- In the product today Scheduled scans and reportsThe scan you used to start by hand now also runs on a per-cluster interval (every 6, 12, 24 hours, or weekly); the owner check runs again on every occurrence, and the report lands in the notification channel and as a single-file HTML document.
- On the roadmap Anomaly detectionOne step past the scan: not a fixed threshold but a departure from the cluster's own last 14 days. The method is in the product and measured in shadow mode (visible on the Alerts tab), delivery to a channel isn't there yet.
Builds on the monitoring and scan already in Community: the series, the report, rules, the channel and now scheduled scanning exist today; what is pending is carrying the same view to a departure from the cluster's own normal (anomaly) — the method is measured in shadow mode, delivery to a channel is a later release's subject.
Scope will be refined around customer requirements; no dates are committed.
E6 Access and Secret management
- In the product today
Install-wide Secret display ceiling
YEKE_SECRET_DISPLAY=masked|hidden— values can be hidden from everyone, owner included. Shipped in 0.57.0 (secret-display); the name is unchanged, only its phase moved here from E3. - In the product today
Key-level Secret access for permission groups
(
secret-keys) A permission group can get a "Can view / Can edit" rule per namespace, Secret or key; without a rule the value stays hidden. Used to ship flagless (free); from this release it requires Enterprise — the foundation of permission groups (definition, membership, RBAC generation) stays Community. - In the product today
Per-user effective access view
(
effective-access) Lets an admin see what another user can actually reach in the cluster right now; the endpoints that read a user's own access stay Community. - In the product today
Secret versions
(
secret-versions) Every YEKE write to a Secret is versioned automatically (rN+ date); a change made outside YEKE is caught on the next YEKE write. A single key or the whole Secret can be restored through an approval card, and a deleted Secret can be recreated from its history. See Secret versions.
One item for the organization's own security/access owner: who can see which Secret, under which rule, and what changed in its history.
The old E6 (managed AI) is removed (0.58.0). It was never wired to any gate; the names left the dictionary. A license carrying the old name is treated as having unlocked all three items of the new E6 — existing licenses lose nothing.
The scope and response times for SLA-backed support in Turkish are defined in the contract.
Deliberately staying free
These are in Community today; each row gives the reason and names the paid part.
| Item | Why it stays in Community |
|---|---|
| Two-step verification (TOTP) | A second factor is a baseline security control, not a sales line item — and its real audience is precisely the team on the free tier: an enterprise customer already enforces a second factor in its own identity provider. What is paid for is not the second factor itself but the identity-provider integration (E1) — plus the export of MFA events and the compliance report. |
| In-house model endpoints | An honest reading of "bring your own key and model" includes the model running on your own servers. The value of Enterprise AI is the managed key, the policies and the reporting — not a monopoly on the endpoint URL. |
| Guardrails and your own policy directory | The chain is the identity of the product. What is Enterprise is central distribution of policies, not the protection itself. |
| Reading the audit trail | Part of the trust claim. Only the export and reporting layer is paid. |
| Exec/terminal and log streaming | Part of daily operations. Only session recording is paid. |
| Backup and restore | Data is never held hostage: the backup path is documented for every tier. |
| Monitoring (30-day history) | You can't run a cluster you can't see; the agent collects the metrics and there is nothing extra to install. What is paid for is 90-day history, alerts and anomaly detection — not the measurements themselves. |
| Scan (manual scans and JSON report) | Scans run on your own AI provider, so the model cost is already yours and the product asks for no license on top. What is paid for is scheduled scanning and the HTML version of the report. |
| KubeWorld | It collects no new data; it reads what monitoring and the live lists already carry and draws it as a city. It is part of monitoring, so it sits in the same tier. |
Licensing and buying
Load your Enterprise license to enable the capacity and features in your contract. The license is signed and verified offline.
- Verified entirely offline. There is no license server to reach, no online activation and no periodic check — it behaves identically in an air-gapped install.
- The license belongs to your organization. It is not locked to a machine or hardware configuration.
- Community capacity is preserved. Loading a license cannot lower the effective limits below Community.
- Expiry starts with a warning. Usage continues during the contractual grace period. Afterward, new clusters, users and enterprise configuration are restricted. Local administrator access remains available; each technical guide describes its feature’s license behavior. Some configurations, including PostgreSQL and central policy mode, require a valid license.
- Your existing data is preserved. Check each feature’s guide for its behavior in different license states before deployment.
Enterprise scope, limits and price are settled in a conversation. You need no license to try the product yourself: the deployment guide is Community from beginning to end.
yeke.io
Install first, talk later.
Install Community and try it on your own cluster. Contact us for enterprise features and support.