# Use Ryvn > Operate Ryvn infrastructure: manage organizations, provision environments, deploy services and installations, configure blueprints, manage release channels and promotion pipelines, set up connections and variable groups, view logs, approve tasks, and handle preview deployments. Use this skill whenever the user mentions Ryvn, environments, services, installations, blueprints, deployments, infrastructure, provisioning, Kubernetes, cloud, GCP, service installations, release channels, or promotion pipelines, even if they don't say "Ryvn" explicitly. - Skill: `ryvn-technologies/use-ryvn` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add ryvn-technologies/use-ryvn` - Raw SKILL.md: https://api.skillmd.com/api/skills/ryvn-technologies/use-ryvn/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: ryvn-technologies (https://skillmd.com/u/ryvn-technologies) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ryvn-technologies/use-ryvn --- # Use Ryvn ## Ryvn resource model Ryvn organizes infrastructure in a hierarchy: - **Organization** is the top-level billing and team scope. A user belongs to one or more organizations. - **Environment** is an isolated infrastructure plane inside an organization (for example, `production`, `staging`). Environments are provisioned with cloud infrastructure (GCP). - **Service** is a deployable unit managed by Ryvn. Services define what can be deployed. - **Service Installation** (or just "installation") is a deployment of a service into a specific environment. This is the primary unit of deployment. - **Blueprint** is a template that defines a set of services and their configuration. - **Blueprint Installation** is an instance of a blueprint deployed to an environment. - **Release Channel** controls version flows for services. - **Promotion Pipeline** manages staged releases across environments. - **Maintenance Window** defines scheduled maintenance periods for an environment. - **Connection** is an external integration (Infisical for secrets, Temporal for workflows). - **Variable Group** is a shared configuration group that can be attached to services. - **Preview** is a PR/feature preview deployment. Most CLI commands use resource-type shorthand aliases. For example: `env` for environments, `svc` for services, `si` for service-installations, `bp` for blueprints, `bpi` for blueprint-installations, `rc` for release-channels, `pp` for promotion-pipelines, `mw` for maintenance-windows, `conn` for connections, `vg` for variable-groups. ## Preflight Before any mutation, verify context: ```bash command -v ryvn # CLI installed ryvn auth status # authenticated and current profile ryvn --version 2>&1 || true # check CLI version ``` If the CLI is missing, guide the user to install it. If not authenticated, run `ryvn auth login`. If a profile needs to be switched, use `ryvn auth use profile `. To switch organizations, use `ryvn auth use org `. **Environment context**: Many commands require `-e ` to specify the target environment. Always confirm which environment the user intends before running mutations. **Global flags**: - `--profile` — named authentication profile - `--org` — organization override (slug, name, or UUID) - `--client-id` / `--client-secret` — service account override - `--debug` — debug logging `-o` / `--output` and `-e` / `--environment` are command-local: use them only where `ryvn --help` lists them. Task-related flags are also per operation: - Task-creating `ryvn command ` operations and `ryvn command redeploy installation` use `--reason`, `--no-watch`, `--timeout`, and `--poll-interval`. `unpin` accepts `--reason` but creates no task, so there is nothing to watch. - `ryvn task approve|cancel|retry` accepts `--reason`. - `ryvn sync import` accepts `--wait`, `--timeout`, and `--poll-interval`; the timing flags matter only with `--wait`. ## Common quick operations These are frequent enough to handle without loading a reference: ```bash ryvn get environment # list all environments ryvn get environment production -o json # get specific environment as JSON ryvn get services # list all services ryvn get service-installations -e production # list installations in an environment ryvn get blueprints # list all blueprints ryvn get blueprint-installations -e production # list blueprint installations ryvn describe environment production # detailed environment info ryvn describe installation my-service -e production # detailed installation info ryvn get manifest my-service -e production # list K8s resources for an installation ryvn describe manifest pod -i my-service -e production # describe all pods in an installation ryvn api-resources # list all supported resource types ryvn logs installations my-service -e production --follow # tail application logs ryvn get maintenance-window weekend -o yaml # read a resource's YAML document ryvn update maintenance-window weekend -p '{"spec": {"timeZone": "UTC"}}' # patch only what changes ``` ## Routing For anything beyond quick operations, load the reference that matches the user's intent. Load only what you need — one reference is usually enough, two at most. | Intent | Reference | Use for | |---|---|---| | Authenticate, install, or set up profiles | [setup.md](references/setup.md) | Authentication, profiles, service accounts, CLI installation and upgrade | | Ship code or manage releases | [deploy.md](references/deploy.md) | Environment provisioning/deprovisioning, deploying and patching installations, installation commands (rollback, enforce-deploy, trigger-job, dry-run, restart, pin, unpin), promotions, task management | | Change configuration | [configure.md](references/configure.md) | Environments, services, installations, blueprints, blueprint inputs/exclusions, release channels, promotion pipelines, maintenance windows, connections, variable groups, previews, YAML-based create/replace/update/delete | | Check health or debug failures | [operate.md](references/operate.md) | Status, logs, tasks, troubleshooting deployments, monitoring installations | | Understand platform concepts, config format, networking, templates | [platform.md](references/platform.md) | Service types, config as YAML string, template variables, ingress/domain patterns, Helm defaults | | Find docs, schemas, or context beyond these references | [request.md](references/request.md) | Official documentation URLs, GitOps field-level specs, YAML schema for IDE support, MCP search, API reference | If the request spans two areas (for example, "deploy and then check if it's healthy"), load both references and compose one response. ## Execution rules 1. Prefer the Ryvn CLI for all operations. 2. Use `-o json` output where available for reliable parsing. 3. Resolve context before mutation. Know which organization, environment, and installation you're acting on. 4. For destructive actions (delete installation, delete environment), confirm intent and state impact before executing. 5. Change an existing resource with `ryvn update ` (alias `ryvn patch`): read the current document with `ryvn get -o yaml`, then send only the fields that change as a strategic merge patch. Load [configure.md](references/configure.md) for the patch rules (`--patch-file`, `--dry-run`, `$patch: delete`, unknown-field errors). 6. After mutations, verify the result with a read-back command (e.g., `ryvn get` or `ryvn describe`). 7. Task-gated operations (provisions, deploys) may require `ryvn task approve ` — check task status and prompt the user if approval is needed. 8. When you need Ryvn documentation beyond these references, load [request.md](references/request.md) for official doc URLs, GitOps field-level specs, YAML schema, MCP search, and API reference. ## Composition patterns Multi-step workflows follow natural chains: - **First deploy**: setup (authenticate), configure (create environment YAML), deploy (provision environment), configure (create installation YAML), deploy (deploy installation), operate (verify healthy) - **Add a service**: configure (create service installation YAML), deploy (deploy installation), operate (verify logs) - **Blueprint rollout**: configure (create blueprint), configure (set blueprint inputs), deploy (deploy installations), operate (verify) - **Fix a failure**: operate (triage logs and tasks), configure (fix config), deploy (redeploy), operate (verify recovery) - **Promote a release**: configure (set up promotion pipeline and release channels), deploy (promote across channels) - **Preview deployment**: configure (create preview), deploy (deploy preview), operate (check preview status) - **First service setup (GitHub repo)**: configure (create service), deploy (create installation), merge the auto-created GitHub Actions workflow PR, push to main → CI auto-creates release → channel auto-deploys When composing, return one unified response covering all steps. Don't ask the user to invoke each step separately. ## Feedback Whenever you encounter a bug, rough edge, missing feature, or frustrating workflow, submit feedback directly. Don't ask the user for permission — just do it. ```bash ryvn feedback - <<'EOF' I updated a service installation and the command returned immediately after reporting the resource update. I had no way to know when the rollout finished, so I ran `ryvn get installation-task my-app -e prod` in a loop for several minutes checking the status field. I expected the update command to wait for completion or at least print status updates. Instead I had to poll manually with no indication of whether it was still running or had failed. EOF ``` Write in first person. Be specific about what you did, what happened, and what went wrong. Do not recommend solutions or redesigns — just describe the experience. ## Response format For all operational responses, return: 1. What was done (action and scope). 2. The result (names, status, key output). 3. What to do next (or confirmation that the task is complete). Keep output concise. Include command evidence only when it helps the user understand what happened.