A simple portal for teams that need production-ready Kubernetes clusters on Oracle Cloud without writing all the Terraform, networking, access, approvals, and day-2 automation by hand. It runs in your tenancy, so your credentials, logs, and operational data stay with you.
Infrayard gives your engineers a controlled button for creating Kubernetes environments on Oracle Cloud. Your platform team defines the templates, limits, network rules, identity rules, and approval rules. Users request a cluster, Infrayard runs the infrastructure workflow, and everyone gets a visible audit trail.
Kubernetes clusters, worker pools, networking, access files, cost estimates, and lifecycle jobs.
Oracle Cloud. Resources are still created in your tenancy and billed by Oracle.
Terraform is the engine underneath. Engineers use the portal; admins decide what can be created.
Platform, DevOps, and cloud teams standardizing Kubernetes on Oracle Cloud.
The landing page version: fewer tools, fewer handoffs, fewer manual cloud steps. The docs can go deep on the exact Terraform, Oracle Cloud, and security details.
Engineers choose an approved template or custom configuration. Infrayard creates the Oracle Kubernetes Engine cluster and the required cloud resources.
Add or remove worker pools, change CPU and memory, scale environments down, run Kubernetes upgrades, and clean up clusters through guided workflows.
See hourly and monthly estimates before creating or changing a cluster. Admins can review total estimated spend across active clusters.
Require approval for protected destroys and higher resource limits. Users and admins get a clear history of what happened, who approved it, and when.
Admins define the available network ranges. Infrayard allocates one per cluster, prevents overlap, and releases it when the cluster is destroyed.
Authorized users can download Kubernetes access files without learning the Oracle Cloud CLI. Network access still follows your private or VPN design.
Terraform runs are visible during deploy, scale, upgrade, and destroy, so the platform team can inspect the infrastructure workflow instead of guessing.
Point Infrayard at existing compartments, virtual cloud networks, or subnets when your organization already owns those foundations.
Define global and per-user limits for clusters, worker pools, CPU, memory, and storage. Users can request more when they need it.
Admins define approved cluster templates: Kubernetes version, machine shape, worker pools, expiry time, destroy protection, and who can use them. Users only see the choices they are allowed to use, so the portal stays simple.
Users without the production role never see this template - clean UI, no error messages.
testing → QA teamuat → release managersproduction → SRE onlyUsers see estimates while they configure a cluster. Admins can track estimated spend across active clusters and adjust rates for custom Oracle contracts.
Hourly and monthly estimates update as users choose worker pools, machine shape, and cluster tier.
Dashboard cards and detail pages show estimated cost per cluster, including worker pools and control plane tier.
Admins see total estimated monthly spend across active clusters and can use custom rates for enterprise contracts.
OCI Pay-As-You-Go rates + admin overrides for custom enterprise contracts.
Admins manage allowed resources, templates, requests, approvals, configuration, and audit history from one place.
See every cluster, owner, status, Kubernetes version, resources, cost, and age.
Set global defaults and per-user exceptions for resource limits.
Manage network ranges, machine shapes, Kubernetes versions, images, and default limits.
Publish approved cluster sizes and settings for different teams or environments.
Review protected destroy requests and higher-limit requests before they take effect.
Keep a searchable record of deploy, scale, upgrade, and destroy actions.
Infrayard is installed in your environment. There is no hosted SaaS control plane that needs your credentials or operational data.
Use bundled Keycloak or connect Azure AD, Okta, Google Workspace, or another OpenID Connect provider.
Uses the Authorization Code flow with PKCE, so frontend code does not store client secrets.
Users can be created on first login, then governed by roles, templates, and resource limits.
Identity configuration is cached so normal page loads avoid unnecessary discovery calls.
For teams that want Kubernetes self-service on Oracle Cloud, but still need the platform, secrets, and operations to stay inside their own boundary.
Clear separation between available product capabilities and roadmap ideas. Every phase keeps the same customer-boundary model: no Solvia-hosted control plane and no credentials, Terraform state, audit logs, or cluster data sent to a vendor SaaS.
A small group of production teams helping us build the first year of the roadmap. Early-access program with discounted pricing and direct product feedback.
€18,000 for the first 12 months, compared with the €30,000 standard annual Business license.
Monthly roadmap calls, private Slack / email with engineering. Your feedback shapes what ships next.
Near-term scope: Oracle-native Gatekeeper insights for cost, policy drift, compliance, and troubleshooting. Founding feedback also shapes v1.2 multicloud governance for observed EKS, AKS, and GKE clusters without Terraform state adoption.
In exchange: monthly feedback calls and the right to publish a sanitized case study. That's it.
Not ready for a commitment? See standard pricing
Infrayard is delivered as a private commercial product, not a hosted SaaS control plane. Pricing is shown as a monthly equivalent, but production access is contracted upfront to keep procurement and support simple.
Prices are listed in EUR. USD invoicing is available on request using the exchange rate agreed at contracting.
For qualified teams validating Infrayard in their own OCI tenancy. Non-production scope, hard 14-day window.
For teams running Infrayard in production with self-managed day-2 operations.
For regulated or mission-critical organizations that require formal operating guarantees and shared responsibility.
Short answers first. Deeper implementation details belong in the documentation.