Documentation Index
Fetch the complete documentation index at: https://ryvn.ai/docs/llms.txt
Use this file to discover all available pages before exploring further.
Ryvn deploys your applications to Kubernetes clusters running in your cloud account. You don’t need to be a Kubernetes expert to use Ryvn, but understanding a few core concepts will help you configure deployments, troubleshoot issues, and make sense of what’s happening under the hood.
How Ryvn maps to Kubernetes
When you deploy a server service to an environment, Ryvn creates the Kubernetes resources needed to run and expose your application:
| Ryvn | Kubernetes | What it does |
|---|
| Environment | Cluster | An isolated Kubernetes cluster in your cloud account |
| Service | — | A deployment template (no direct K8s equivalent) |
| Installation | Deployment + Service + Ingress | A running instance of a service in an environment |
| Pod | Pod | A single container instance of your application |
Pods
A pod is a single running instance of your application. When you configure the pod count in Ryvn, you’re controlling how many pods run simultaneously. Running multiple pods gives you:
- Availability — if one pod crashes, others keep serving traffic
- Throughput — traffic is distributed across pods via a load balancer
Pods are ephemeral. Kubernetes replaces them when they fail, when you deploy a new version, or when the cluster needs to rebalance. Don’t store important data inside a container’s filesystem — use environment variables, secrets, or external storage instead.
Resource requests and limits
Every pod needs CPU and memory. Kubernetes uses two settings to manage this:
- Requests — the guaranteed minimum. The scheduler uses this to decide where your pod runs.
- Limits — the maximum allowed. If a pod exceeds its memory limit, it’s killed (OOMKilled). If it exceeds CPU, it gets throttled (slower responses).
| Unit | Meaning | Example |
|---|
250m CPU | 0.25 cores | Light API server |
1000m CPU | 1 full core | CPU-intensive workload |
256Mi memory | 256 megabytes | Small service |
1Gi memory | 1 gigabyte | Larger service |
Health checks
Ryvn uses health checks to determine whether a pod is ready to receive traffic. During a deployment, new pods must pass their health check before traffic is routed to them — this is how zero-downtime deployments work.
How it works:
- Ryvn sends an HTTP GET request to your health check endpoint (e.g.,
/healthz)
- A
2xx or 3xx response means healthy
- If a pod fails health checks for 60+ seconds, it gets restarted
- If a new deployment fails health checks for 15+ minutes, the deployment is canceled and the previous version keeps running
A correct health check is critical — it’s the mechanism that prevents bad deployments from going live. Configure a health check endpoint in your application that returns a success status when the app is ready to handle requests. See Health Checks for setup details.
Deployments and rolling updates
When you deploy a new version, Ryvn uses rolling updates:
- New pods are created with the updated version
- Each new pod must pass its health check
- Once healthy, traffic shifts to the new pods
- Old pods are terminated
This means your application is never fully down during a deployment. If the new version fails health checks, the old version keeps running.
Autoscaling
Ryvn monitors CPU and memory utilization across your pods and automatically adjusts the pod count:
- When average utilization exceeds the target, pods are added (up to your max)
- When utilization drops, pods are removed (down to your min)
For example, with a target CPU of 70%, 2 min pods, and 10 max pods — if your 2 pods are averaging 90% CPU, Ryvn adds pods until utilization drops below 70%. See Scaling for configuration.
Networking
Ryvn configures three access modes that control how traffic reaches your application:
| Mode | Who can reach it |
|---|
| Public | Anyone on the internet |
| Internal | Services within your VPC |
| Private | Services within the cluster only |
Common troubleshooting
| Symptom | Likely cause | What to do |
|---|
| Pod stuck in Pending | Not enough CPU/memory on cluster nodes | Reduce resource requests or scale up the cluster |
| Pod in CrashLoopBackOff | Application crashes on startup | Check logs for errors — likely a missing env var or failed dependency |
| Deployment stuck/canceled | Health check failing | Verify your health endpoint works and returns 2xx within 5 seconds |
| OOMKilled | Pod exceeded memory limit | Increase the memory limit or fix a memory leak |
| No traffic reaching service | Ingress or DNS misconfiguration | Check custom domain setup and networking mode |
