Pantaria Admin

Usuarios totales

—

Premium

—

Free

—

Meditaciones generadas

—

Últimos 7 días

—

Últimos 30 días

—

Coste de hoy

—

DeepSeek + Fish TTS

Coste total estimado

—

DeepSeek + Fish TTS

Coste últimos 7 días

—

DeepSeek + Fish TTS

Coste últimos 30 días

—

DeepSeek + Fish TTS

Precios de las APIs

Cargando…

Umbral de alerta diaria

Cargando…

Top 10 generadores este mes

Patrón de abuso sostenido (48h)

Usuarios que generaron ≥4 de las 5 posibles en una hora, durante 6 o más horas distintas en las últimas 48h.

Fecha	Usuario	Query	Título	Min	Voz	Idioma	Coste

Email	Nombre	Plan	Expira	Generaciones	Meditaciones	Minutos	Coste	Registro

Tasa de error TTS/LLM (24h)

—

Webhooks RevenueCat

—

Último pago/renovación procesado

—

Suscriptores activos por plan

Altas (7d / 30d)

—

Bajas (7d / 30d)

—

Conversión free → premium

—

de los que agotaron sus 5 gratis

Churn premium (30d)

—

Modo Testing

INACTIVO

Los nuevos usuarios se crean con cuenta gratuita.

Límite mensual de emergencia (Premium)

DESACTIVADO

Premium es ilimitado. Actívalo solo si detectas abuso sostenido.

Modelo de TTS (Fish Audio)

—

Cargando…

Cargando procesos…

🗺️ Los dos entornos

Testing y producción son dos despliegues completamente separados — código, base de datos y proceso propios. Nada se comparte entre ellos salvo que tú lo muevas a mano.

	TESTING	PRODUCCIÓN
Carpeta	`/opt/meditation-testing`	`/opt/meditation`
Rama git	`testing`	`production`
Dominio API	`api-testing.getpantaria.com`	`api.getpantaria.com`
Proceso PM2	`api-pantaria-testing`	`api-pantaria-prod`
Puerto local	`3002`	`3000`
Base de datos	`meditation_testing`	`meditation`
NODE_ENV	`development`	`production`

⚠️

Bases de datos totalmente separadas. Un usuario, meditación o migración que creas en testing NO existe en producción, y viceversa. Es intencional — así las pruebas nunca tocan datos reales. Pero significa que una migración nueva hay que aplicarla a mano en las DOS bases de datos (ver abajo).

①→⑥ Flujo normal: cambiar algo y llevarlo a producción

Trabaja en testing. Todos los cambios de código se hacen primero en /opt/meditation-testing (rama testing), nunca directamente en producción.
Si el cambio añade o modifica tablas, crea un archivo nuevo en db/migrations/ (numeración correlativa, ej. 028_algo.sql) y aplícalo a la base de testing:
# desde /opt/meditation-testing sudo -u postgres psql -d meditation_testing -f db/migrations/028_algo.sql
Reinicia el proceso de testing para cargar el código nuevo (y --update-env si tocaste el .env):
pm2 restart api-pantaria-testing # solo código pm2 restart api-pantaria-testing --update-env # si cambió el .env
Prueba de verdad contra https://api-testing.getpantaria.com (o http://localhost:3002 en local) antes de dar nada por bueno. Revisa pm2 logs api-pantaria-testing --err por si algo falla en silencio.
Cuando esté validado, commitea y sube la rama testing, luego mergéala a production:
# dentro de /opt/meditation-testing git add -A git commit -m "lo que sea que hiciste" git push origin testing # dentro de /opt/meditation (producción) git checkout production git merge testing git push origin production
Despliega en producción: aplica la MISMA migración (si la hubo) a la base de producción — nunca a la de testing dos veces — actualiza el código, y reinicia:
# desde /opt/meditation git pull origin production sudo -u postgres psql -d meditation -f db/migrations/028_algo.sql # solo si hubo migración nueva node --check server.js # sanity check de sintaxis antes de reiniciar pm2 restart api-pantaria-prod # añade --update-env si cambió el .env curl -s -o /dev/null -w "%{http_code}\n" https://api.getpantaria.com/v1/health # debe dar 200

