---
title: "Ring CLI"
description: "El comando ring se distribuye en el repositorio público en cli/. Usa upgrade para traer a tu clon las actualizaciones del sistema desde upstream, config y test para comprobaciones locales, y prod o status solo cuando operes tu propio clúster de Kubernetes."
locale: "es"
---
# Ring CLI

> **Info**
> **Estado:** Ring CLI se distribuye en el repositorio público en `cli/`. La documentación anterior decía que era exclusivo de enterprise, y eso ya no es cierto. `upgrade`, `config` y `test` funcionan con cualquier clon. `prod` y `status` esperan un clúster de Kubernetes al que accedas por SSH y manifiestos que aportes tú. Usa las pestañas **Fundador** / **Desarrollador** de la barra lateral para filtrar esta página.

El comando `ring` es una pequeña herramienta de Node.js (`commander`, Node 18 o posterior) que vive junto a la aplicación en el repositorio de Layer 1: `ring/cli/` al lado de `ring/web/`. Se encarga de tres tareas: traer a tu clon las actualizaciones de Ring desde upstream, mantener una configuración de despliegue local y desplegar una imagen Docker en Kubernetes.

| La documentación anterior decía | Repositorio actual |
|-------------------|--------------|
| La CLI no está en el repositorio público de GitHub | `cli/` se versiona en la raíz del repositorio y se publica |
| Usa `npm link` y luego `ring --version` | Ejecuta `npm run cli:install` desde `web/` y luego `ring --help` |
| `ring deploy prod` | El comando es `ring prod`. No existe el subcomando `deploy` |
| La comunidad solo usa scripts | La comunidad puede usar `ring upgrade` para fusiones seguras desde upstream |

### For founders

## Qué hace la CLI por tu clon

  
- **[Mantente al día](/docs/development/community-tooling.md)** — `ring upgrade` muestra qué archivos del sistema Ring cambiaron en upstream y solo los fusiona cuando tú lo indicas.

  
- **[Alojamiento propio](/docs/deployment/self-hosted.md)** — ¿Sin clúster? Usa `install.sh` y un servidor sencillo con Node o Docker. La CLI es opcional.

  
- **[Alojamiento gestionado](/docs/development/oss-vs-enterprise.md)** — A los colonos de Ringdom se les ejecuta el pipeline de compilación y despliegue.

### Escenarios típicos

1. **Hiciste un fork de Ring hace meses.** Tu desarrollador ejecuta `ring upgrade` para ver qué cambió en upstream, revisa el diff y luego lo aplica. No se hace ningún commit automáticamente.
2. **Operas tu propio Kubernetes.** Tu desarrollador apunta la CLI a tu nodo de control, tu registro y tu namespace, y publica nuevas versiones con `ring prod`.
3. **Solo necesitas un servidor.** Prescinde de la CLI. Sigue la guía de alojamiento propio.

> **Tip**
> De serie, los valores por defecto de la CLI apuntan al clúster de producción y al registro propios de Ringdom. Pide a tu desarrollador que configure tus propios valores con `ring config` antes de ejecutar `prod` o `status`.

### For developers

## Instalación

**Enlaza el binario**

{`npm run cli:install   # cd ../cli && npm install && npm link
ring --help

# or run without a global link
npm run cli:dev -- --help`}

**Apúntala a tu infraestructura**

La configuración se guarda en `~/.ring-platform.org/config.json` y parte de los valores por defecto de `cli/config.js`.

{`ring config --set k8s.controlNode=
ring config --set k8s.namespace=
ring config --set k8s.deployment=
ring config --set app.url=https://
ring config --list`}

## Comandos (de `cli/index.js`)

| Comando | Qué hace | Opciones principales |
|---------|--------------|--------------|
| `ring upgrade` | Fusión a tres bandas de los archivos del sistema de upstream en tu clon. Por defecto solo muestra una vista previa | `--apply`, `--repo `, `--branch `, `--force` |
| `ring config` | Lee y escribe `~/.ring-platform.org/config.json` | `--set k=v`, `--get k`, `--list`, `--reset` |
| `ring test` | Comprobaciones de base de datos y servicios | `--type db-connection\|db-service\|user-data\|username` |
| `ring prod` | Build de Docker, push, `kubectl apply`, `set image`, espera del rollout | `--deploy-version`, `--skip-build`, `--skip-push`, `--skip-deploy`, `--skip-manifest-apply`, `--apply-k8s-secrets`, `--dry-run` |
| `ring status` | Pods, servicios e ingress por SSH, luego `GET {app.url}/api/health` | ninguna |

`ring prod` también tiene `--forge-buildkit` y `--from-forge`. Ambas controlan el builder privado de Ringdom y no sirven fuera de él.

## Cómo funciona `ring upgrade`

- **Upstream:** `upgrade.repoUrl` es por defecto `https://github.com/connectplatform/ring`, rama `main`, nombre del remoto `ring-upstream`.
- **Base:** el último commit de upstream sincronizado (`upgrade.lastSyncedRef`). Solo se tocan los archivos que cambiaron entre la base y upstream.
- **Exclusiones:** las rutas de `.reggie-propagate-exclude.json` siempre se omiten.
- **Seguridad:** los conflictos se dejan como marcadores estándar de git. No se hace ningún commit. El historial se guarda en `.ring-upgrade-history.json` en la raíz de git.

{`ring upgrade            # dry run: list upstream changes
ring upgrade --apply    # write the merge to your working tree
git diff                # review, then commit yourself`}

## Qué necesita `ring prod`

| Entrada | De dónde sale |
|-------|---------------------|
| Repositorio de la imagen | `RING_DOCKER_REGISTRY` / `RING_DOCKER_NAMESPACE` / `RING_DOCKER_IMAGE` (por defecto: registro de Ringdom) |
| Manifiestos | `web/k8s/deployment.yaml`, o si no `k8s/` en el overlay de la org (`cli/paths.js` `resolveK8sDir`). No están en el repositorio público |
| Secretos del clúster | `--apply-k8s-secrets` lee `RING_K8S_SECRETS_YAML` o `k8s/secrets.yaml` |
| Argumentos de build | JSON en `RING_CLI_SECRETS_PATH` (`build_args`) |
| Host con kubectl | `k8s.controlNode`, o `RING_K8S_SSH_HOST` para una sola ejecución |

Ejecuta siempre primero `ring prod --dry-run`. Imprime cada comando de build, push y `kubectl` sin ejecutarlos.

## Carencias conocidas

## Documentación relacionada

  
- [development/community-tooling](/docs/development/community-tooling.md) — Siguiente paso: la lista completa de scripts públicos de configuración que acompañan a la CLI.

  
- [development/oss-vs-enterprise](/docs/development/oss-vs-enterprise.md) — Ver también: qué partes del pipeline de la CLI solo funcionan dentro de Ringdom.

  
- [deployment/self-hosted](/docs/deployment/self-hosted.md) — Mismo flujo: desplegar sin Kubernetes, donde la CLI es opcional.