---
title: "k6 Cloud vs k6 self-hosted: costo, privacidad y trade-offs de flujo de equipo"
description: "k6 Cloud vs OSS self-hosted: cumplimiento, escalado de generadores y mantenimiento—docs Grafana más iteración en escritorio con Performate."
publishDate: "2026-08-03"
draft: false
keyword: "k6 cloud vs self hosted"
intent: "TOFU"
cta: "Explora cómo Performate simplifica las pruebas de carga con k6, desde imports hasta resultados, para que tu equipo publique con más confianza en rendimiento."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "cloud", "self", "hosted"]
translationOf: k6-cloud-vs-self-hosted
---

Tu equipo superó corridas k6 en laptop—pero procurement pregunta si comprar **Grafana k6 Cloud** o provisionar generadores **OSS self-hosted** en Kubernetes. Ambos corren el mismo formato de script; difieren en quién posee uptime, residencia de datos y flujo desde «editar escenario» hasta «compartir reporte con producto».

k6 Cloud vs self-hosted no es debate de pureza. Es una **matriz de trade-offs**: costo SaaS recurrente vs labor ops, colaboración hospedada vs artefactos solo git, y si generadores deben vivir dentro de boundary VPC. En esta guía verás dónde gana cada opción, cómo correr el mismo script en ambos modelos, y qué fila de tabla encaja con tu equipo—no «cloud siempre es más fácil».

## Por qué la elección afecta flujo—no solo billing

Equipos suelen comparar pricing line-item e ignorar fricción de ejecución:

- **Escalado de generadores:** Cloud levanta carga distribuida global; self-hosted implica dimensionar jobs K8s o pools VM ([pruebas distribuidas geo](/es/blog/pruebas-de-carga-distribuidas-geo)).
- **Residencia de datos:** PCI, HIPAA o contratos cliente pueden prohibir enviar URLs, tokens o payloads a SaaS—aunque «solo métricas» salgan del VPC.
- **Colaboración:** dashboards Cloud comparten corridas por link; OSS depende de JSON exportado, Grafana o reportes escritorio.
- **Mantenimiento:** self-hosted parchea versiones k6, Chromium para browser tests, y reglas firewall outbound vos mismo.
- **Integración CI:** ambos soportan corridas pipeline; Cloud suma orquestación hospedada, OSS usa tus runners ([pruebas de carga en CI/CD](/es/blog/pruebas-de-carga-en-ci-cd)).

Piensa Cloud como contratar control plane de load test; self-hosted como poseer la flota pero mantener cada byte en tu red.