🚫 Errores típicos que ya nos han pasado

①

pm2 restart NO recarga el .env. PM2 reutiliza el entorno con el que arrancó el proceso la primera vez. Si cambiaste cualquier variable en .env (una API key, un secreto de Apple, la DATABASE_URL...) y solo haces pm2 restart nombre, el proceso sigue usando los valores viejos aunque el archivo esté actualizado — sin ningún error visible. Hay que usar siempre pm2 restart nombre --update-env tras tocar el .env.

②

Las migraciones no son automáticas. No hay ningún proceso que aplique db/migrations/*.sql solo. Si añades una tabla o columna nueva y no corres el .sql a mano en la base de datos correspondiente, el código desplegado fallará con errores de "columna/tabla no existe" en cuanto intente usarla — y como testing y producción son bases separadas, hay que acordarse de aplicarla en las dos, cada una en su momento (testing al probar, producción al desplegar).

③

ALTER TABLE falla con "must be owner of table" si usas la conexión normal de la app. El usuario de la app (meditation_user, el de DATABASE_URL) tiene permisos de lectura/escritura pero no de modificar el esquema — las tablas son propiedad de postgres. Por eso las migraciones se aplican con sudo -u postgres psql -d <nombre_db> -f archivo.sql, nunca contra la DATABASE_URL de .env.

④

Los ficheros de estado en caliente no viven en git. testing-mode.json, fish-tts-config.json, emergency-limits.json, dashboard/pricing.json... se editan desde este mismo dashboard y están en .gitignore a propósito (cambian solos, no son código). Esto significa que cada entorno tiene su propio valor independiente — si activas algo en testing (p.ej. el modo Testing con premium automático) no se refleja en producción, y viceversa. Revísalos por separado en la pestaña "Servidor" de cada entorno.

⑤

Nunca escribas datos de prueba directamente en la base de datos de producción. Para probar cascadas de borrado, límites, etc., usa siempre los endpoints reales de la API (registro, login, generar meditación...) contra testing — nunca un INSERT a mano en la base de meditation real.

🔑

Secretos: viven solo en cada .env (nunca en git, nunca en el código). Si rotas una API key o un secreto en producción, acuérdate de actualizar también el .env de testing si testing lo necesita para probar esa misma funcionalidad — no se sincronizan solos.

✅ Checklist rápida antes de tocar producción

¿Lo probaste primero en api-testing.getpantaria.com, no solo en local?
¿Hay alguna migración nueva? → aplícala a meditation (producción) antes de reiniciar el proceso, no después.
¿Tocaste el .env de producción? → usa --update-env al reiniciar.
¿Pasó node --check archivo.js sin errores en todos los archivos que tocaste?
Tras reiniciar: curl .../v1/health da 200 y pm2 logs api-pantaria-prod --err --lines 20 no muestra nada nuevo.
¿Mergeaste testing → production y le hiciste push, para que el historial de git refleje lo que hay realmente corriendo?

Generar lote

LISTO

Ejecuta el pipeline completo (tema, voz, fondo, guion, TTS, ensamblado) para N videos.

Ajustes del pipeline

Timing, audio, marca del outro, hook templates (A/B), búsquedas de Pexels y temáticas. Se aplican al siguiente video generado.

Avisar del lanzamiento

—

Cargando…

Email	Apuntado	Avisado

Resumen

Precios de las APIs

Umbral de alerta diaria

Meditaciones

Usuarios

Salud del sistema

Negocio y retención

Servidor

Modo Testing

Límite mensual de emergencia (Premium)

Modelo de TTS (Fish Audio)

Docs

🗺️ Los dos entornos

①→⑥ Flujo normal: cambiar algo y llevarlo a producción

🚫 Errores típicos que ya nos han pasado

✅ Checklist rápida antes de tocar producción

TikTok

Generar lote

Ajustes del pipeline

Waitlist

Avisar del lanzamiento