Known Limitations
Things OpenPrime does not do yet, or does in a way you should know about before you rely on it. This page exists so you find them here rather than halfway through an evaluation.
The generated EKS cluster has a public API endpoint​
Infrastructure generated by OpenPrime creates an EKS cluster whose Kubernetes API server endpoint is reachable from the internet. This is a deliberate choice, not an oversight.
The generated pipeline applies Kubernetes resources from a GitHub-hosted runner, which sits outside your VPC. Reaching a private-only endpoint from there would require either a self-hosted runner inside the VPC, a bastion, or a second CI system — each of which breaks the "generate and deploy" flow the product is for.
What is and is not exposed. The API endpoint is reachable; the cluster is not open. Access still requires AWS IAM credentials plus a matching EKS access entry, exactly as it would with a private endpoint. Your workloads and nodes stay in private subnets.
If this does not meet your requirements, set endpoint_public_access = false
in the generated terraform/aws/terraform.auto.tfvars (it ships as true) and
run the Kubernetes stage from a runner inside the VPC. The generated pipeline
will not work unchanged after that.
Restricting the endpoint by IP is not a workable middle ground: GitHub's runner
address ranges run to thousands of blocks, and EKS caps public_access_cidrs at
40.
Deployment status is not tracked​
Every environment shows the status pending, always. OpenPrime generates
infrastructure code and pushes it to your repository; it does not watch what
happens afterwards, so it cannot tell you whether an apply succeeded, what is
running, or whether live infrastructure has drifted from the code.
Use your CI pipeline and your cloud console as the source of truth for what is actually deployed.
AWS only​
Terraform is generated for AWS. Azure, GCP and on-premise appear in the roadmap but are not selectable and generate nothing today.
Custom Helm values are saved but not applied​
The Helm chart editor stores the YAML you write against the environment, and it
survives edits — but nothing in the generation pipeline reads it yet. Charts are
generated with their defaults, and the enabled flag is the only chart setting
that currently affects output.
To customise a chart today, edit the values file in the generated repository after the push.
No import or clone​
An environment's configuration can be exported for reference, but there is no path to import it back or to copy an existing environment. Recreating one means going through the wizard again.
Sessions do not survive an identity-service restart​
The hosted service runs a single Keycloak instance without a shared session cache. When it restarts — during a deployment, for example — active sessions are lost and you will be asked to sign in again. Work already saved is unaffected.
There is no password reset​
The sign-in page does not offer a "Forgot password" link, because there is no mail server configured to send one — the link used to be shown and could never have delivered anything.
If you cannot sign in, contact us and we will reset the account manually. Adding self-service reset is tracked and needs a mail provider first.
Social login and enterprise SSO need configuring​
Authentication runs on Keycloak, which supports social login and SAML/LDAP federation. None of it is configured out of the box: enabling any of it means setting the identity provider up yourself in the Keycloak admin console.