**k6 OSS** corre donde provisiones CPUs ([getting started](https://k6.io/docs/get-started/running-k6/)). **Grafana k6 Cloud** suma orquestación y dashboards hospedados ([Cloud docs](https://k6.io/docs/cloud/)).

## Implementación práctica en k6: script portable, dos targets de corrida

Escribe scripts con **env vars para secretos y base URLs** para que el mismo archivo corra local, en CI, contra Cloud o en agents self-hosted—sin fork por plataforma.

**Script de ejemplo (ilustrativo—no listo para producción).** Idéntico para upload Cloud o `k6 run` en tu cluster.

**Qué demuestra este ejemplo:**

- **Target vía env:** `API_BASE` cambia staging vs túnel Cloud sin editar script.
- **Tasa moderada friendly a distribución:** `constant-arrival-rate` divide limpio entre zonas Cloud o réplicas K8s.
- **Tags para comparación de plataforma:** `run_target:cloud|selfhosted` vía `--tag` al invocar.
- **Umbrales portables:** mismos gates SLO ya sea resultados en UI Cloud o InfluxDB.

```javascript
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const TARGET = __ENV.RUN_TARGET || 'local';

export const options = {
  scenarios: {
    portable_load: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.RPS || 50),
      timeUnit: '1s',
      duration: '10m',
      preAllocatedVUs: 20,
      maxVUs: 200,
      tags: { run_target: TARGET, suite: 'cloud-vs-oss' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{run_target:' + TARGET + '}': ['p(95)<700'],
  },
};

export default function () {
  const res = http.get(`${BASE}/v1/catalog`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
    tags: { route: 'catalog', run_target: TARGET },
  });
  check(res, { 'catalog 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.2);
}
```

**Patrones que funcionan**

- **Piloto ambos:** mismo script, una corrida trial Cloud, un Job K8s—compara tiempo ops y UX reporte.
- **Stack métricas self-hosted:** canaliza output OSS a InfluxDB + Grafana ([stack InfluxDB k6](/es/blog/stack-metricas-k6-influxdb-grafana)).
- **Iteración escritorio:** tuning en Performate; exporta script a git para cualquier target ([flujos escritorio](/es/blog/flujos-pruebas-de-carga-escritorio)).
- **Secretos nunca en settings Cloud** si política prohíbe—inyecta en runtime vía CI.

**Anti-patrones a evitar**

- Mantener dos repos script porque «sintaxis Cloud difiere»—no debería.
- Elegir Cloud para carga global sin chequear allowlists egress en tu API.
- Self-hosting sin capacity planning—generadores sub-dimensionados distorsionan resultados.

**Pro tip (comandos de ejemplo):**

```bash
# Self-hosted
k6 run portable-load.js -e RUN_TARGET=selfhosted -e API_BASE=https://staging.internal.example.com

# Cloud (tras login/upload según docs Grafana)
k6 cloud portable-load.js -e RUN_TARGET=cloud
```

**Qué demuestran estos comandos:** script y umbrales idénticos; solo cambian plano de ejecución e inyección env.

## Marco de decisión: Cloud vs self-hosted vs híbrido

| Situación | Acción recomendada |
|:---|:---|
| Equipo chico, sin capacidad ops | Trial k6 Cloud; minimizar ops de generadores |
| Residencia estricta / staging air-gapped | OSS self-hosted en VPC; reportes locales |
| Testing latencia global desde muchas regiones | Carga distribuida Cloud o self-hosted multi-región |
| Solo smoke CI pesado | OSS en runners existentes—Cloud opcional |
| Dashboards compartibles para PM/QA | Cloud u OSS + Grafana + exports Performate |

**Usa k6 Cloud si** headcount ops escasea y compliance permite metadata de escenario off-prem.

**Usa OSS self-hosted si** generadores, payloads o URLs deben quedarse dentro de boundary de red.

**Usa híbrido si** ingeniería itera local/escritorio, CI corre smoke OSS, picos trimestrales usan burst Cloud—mismo script git para todo.

## Observabilidad, documentación y próximos pasos

Elecciones de plataforma fallan cuando runbooks asumen target incorrecto. Antes de estandarizar:

- [ ] Documenta targets aprobados (Cloud, K8s, laptop) y prohibidos (prod sin aprobación).
- [ ] Registra modelo de costo: suscripción Cloud vs horas ingeniero mantenimiento self-hosted.
- [ ] Taggea corridas con `run_target` y archiva summaries para pilotos comparativos.
- [ ] Automatiza smoke OSS en CI; agenda corridas distribuidas Cloud para release candidates.
- [ ] Alinea patrón inyección secretos en Cloud y self-hosted—mismos nombres env var.

## Cómo Performate simplifica flujos Cloud vs self-hosted

Dividir iteración entre CLI, UI Cloud y hojas frena adopción. Abajo un **ejemplo de flujo concreto** para load testing portable.

**Ejemplo: un workspace escritorio, dos planos de ejecución**

1. **Importa colección Postman** y ajusta tasas de escenario en Performate. *Problema resuelto:* editar forma de carga una vez—no separado para Cloud y OSS.
2. **Corre local contra staging** para iteración rápida. *Problema resuelto:* no quemar minutos Cloud debuggeando script.
3. **Exporta script k6 a git** con placeholders env para `API_BASE` y `TOKEN`. *Problema resuelto:* CI self-hosted y upload Cloud comparten fuente canónica.
4. **Agrega tags `run_target` en notas de escenario** para consistencia de reporte. *Problema resuelto:* comparar pilotos sin reescribir scripts.
5. **Comparte reporte integrado PDF/JSON** con PM para sign-off antes de escalar test distribuido Cloud. *Problema resuelto:* colaboración sin seats Cloud obligatorios para cada viewer.
6. **Dispara corrida Cloud o K8s** desde script exportado cuando abre ventana staging. *Problema resuelto:* plano de ejecución es elección ops, no evento de rewrite.

Ese flujo mapea al `cta`: simplificar k6 de imports a resultados sin importar target Cloud u OSS.

## Cierre

Cloud vs self-hosted k6 es decisión de **flujo y compliance**—no checklist de features. Mantén scripts portables, pilotea ambos con mismos umbrales, y documenta quién posee generadores, secretos y dashboards antes del próximo ensayo de tráfico pico.

Corre el piloto de este mes con `RPS` idéntico en Cloud y un Job K8s—anota tiempo ops y shareability de reporte, no solo la factura.

[Try Performate free](https://performate.app) | [Reserva una demo](/demo) | [Docs k6 Cloud](https://k6.io/docs/cloud/)