Pelican vs Pterodactyl en 2026: funciones, rendimiento y requisitos de VPS
Pelican y Pterodactyl resuelven el mismo problema básico: gestionar servidores de juegos desde un navegador mientras un servicio independiente controla los contenedores del host. Elegir uno u otro afecta a la administración, las integraciones y las actualizaciones. No cambia automáticamente la velocidad de los ticks de un mundo Minecraft ni el número de jugadores que admite un servidor Rust.
Elige la rama estable 1.x de Pterodactyl si la prioridad es conservar un despliegue consolidado. Evalúa Pelican si te interesan su flujo administrativo, sus plugins y sus opciones de autenticación. Para la infraestructura de cualquiera de los dos paneles, nuestra recomendación general es LightNode cuando la ubicación regional y la facturación flexible encajan con tu comunidad.
Después de elegir el panel, consulta nuestra guía de los mejores proveedores de alojamiento para Pelican Panel y nuestra guía de los mejores proveedores para Pterodactyl Panel para profundizar en la compra.
Revisado el 16 de octubre de 2026. Este artículo combina documentación oficial, notas de versiones, análisis del despliegue y un plan de evaluación reproducible. No realizamos benchmarks en VPS de pago para este artículo; no hay tiempos de respuesta, mediciones de memoria ni puntuaciones de proveedores inventados.
Primero, compara las versiones correctas
«Pelican vs Pterodactyl» ya no es simplemente una interfaz nueva frente a un panel antiguo que permanece sin cambios.
| Proyecto o rama | Información disponible al revisar | Cómo interpretarla |
|---|---|---|
| Pelican Panel | La página de versiones indica v1.0.0-rc.1 como la más reciente | Ten en cuenta la etiqueta RC en las pruebas de aceptación; no la presentes como una versión final 1.0 consolidada |
| Pterodactyl 1.x | v1.15.1 figura como la última versión estable | Referencia para un despliegue de producción establecido |
| Pterodactyl 2.0 | v2.0.0-beta.2 figura como versión preliminar | Evalúala por separado en pruebas; el proyecto recomienda mantener producción en 1.x por ahora |
Fuentes: versiones de Pelican y versiones de Pterodactyl. Es una instantánea fechada, no una instrucción para instalar indefinidamente esas compilaciones exactas.
Pterodactyl 2.0 incorpora extensiones, temas, una aplicación unificada para administradores y usuarios, y un catálogo de eggs. Por eso, afirmar que «Pterodactyl no tiene sistema de extensiones» es incorrecto como descripción de todo el proyecto. Distingue la rama estable de la beta al comparar funciones.
Arquitectura: Panel, Wings, Docker y eggs
Piensa en dos recorridos:
Administration:
Browser -> HTTPS reverse proxy -> Panel -> Wings API
Gameplay:
Player -> game allocation on a node -> Docker container -> game processEl Panel atiende la interfaz web y las solicitudes de administración. Wings se ejecuta en cada nodo de juegos y controla los contenedores. Un egg describe la instalación y el arranque, incluidas la imagen y las variables. Pelican nació como un fork de Pterodactyl y conserva esta división general de responsabilidades. Consulta la introducción a la arquitectura de Pelican y la documentación de Pterodactyl.
Un solo VPS puede alojar ambos componentes. En instalaciones mayores, el Panel puede tener su propia máquina y Wings otros nodos. En las asignaciones habituales con conexión directa al juego, el tráfico de los jugadores no atraviesa el servidor web del Panel. Acercar el Panel al administrador no acerca un nodo remoto a los jugadores.
Consecuencia práctica: compara por separado la respuesta del dashboard y el rendimiento del juego. Una página de acceso lenta, una consola que tarda en conectar y un pico de duración del tick pueden tener causas distintas.
Funciones: dónde importan las diferencias
| Aspecto | Pelican | Pterodactyl estable 1.x | Implicación al comprar o administrar |
|---|---|---|---|
| Gestión básica | Arquitectura Panel/Wings; cargas Docker | Arquitectura Panel/Wings; cargas Docker | Ambos necesitan nodos adecuados, asignaciones y definiciones de juegos mantenidas |
| Administración | Interfaz Filament; roles y permisos de administradores | Flujo administrativo consolidado | Prueba tareas reales del equipo, no solo capturas |
| Extensibilidad | Plugins y temas de primera parte en su ecosistema | Modificaciones e integraciones de terceros requieren comprobar versiones | Inventaría todas las integraciones antes de migrar |
| Autenticación | Documenta passkeys, OAuth y doble factor | Comprueba la versión elegida y las integraciones añadidas | Prueba también recuperación de cuentas y proxy |
| Organización | Etiquetas en lugar del antiguo modelo nests/locations | Nests y locations en el flujo establecido | Puede exigir cambios en la automatización |
| Copias | Documenta almacenamiento local y S3 por nodo | Revisa la configuración de la versión instalada | Ninguno elimina la necesidad de probar restauraciones |
| Evolución de versiones principales | Revisar cambios de la RC y versiones posteriores | La beta 2.0 añade extensiones y otros cambios | Una función beta no pertenece automáticamente a 1.x estable |
Las descripciones de Pelican proceden de su comparativa oficial. Al estar escrita por Pelican, sirve para identificar funciones documentadas, no como prueba independiente de mayor velocidad.
Pelican: ventajas y compromisos
Pelican resulta atractivo si el equipo necesita su modelo de permisos administrativos y un mecanismo de plugins con soporte oficial. Eso puede reducir la necesidad de mantener parches sobre archivos del núcleo.
El compromiso es validar la versión elegida, los plugins y la automatización. Poder instalar un plugin no demuestra compatibilidad con la facturación, los permisos o la siguiente actualización. La documentación de plugins explica las restricciones de versión y distingue las interfaces admitidas de los componentes internos que pueden cambiar.
Nuestra valoración: buen candidato para un despliegue nuevo con tiempo de preproducción. Adóptalo porque sus flujos ayudan al equipo, después de probar la versión concreta.
Pterodactyl: ventajas y compromisos
Pterodactyl 1.x es una referencia práctica si tus eggs, procedimientos del equipo e integraciones de aprovisionamiento ya funcionan. Conservar esas dependencias puede aportar más que cambiar el dashboard.
Debes decidir cuándo seguir invirtiendo en modificaciones existentes y cuándo preparar 2.0. No presupongas que una personalización 1.x funcionará en la beta ni que los pasos de actualización dentro de 1.x permiten pasar con seguridad a 2.0. La guía de actualización de 1.x separa expresamente ambos procedimientos.
Nuestra valoración: conserva una instalación sana y parcheada salvo que otro panel resuelva un problema operativo concreto. Trata las pruebas de 2.0 como un proyecto de migración independiente.
Rendimiento: ¿qué puede cambiar realmente?
La marca del panel es solo una variable. Conviene medir por separado cuatro capas:
| Capa | Mediciones útiles | Problemas habituales |
|---|---|---|
| Solicitudes HTTP del Panel | Mediana/p95 de respuesta, errores | Procesos PHP, latencia de base de datos, caché, proxy inverso |
| Operaciones administrativas | Conexión de consola, instalación y copia completadas | Conectividad Wings, colas, descarga de imágenes, almacenamiento |
| Proceso del juego | Tiempo de tick/frame, CPU, memoria y pausas visibles | Mods, scripts, tamaño del mundo, planificación de CPU |
| Host y red del VPS | CPU steal, latencia de E/S, pérdida de paquetes, rutas | Contención del host, almacenamiento saturado, malas rutas |
Una experiencia de panel mejor puede deberse a menos pasos administrativos y no a una simulación más rápida. A la inversa, una copia ejecutada en el mismo VPS puede competir con el juego por CPU y disco, independientemente de la interfaz que la inicia.
También importan los límites Docker. Una cuota de CPU limita el consumo, no reserva capacidad física. Un contenedor con límite de memoria sigue necesitando margen para el runtime y las asignaciones nativas. Consulta restricciones de recursos de Docker.
Una prueba A/B reproducible
Usa un nodo libre o preproducción aislada. Mantén idénticos el binario del juego, el mundo, el runtime, el digest de imagen, los límites y la carga de jugadores. Anota las versiones de Panel y Wings de cada proyecto. Iguala los ajustes cuando sea posible y documenta las diferencias entre implementaciones de Wings.
- Restaura la misma copia del mundo antes de cada ejecución.
- Calienta el juego y sus cachés durante un periodo fijo.
- Ejecuta una sesión representativa de al menos 30 minutos.
- Mide por separado panel inactivo, administración activa y copia programada.
- Repite al menos tres veces por configuración, alternando el orden.
- Compara distribuciones y valores atípicos, no una media conveniente.
Las pruebas secuenciales en el mismo VPS reducen diferencias de hardware, pero el host compartido puede variar. Probar simultáneamente en dos nodos introduce diferencias entre hosts. Documenta la limitación del método elegido.
En un nodo Ubuntu de pruebas, instala herramientas y examina el entorno:
sudo apt update
sudo apt install -y sysstat
uname -m
systemd-detect-virt
lscpu
free -h
df -h
sudo docker version
sudo docker info --format 'Driver={{.Driver}} Cgroup={{.CgroupVersion}}'Registra la actividad del host durante la sesión:
mkdir -p "$HOME/panel-ab-results"
mpstat -P ALL 1 60 > "$HOME/panel-ab-results/cpu.txt"
iostat -xz 1 60 > "$HOME/panel-ab-results/disk.txt"
sudo docker stats --no-streamLos dos comandos temporizados anteriores se ejecutan secuencialmente. Usa terminales separados para registrar el mismo intervalo o repítelos en cada fase. docker stats --no-stream es una instantánea; muestrea repetidamente o utiliza monitorización para obtener una serie temporal completa.
Para muestrear una página pública, sustituye el hostname y usa el mismo endpoint en ambos paneles:
PANEL_URL='https://panel.example.com/'
for sample in $(seq 1 30); do
curl --fail --silent --show-error --output /dev/null \
--connect-timeout 5 --max-time 15 \
--write-out '%{http_code},%{time_starttransfer},%{time_total}\n' \
"$PANEL_URL"
doneEsto mide una solicitud HTTP no autenticada, incluidos efectos de red y TLS. No mide un dashboard autenticado, usuarios concurrentes ni latencia del juego. Para ello, utiliza carga autenticada controlada y telemetría específica del juego.
Cómo presentar los resultados con rigor
| Métrica | Ejecución Pelican | Ejecución Pterodactyl | Interpretación |
|---|---|---|---|
| HTTP p95 del Panel | Anotar valor medido | Anotar valor medido | Misma ruta, cliente, endpoint y número de solicitudes |
| Tick/frame p95 del juego | Anotar valor medido | Anotar valor medido | Misma partida, runtime y carga |
| Memoria de la pila en reposo | Anotar valor medido | Anotar valor medido | Mismos servicios incluidos y método |
| Duración de la copia | Anotar valor medido | Anotar valor medido | Mismos datos, compresión y destino |
| CPU steal del host | Anotar valor medido | Anotar valor medido | Comprobar si la contención distorsionó el resultado |
Son campos para tus resultados, no mediciones de este artículo. Sin este control, afirmar que un panel es «un 30 % más rápido» no aporta evidencia útil para comprar.
Requisitos del VPS: dimensiona juego y Panel por separado
No existe una cifra de RAM que describa a la vez un dashboard vacío y un nodo con muchos mods. Las siguientes son recomendaciones de planificación, no mínimos oficiales ni garantías de jugadores.
| Despliegue | CPU inicial sugerida | RAM total VPS | Almacenamiento previsto | Notas |
|---|---|---|---|---|
| Solo Panel, comunidad pequeña | 2 vCPU | 2–4 GB | 25–40 GB SSD | Margen para servicios web y auxiliares; validar carga |
| Panel + un juego ligero | 2–4 vCPU rápidas | 8 GB | 80–100 GB SSD/NVMe | Incluir SO, contenedores, base de datos, actualizaciones y partidas |
| Panel + juego pesado o varias instancias pequeñas | 4–8 vCPU rápidas | 16–32 GB o más | 160–300 GB o más | Límites por juego; probar CPU y almacenamiento sostenidos |
| Panel separado y varios nodos | Dimensionar cada máquina | Presupuesto por función | Datos por nodo y copias externas | Acercar nodos a jugadores; proteger Panel–Wings |
Un host de 8 GB no debería asignar los 8 GB al juego. Por ejemplo, un límite hipotético de 5 GB para el juego y 2 GB para el SO y la pila administrativa deja 1 GB de margen. La pila real puede necesitar más, sobre todo al instalar, comprimir o actualizar.
En servidores Java, el heap es solo parte de la memoria del contenedor. Memoria nativa, pilas de hilos y otros gastos de la JVM cuentan para su límite. Configurar dos contenedores para que cada uno use toda la RAM del host no crea memoria adicional.
Los requisitos de software dependen de la versión
| Componente | Requisito que comprobar |
|---|---|
| Documentación actual de Pelican | PHP 8.4 o 8.5, recomendado 8.5; extensiones necesarias y servidor web compatible |
| Base de datos Pelican | SQLite si se cumple el requisito de su biblioteca; opciones externas documentadas: MySQL 8.4+, MariaDB 10.11+ y PostgreSQL 17+ |
| Instalación Pterodactyl 1.x | PHP 8.2 o 8.3, recomendado 8.3; MySQL/MariaDB y servicios web/cola/caché documentados |
| Documentación beta Pterodactyl 2.0 | PHP 8.3 o 8.4, Composer 2, Redis y versiones documentadas de MySQL/MariaDB |
| Nodo Wings | Linux con Docker funcional; arquitectura compatible entre Wings, imágenes y binarios del juego |
Fuentes: requisitos de instalación Pelican, instalación Pterodactyl 1.x, requisitos Pterodactyl 2.0 e instalación Wings de Pelican.
La documentación puede avanzar más que una compilación fijada. Sigue las dependencias de la versión que realmente despliegues; la tabla no recomienda actualizar PHP en producción a ciegas. Ubuntu 24.04 LTS es un punto de partida común razonable, pero sus paquetes predeterminados no satisfacen automáticamente todos los requisitos actuales de Pelican.
Prefiere un VPS Linux KVM para un nodo Docker sencillo de desplegar. La virtualización VPS basada en contenedores puede funcionar si el host activa las funciones de kernel necesarias, pero debes confirmarlo. Un binario ARM64 de Wings tampoco ejecuta de forma nativa en ARM un juego exclusivo de x86.
Red y seguridad: puntos de fallo habituales
Trátalos como servicios independientes, cada uno con sus reglas:
| Servicio | Plan de acceso habitual |
|---|---|
| HTTPS del Panel | TCP 443 para usuarios/administradores; TCP 80 solo para redirección o validación del certificado si hace falta |
| API y consola Wings | Puerto configurado del daemon y TLS; permitir rutas necesarias para Panel y navegador |
| SFTP Wings | Puerto SFTP configurado, normalmente TCP 2022; limitar según usuarios |
| Asignaciones de juegos | Abrir los puertos TCP y/o UDP exactos de cada juego |
| Base de datos del Panel y Redis | Conectividad local/privada; evitar exposición pública |
No limites Wings únicamente a la IP del Panel sin comprobar cómo llegan los navegadores a la consola y a los endpoints de transferencia. Poder iniciar sesión en el Panel no demuestra que el navegador llegue a Wings.
Los puertos publicados por Docker pueden interactuar de forma inesperada con el cortafuegos del host. Verifica la exposición desde una red externa y sigue las instrucciones Docker para tu backend. Una regla UFW aparentemente restrictiva no demuestra por sí sola que el puerto publicado esté bloqueado. Fuente: filtrado de paquetes y cortafuegos Docker.
Utiliza imágenes fiables y eggs revisados, mantén el host, limita privilegios y prueba la renovación de certificados. El aislamiento reduce ciertos riesgos, pero no garantiza que el host no pueda verse comprometido. La protección DDoS de red depende del proveedor y la red, no del panel.
Cinco proveedores VPS para Pelican o Pterodactyl
Estos proveedores aportan la infraestructura bajo el panel. No son versiones rivales de Pelican o Pterodactyl, y un botón de instalación de juegos no demuestra que ninguno venga preinstalado.
| Proveedor | Mejor encaje | Despliegue | Principal comparación |
|---|---|---|---|
| LightNode — recomendación general | Flexibilidad regional y evaluaciones cortas | Instalar cualquiera en Linux KVM autogestionado | Ubicación, tamaño y facturación horaria/mensual |
| Hostinger | Atajo para instalar Pterodactyl Panel | Plantilla Pterodactyl; Wings aparte | Periodo inicial, renovación y alcance de la plantilla |
| Hetzner | Elegir CPU compartida o dedicada | Instalar cualquiera | CPU sostenida, arquitectura y región |
| Vultr | Comparar niveles de cómputo | Instalar cualquiera | Nivel concreto, recursos y presupuesto completo |
| DigitalOcean | Operaciones dirigidas por desarrolladores | Instalar cualquiera en un Droplet Linux | Familia CPU y servicios auxiliares |
Compara asignación de CPU, RAM, disco, tráfico, direcciones, copias y renovación equivalentes. La VM más barata anunciada no sustituye de forma equivalente a un nodo dimensionado para juegos.
1. LightNode — Mejor opción general por flexibilidad
La oferta de servidores de juegos de LightNode describe VPS KVM, almacenamiento NVMe, más de 40 ubicaciones y facturación horaria/mensual. También permite instalar con un clic los juegos disponibles.
Características: base VPS Linux, ubicación regional, NVMe, facturación flexible y catálogo de instalación. Aquí se contempla instalar Panel/Wings por cuenta propia; el catálogo no confirma una pila Pelican o Pterodactyl preinstalada.
Ventajas
- La elección regional adapta el nodo a la geografía de la comunidad.
- La facturación horaria sirve para preproducción y comparaciones.
- Infraestructura adecuada para mantener el control de tu pila.
Desventajas
- Comprueba si la región y configuración elegidas están agotadas antes de contratar.
Nuestra recomendación: primera opción si quieres probar una región cercana antes de un despliegue persistente. Es una valoración de adecuación, no una victoria medida en rendimiento.
Visitar LightNode Game Server Hosting.
2. Hostinger — Mejor para una plantilla Pterodactyl Panel
Hostinger ofrece un despliegue Pterodactyl con Panel, MariaDB y Redis. La página especifica que Wings se instala aparte en los nodos de juegos.
Características: VPS KVM, NVMe, plantilla Pterodactyl y copias semanales de infraestructura.
Ventajas
- Reduce el trabajo inicial del Panel.
- Niveles de recursos claros para comparar configuraciones mayores.
Desventajas
- La plantilla no completa la instalación del nodo de juegos.
- Las mensualidades anunciadas son equivalencias de pagos anticipados; la renovación cambia.
- Una plantilla Pterodactyl no acredita que Pelican esté incluido.
Nuestra recomendación: considéralo si el arranque del Panel importa más que probar infraestructura brevemente. Comprueba la versión y termina Wings.
Visitar Hostinger Pterodactyl Hosting.
3. Hetzner — Mejor para valorar vCPU dedicadas
Hetzner Cloud separa recursos compartidos y vCPU dedicadas, y ofrece redes privadas, cortafuegos y API. La asignación de CPU es así una decisión explícita.
Características: vCPU compartidas/dedicadas, Linux, redes privadas y automatización.
Ventajas
- Permite elegir según carga variable o CPU sostenida.
- Sus redes facilitan separar Panel y nodos de juegos.
Desventajas
- Los planes compartidos requieren pruebas en horas punta.
- Arquitectura, disponibilidad regional, direcciones y copias afectan la comparación.
Nuestra recomendación: compara vCPU dedicadas si has observado contención del host. Comprueba la arquitectura de la imagen del juego antes de elegir.
4. Vultr — Mejor para comparar niveles de cómputo
Vultr ofrece categorías generales y orientadas al rendimiento. Su catálogo permite evaluar distintos tipos de instancia para una pila instalada por ti.
Características: varios niveles, instancias Linux y opciones documentadas de despliegue con imágenes/copias.
Ventajas
- Comparaciones más allá de una única familia básica de VM.
- Adecuado para instalar limpiamente cualquiera de los paneles.
Desventajas
- Un nombre orientado al rendimiento no demuestra CPU dedicada.
- Hay que comparar por separado transferencia y extras.
Nuestra recomendación: prueba el nivel concreto, incluida una fase de copias. Las etiquetas no predicen por sí solas la latencia del tick.
Visitar Vultr · Consultar Cloud Compute.
5. DigitalOcean — Mejor para equipos con herramientas propias
Los Droplets DigitalOcean son VM Linux con vCPU compartidas y dedicadas. Encajan con equipos que mantienen el panel junto con su automatización.
Características: varias familias, imágenes Linux/personalizadas y servicios cloud auxiliares.
Ventajas
- Opciones de CPU para distintas fases de carga.
- Ecosistema útil para operaciones dirigidas por desarrolladores.
Desventajas
- Los planes pequeños anunciados no son un presupuesto sensato para Panel y juego juntos.
- Copias y transferencia saliente pueden aumentar el total.
Nuestra recomendación: compáralo si el equipo ya utiliza sus herramientas. Dimensiona primero el juego y calcula la factura completa.
Visitar DigitalOcean Droplets.
Migrar de Pterodactyl a Pelican
Trata la migración como un cambio de datos, no como instalar un tema. La guía oficial de Pelican describe una actualización de la base de datos en el mismo entorno y advierte que no se deshace simplemente. Documenta Pterodactyl 1.11.4 o posterior como origen compatible y las dependencias actuales de Pelican.
Antes de proceder:
- Ensaya en una copia aislada, evitando que agentes y automatizaciones de producción se conecten.
- Conserva base de datos del Panel,
.env, clave de cifrado, configuración Wings, archivos del juego y copias externas. - Inventaría eggs, temas, modificaciones, clientes API, tareas y facturación.
- Sigue el procedimiento vigente, incluida la transición Wings en cada nodo.
- Prueba acceso, consola, SFTP, acciones de encendido, tareas, creación/restauración de copias y aprovisionamiento.
- Si debes revertir, restaura conjuntamente la base de datos previa y el software/configuración correspondiente.
La guía indica que temas y modificaciones del Panel no se transfieren y que cambian endpoints antiguos de nests/locations. Conservar claves API no garantiza que todos los scripts sigan funcionando. No conectes ambos paneles como escritores activos a la misma base migrada.
¿Cuál deberías elegir?
| Situación | Recomendación |
|---|---|
| Pterodactyl 1.x funcionando en producción | Mantener parches; migrar para resolver un problema concreto |
| Comunidad nueva interesada en plugins y roles Pelican | Probar en preproducción, verificar versión e integraciones |
| Interés en funciones de Pterodactyl 2.0 | Beta en pruebas, siguiendo las recomendaciones de producción oficiales |
| Mal rendimiento con cualquiera | Analizar juego y host antes de cambiar |
| Jugadores lejos del nodo | Revisar ubicación y rutas |
| Poco tiempo para administrar | Comparar alcance real de preinstalación y soporte continuo |
Preferimos LightNode cuando región y facturación encajan. Elige el nodo alrededor de tus jugadores, prueba la carga real y comprueba disponibilidad de la configuración. Después decide el panel según funciones administrativas e integraciones.
Preguntas frecuentes
¿Pelican es más rápido que Pterodactyl?
Aquí no se establece una ventaja universal. Mide por separado respuesta del Panel, operaciones y tick/frame con condiciones equivalentes. Cambiar la interfaz no demuestra mayor capacidad del juego.
¿Pueden ejecutarse ambos en el mismo VPS?
Puedes evaluarlos en entornos aislados si hay recursos, con datos y configuración propios. Para comparar justamente, usa ejecuciones secuenciales controladas o considera las diferencias de host. No dejes que dos controladores activos compitan por un nodo y base de datos.
¿Puedo usar los mismos eggs e integraciones?
Revísalos individualmente: compatibilidad de imágenes, variables, instalación y endpoints API. Migrar datos no migra automáticamente temas ni modificaciones.
¿Bastan 4 GB de RAM?
Pueden ser un punto inicial para un Panel pequeño sin juegos. Añadir un juego a esa máquina cambia la respuesta. Presupuesta SO, administración, runtime y margen por separado.
¿LightNode incluye Pelican o Pterodactyl preinstalados?
La página revisada describe instalaciones de juegos disponibles. Aquí LightNode se trata como base VPS para desplegar Panel y Wings, sin asumir una imagen de panel incluida.
¿Dónde comparo más detalles de alojamiento?
Consulta la guía de alojamiento Pelican Panel para sus despliegues y la guía Pterodactyl Panel para opciones e instalación.
Recomendación final
Mantén Pterodactyl 1.x para un despliegue probado o evalúa Pelican si su flujo aporta una mejora concreta. Vigila los canales de versiones, especialmente al comparar la RC de Pelican con las ramas estable y beta de Pterodactyl.
Para VPS, LightNode es nuestra primera opción general para comunidades que priorizan flexibilidad regional y evaluaciones cortas. Confirma disponibilidad, reserva capacidad para toda la pila y realiza una sesión representativa antes de lanzar.