El panel de servidor construido para un trabajo — ejecutar 6amMart
Rentas un servidor nuevo, ejecutas una orden, y obtienes de vuelta una página web que ejecuta tu tienda. SixPanel instala el servidor web, la base de datos, PHP, la caché, el worker en segundo plano, el scheduler, el servidor websocket y HTTPS — todo configurado de la forma que 6amMart realmente lo necesita.
Todo se ejecuta en tu servidor. Tu base de datos, tus imágenes, los datos de tus clientes.
- Más rápido que un aaPanel completamente ajustado — mismo hardware, misma tienda, medido
1.76×
Más rápido que un aaPanel completamente ajustado — mismo hardware, misma tienda, medido
- Ejecuta una tienda completa
2 núcleos / 4 GB
Ejecuta una tienda completa
- Publicado en CodeCanyon, setup inicial hecho para ti
Gratis
Publicado en CodeCanyon, setup inicial hecho para ti
- Idiomas de interfaz del panel
8
Idiomas de interfaz del panel
¿Estás leyendo esto con un asistente de IA?
Conseguir SixPanel
SixPanel se instala con un solo comando. Nada que registrar, ninguna clave que introducir, ningún código que pegar — es el mismo comando para todo el mundo. Es gratis.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashLo que protege un comando que se ejecuta como root no es la dirección — es la firma de la versión. El instalador lleva nuestra clave de firma y rechaza automáticamente cualquier archivo que no coincida. La página de instalación lo explica.
Pruébalo antes de descargarlo
Acceso de solo lectura
Username: demo Password: g5b7h878vjQN
Read-only: every change is refused and secrets are masked.
The shop runs a real dataset — tens of thousands of orders — so the screens behave the way they will on yours, not the way a demo with forty products does. Two things are switched off on the demo: maps and SMS one-time passwords. Both use keys locked to a single server, which is how they should be held, so they cannot answer from a demo host. They work normally on your own install.
Obtener SixPanel
Free- Actualizaciones incluidas — cada versión llega a CodeCanyon sin coste adicional, y el panel también puede actualizarse solo. Sin servidor de licencias, sin clave que renovar.
- La primera configuración es gratis — envía tu código de compra y los datos del servidor por WhatsApp o correo.
Nada que activar — funciona en tu propio servidor, no llama a casa, y sigue funcionando aunque este sitio esté caído.
Qué es y qué reemplaza
El script es tuyo. Alguien igual tiene que operar el servidor.
Compraste el script 6amMart en CodeCanyon. Es una carpeta con archivos. Antes de que pueda recibir un pedido, alguien tiene que instalar un servidor web, una base de datos, PHP, una caché, un worker en segundo plano y un certificado HTTPS — y después mantener todo eso funcionando.
SixPanel es la parte que hace eso. Alquilas un servidor nuevo, corres un comando y recibes un panel de control web. Desde ese panel conectas tu dominio, obtienes HTTPS gratis, instalas tu código de 6amMart desde git, lo actualizas, lo respaldas, y ves qué está roto cuando algo se rompe.
Todo corre en tu servidor. Tu base de datos, tus imágenes, los datos de tus clientes.
Tres formas de manejarlo
El panel
En un navegador. Aquí haces casi todo.
El comando sixpanel
En el servidor, para cuando el panel no abre.
El instalador
Que corres una sola vez.
Con esto frente a sin esto
Cada fila es el mismo trabajo, hecho de las dos maneras. A la izquierda, lo que ejecutar 6amMart te exige sin SixPanel; a la derecha, en qué se convierte con él.
Poner el servidor en marcha
Sin esto
Construir un servidor a mano — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, un supervisor de procesos — y mantenerlo todo vivo
Con SixPanel
Una orden de instalación. systemd es el supervisor — reinicia al fallar, reinicia al reiniciar, límites de memoria, rotación de logs y un health check en cada servicio, declarado en un lugar. En el runtime Docker, Docker Compose hace el mismo trabajo.
Dimensionar la base de datos y PHP
Sin esto
Adivinar los ajustes de la base de datos y de PHP, o pagar a alguien para que los afine
Con SixPanel
Ajuste automático lee la máquina real y escribe los tamaños: workers PHP, pool de buffer de base de datos, memoria de caché, tablas temporales, buffers de sort y join y el redo log. Cubre 1 núcleo / 2 GB hasta 16 núcleos / 32 GB, y los dos lugares que calculan esos números se verifican uno contra el otro en cada build — porque una vez estuvieron en desacuerdo en 66 de 432 valores.
Shipping a change to the shop
Sin esto
Paying a developer for every deployment
Con SixPanel
Haces push a git y la tienda se actualiza. Historial de despliegues y vuelta atrás, con los últimos 30 despliegues guardados.
Knowing the backup works
Sin esto
Hoping the backup works
Con SixPanel
Las copias de seguridad siguen un calendario con retención, y una vez por semana el panel carga la más reciente en una base de datos desechable, cuenta lo que hay dentro y la borra de nuevo.
When the shop goes down
Sin esto
Leer una traza de error para averiguar por qué la tienda está caída
Con SixPanel
Una página de Salud con unas veinte comprobaciones, cada una con una frase llana sobre la consecuencia y exactamente un botón para arreglarlo.
What it costs
Sin esto
Construir y mantener esa pila tú mismo es el coste, lo pagues en horas o en facturas.
Con SixPanel
Nada. SixPanel es gratis en CodeCanyon, la primera instalación y configuración es gratis, y el comando de instalación es el mismo comando público para todo el mundo — sin clave que introducir, sin código que pegar. Las actualizaciones llegan por CodeCanyon, y el panel también puede actualizarse solo.
Qué no reemplaza
No te vende el script 6amMart.
Eso lo compras en CodeCanyon, y SixPanel instala el código que ya tienes.
No es hosting compartido.
Sin cuenta de cPanel, sin otros sitios web en la máquina. SixPanel espera el servidor completo.
No opera tu tienda.
Los precios, productos, repartidores y pedidos viven en el propio panel de administración de 6amMart.
No es un CDN ni un servicio anti-DDoS.
Cloudflare es la verdadera capa de borde, y la documentación lo dice.
Dos formas de ejecutarlo
Un panel, dos entornos de ejecución — y uno de ellos es el recomendado
Ambos son el mismo producto, con el mismo panel, los mismos comandos y el mismo manual. Solo se diferencian en cómo se instala el software que hay debajo, y esa diferencia es medible.
- Recomendado
SixPanel
Se ejecuta directamente en el servidor
nginx, PHP-FPM, MariaDB y Redis instalados desde el propio archivo de la distribución del release y supervisados por systemd. Nada está en contenedores, así que cada salto es un socket unix y la base de datos está ajustada a la máquina y no a un contenedor. Es el más rápido de los dos, y es donde va todo el trabajo nuevo.
Comando de instalación
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- Sistema operativo
- Ubuntu 26.04 LTS (recomendado), Ubuntu 24.04 LTS o Debian 13
- PHP
- 8.5 en Ubuntu 26.04, 8.4 en Debian 13, 8.3 en Ubuntu 24.04 — siempre el propio paquete del release
- Base de datos
- MariaDB 11.8 en Ubuntu 26.04 y Debian 13, 10.11 en Ubuntu 24.04 — del mismo archivo
- Supervisado por
- systemd
SixPanel Docker
Se ejecuta en contenedores
El mismo stack como servicios de Docker Compose. Su ventaja es que las versiones de PHP y de la base de datos no dependen del host en absoluto: las imágenes están fijadas en PHP 8.4 y MariaDB 10.11 sobre cualquier release en el que las corras. Sigue instalándose, y los servidores que ya lo corren siguen recibiendo actualizaciones.
Comando de instalación
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- Sistema operativo
- Ubuntu 24.04 / 26.04 LTS, Debian 13 — y Debian 12, que se instala pero no es recomendado
- PHP
- 8.4, en el contenedor
- Base de datos
- MariaDB 10.11, en el contenedor
- Supervisado por
- Docker Compose
¿Cuál deberías elegir?
Elige SixPanel salvo que algo concreto exija el otro. Es más rápido en todos los endpoints medidos, aísla los proyectos en el kernel en lugar de dentro de PHP, y es el entorno que sigue mejorando.
Elige SixPanel Docker si quieres todo el stack aislado en contenedores, o si necesitas específicamente MariaDB 10.11 en un release cuyo archivo no la trae — las imágenes están fijadas en PHP 8.4 y MariaDB 10.11 sin importar el host. También sigue instalándose en Debian 12, pero no arranques una tienda nueva ahí: el soporte de seguridad de Debian 12 terminó en julio de 2026, y el kernel, glibc, Docker y OpenSSH siguen viniendo del archivo del host.
Dicho con franqueza: el desarrollo nuevo va al entorno nativo. SixPanel Docker se mantiene, no se amplía. Si instalas hoy y puedes elegir libremente el sistema operativo, elige el nativo.
Medido, no afirmado
Tres servidores, la misma tienda, una sola diferencia
Todas las cifras de rendimiento de esta página vienen de una ronda de mediciones en servidores reales con los datos de una tienda real. La configuración, el método y los scripts están publicados — y también la parte que sigue sin explicación.
1.76×
más rápido que un aaPanel plenamente ajustado
1,82× cuando llegan cuatro peticiones a la vez. Medido en los endpoints que llegan a PHP en ambos servidores.
Cómo se midió
- Tres servidores
- AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — idénticos salvo por el panel que se estaba probando
- La misma aplicación
- El mismo código de 6amMart en los tres, verificado byte a byte: mismo archivo de bloqueo de dependencias, mismo hash en la aplicación, las rutas, los módulos y la configuración
- La misma tienda
- 66.701 pedidos · 3.865 artículos · 85 tiendas · 17.534 clientes — un conjunto de datos real, copiado fila a fila
- El método
- Cada máquina se mide a sí misma por loopback con su nombre de host y su certificado reales. 40 muestras por celda tras descartar un calentamiento, y cada cifra publicada es la mediana de pasadas emparejadas y alternadas.
- Nada descartado en silencio
- Cero respuestas limitadas por tasa y cero errores en todas las filas publicadas. Una petición bloqueada o fallida se responde muy rápido, así que una ejecución que las esconde informa de un número mejor que la verdad.
Todos los endpoints, en las cuatro configuraciones
Milisegundos medianos — una petición / cuatro a la vez. Menos es mejor.
| Endpoint | SixPanel | SixPanel Docker | aaPanel, de serie | aaPanel, ajustado |
|---|---|---|---|---|
/api/v1/categoriesObligado a pasar por PHP en los tres — la fila más limpia y comparable | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allEl listado de tiendas que ve primero cada cliente | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchLa lectura más pesada de la aplicación | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularCruza consultas por todo el catálogo | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listCon sesión iniciada y sin caché posible — la llamada más lenta en todos los servidores | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel redirige en 430 bytes; aaPanel renderiza 352 KBTrabajo distinto | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeSixPanel renderiza la página; la de aaPanel es un acierto de caché del proxyTrabajo distinto | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeTiempo hasta que la conexión queda aceptada | 2.35.8 | 4.211.6 | 2.66.3 | —— |
En verde, la configuración más rápida de esa fila.
Dos filas están marcadas porque los servidores no están haciendo el mismo trabajo en ellas. Las cifras son reales; simplemente no son una carrera justa, y se muestran en lugar de descartarse.
Después se ajustó a fondo al rival, y la diferencia no se cerró
Ganar a un competidor con su configuración de serie no demuestra nada. Así que el servidor con aaPanel se ajustó como lo haría un administrador competente, y se volvieron a tomar todas las cifras.
- Caché de código compilado de PHP subida de 128 MB a 256 MB, con la validación por marca de tiempo desactivada
- Pool de búfer de la base de datos subido de 256 MB a 1152 MB — cuatro veces y media mayor
- Archivo de registro de la base de datos subido de 128 MB a 320 MB, y la caché de consultas desactivada
- Procesos de PHP corregidos de unos 50 sobrecomprometidos a 14 bien dimensionados
- Caché de rutas cuadruplicada y búferes del servidor web duplicados
Su PHP 8.4 y su compilador JIT se dejaron deliberadamente activados. Son sus ventajas, y quitárselas habría amañado la prueba.
Frente al servidor de serie, SixPanel fue 1,65× / 1,80× más rápido. Frente al plenamente ajustado es 1,76× / 1,82×. La diferencia se movió ligeramente en el otro sentido.
La batería de base de datos no se movió en absoluto. Un pool de búfer cuatro veces y media mayor no cambió nada, porque estos informes son trabajo de procesador sobre filas que ya estaban en memoria. Los indicadores internos sí mejoraron — tasa de acierto de la caché del 99,856 % al 99,930 %, tablas temporales volcadas a disco del 47,3 % al 22,1 % — y los tiempos de respuesta no siguieron.
De dónde viene realmente la diferencia
Una afirmación de velocidad vale muy poco sin una causa. Así que la diferencia se desmontó en los cinco endpoints que llegan a PHP en ambos servidores, variable a variable.
| Configuración | Una petición | Cuatro a la vez |
|---|---|---|
| Tal como vienen los dos servidores | 1.99× | 1.91× |
| Tras desactivar la restricción de directorios de aaPanel | 1.32× | 1.29× |
| Tras corregir además su modo de compilador JIT | ≈1.25× | ≈1.21× |
La diferencia, atribuida
- Una restricción de directorios de PHP60%
- El modo de compilador JIT equivocado8%
- Versión de PHP0%
- Todavía sin explicar32%
Alrededor de un tercio de la diferencia no está explicado, y se publica como no explicado en lugar de atribuírnoslo. El candidato principal sin comprobar es que aaPanel compila su propio PHP mientras que Ubuntu entrega un paquete. Ni eso ni la diferencia de ajustes restante pueden aislarse en una sola máquina, así que no se afirma ninguno de los dos.
La forma importa más que la proporción
El coste es fijo por petición, así que domina en el trabajo corto y desaparece en el largo. El mismo informe de administración de 20,9 segundos solo se separa 1,17× entre los dos servidores. Si tu tienda son sobre todo informes pesados de trastienda, la diferencia será pequeña. Si son sobre todo llamadas de API desde la app del móvil — que es lo que es casi toda tienda de reparto de comida — es toda la diferencia.
El desarrollo completo
La mayor causa aislada fue un ajuste de PHP, y costaba de 16 a 26 ms en cada petición≈60 % de la diferencia
aaPanel restringe qué directorios puede tocar PHP. Eso es una medida de seguridad real, así que merecía una medición de verdad y no despacharla como sobrecarga.
Tres pares alternados, con el lado «desactivado» escribiendo un archivo de ajustes vacío para que el escaneo por directorio ocurra en ambos lados — si no, la comparación mediría el escaneo en vez del ajuste.
Todos los endpoints se movieron entre un 17 % y un 46 %. Un archivo estático, que nunca llega a PHP, no se movió nada — ese es el control, y es lo que convierte el resto en un resultado y no en una casualidad. La dispersión entre pasadas en estos servidores es del 1 % al 13 %.
El mecanismo se contó después de tres formas distintas: 5.862 consultas al sistema de archivos por petición con la restricción activada, 214 con ella desactivada y 217 en SixPanel. Con ella activada, 400 resoluciones de ruta añaden cero entradas a la caché de rutas de PHP; sin ella añaden 509. La caché simplemente queda desactivada, y por eso el propio ajuste de tamaño de caché de aaPanel no le sirvió de nada.
Confirmado en la otra dirección en una segunda máquina: activar esa misma restricción en SixPanel reprodujo de 17 a 23 ms extra por petición.
Conviene saberlo si administras un servidor: este ajuste estaba en un archivo por directorio que otros cuatro sitios no mostraban. Leer el valor desde el proceso que realmente sirve las peticiones es la única comprobación fiable.
| Endpoint | Restricción activada | Restricción desactivada | Cambio |
|---|---|---|---|
/api/v1/config | 37.7 | 20.3 | −46% |
/api/v1/stores/get-stores/all | 39.8 | 23.5 | −41% |
/api/v1/items/search | 40.6 | 24.1 | −41% |
/api/v1/categories | 55.4 | 33.7 | −39% |
/api/v1/items/popular | 70.7 | 51.5 | −27% |
/ (admin entry) | 85.7 | 66.4 | −23% |
/api/v1/customer/order/list | 154.9 | 128.9 | −17% |
static assetControl — nunca llega a PHP | 0.4 | 0.4 | 0% |
aaPanel ejecuta el modo de compilador JIT equivocado para esta aplicación≈8 % de la diferencia
El ajuste JIT de PHP es un número de cuatro cifras, no un interruptor, y los dos modos con nombre son distintos: «function» es 1205 y «tracing» es 1254. Un script de ajuste que solo comprueba si el JIT está activado dejará tranquilamente el modo equivocado y dará el trabajo por hecho.
aaPanel viene con 1205. SixPanel viene con tracing. Tres pares alternados dejaron tracing por delante en 9 de 9 endpoints con una petición y en 9 de 9 con cuatro a la vez — media geométrica del 5,1 % y el 6,2 %.
Cualquiera de esas diferencias por separado cae dentro del ruido de estas máquinas. Dieciocho de dieciocho cayendo del mismo lado, no.
Para 6amMart en concreto, tracing es el modo correcto: el JIT de función apunta a bucles numéricos apretados, y una petición de Laravel no ejecuta ninguno.
Ir una versión de PHP por detrás no cuesta nada — medido, no supuesto0 % de la diferencia
SixPanel instala el PHP que trae el propio archivo del release — 8.5 en Ubuntu 26.04, 8.4 en Debian 13, 8.3 en Ubuntu 24.04 — porque quedarse en los propios paquetes de la distribución significa que las actualizaciones de seguridad llegan automáticamente, sin ningún repositorio de terceros en la ruta que sirve. La objeción obvia es que un PHP más nuevo es más rápido.
El servidor con aaPanel tiene las dos versiones instaladas, así que podía responder a esto con limpieza. Al pool de 8.3 se le dio primero todo el ajuste de 8.4 — estaba con la configuración por defecto, lo que habría amañado el resultado — y los ajustes se verificaron desde el proceso en marcha, no desde un archivo.
Tres pares alternados: la media geométrica de 8.3 frente a 8.4 es 0,9994. 8.3 fue por delante en 3 filas de 7, y toda diferencia era menor que la propia dispersión de al menos una de las pasadas. El informe lento de administración coincidió.
Así que la regla que mantiene a SixPanel en los propios paquetes de la distribución es gratis: no cuesta velocidad. Tampoco hay techo que sortear: el composer.json de 6amMart declara un límite por debajo de 8.5, pero eso es una declaración y no una medición, y correr el código en 8.5.4 produjo una exportación de hoja de cálculo idéntica byte a byte y un Laravel que arranca, tanto en el árbol puro de CodeCanyon como en nuestro propio fork.
Lo que se comprobó y resultó no ser la causaSeis candidatos
Cada uno de estos es una explicación plausible que alguien podría ofrecer. Cada uno se midió y quedó descartado.
- El servidor web
- Cada endpoint se cronometró por la red y de nuevo dentro de un solo proceso de PHP, en ambos servidores. La diferencia es de 0 a 7 ms en aaPanel y de 3,5 a 5 ms en SixPanel, en su mayoría el saludo de cifrado. La de aaPanel no es mayor, pese a escribir una entrada de registro por petición.
- La base de datos
- Tiempos de consulta prácticamente idénticos en las tres configuraciones. Conjuntos de datos dentro de un 1 % en todas las tablas, y configuraciones equivalentes tras el ajuste salvo por el nivel de parche.
- Cómo llega PHP a la base de datos
- Los dos por el socket local, verificado desde el proceso en marcha y no desde un archivo de configuración.
- La capa de caché
- Contado, no leído de un archivo de configuración: 17,1 comandos de caché por petición en aaPanel, 18,1 en SixPanel. Ninguno está cayendo en silencio al disco.
- La caché de código compilado de PHP
- Cero incidentes por falta de memoria, cero colisiones de hash y cero reinicios manuales en ambos. SixPanel con un 99,86 % de aciertos y un 0 % desperdiciado.
- El hardware
- Idéntico hasta el modelo de procesador y el conjunto de mitigaciones de seguridad activadas.
Lo más lento de 6amMart no es el servidor, y ningún panel puede arreglarloCódigo de la aplicación
Se cronometraron las 297 páginas de administración sobre el conjunto real de 66.701 pedidos. 290 responden en menos de 300 ms. El panel no es lento en general.
Siete páginas concentran todo el problema. La peor, el informe diario de transacciones, tarda 20,86 segundos, de los cuales 12,43 se pasan dentro del controlador de base de datos — y una sola consulta se ejecuta 122 veces a 87,6 ms cada una, que son 10,7 segundos por sí solos.
Está presente en todos los servidores probados y no la movió ningún ajuste, incluida la pasada completa de ajuste de aaPanel: 20.925 ms antes, 20.470 ms después.
Esto es código propio de 6amMart, así que ningún panel de control puede arreglarlo y ninguno debería decir que lo hace. Está documentado a fondo contra la propia aplicación, y es justo el tipo de cosa para la que existe nuestro servicio de instalación de 6amMart.
Todo lo que publicamos
Cada informe, en un solo lugar
Ningún número de esta página está suelto: cada uno viene de un informe publicado con su método, sus salvedades y los resultados que no nos favorecieron. Léelos antes de comprar; para eso están.
SixPanel vs aaPanel
1.76× más rápido con una petición, 1.82× con cuatro llegando a la vez — contra un aaPanel completamente afinado, con la causa desglosada y el 32% de la brecha etiquetado honestamente como sin explicar.
SixPanel vs SixPanel Docker vs aaPanel
Tres paneles en hardware idéntico y una tienda idéntica byte a byte — el método completo detrás de los números del titular.
SixPanel vs CloudPanel
Una comparación justa: CloudPanel es buen software de propósito general. La pregunta es qué problema estás resolviendo.
SixPanel vs un servidor a secas
Lo que el panel agrega sobre el servidor armado a mano con el que la mayoría de los dueños empieza — y lo que eso cuesta a lo largo de un año.
Qué sistema operativo
Ubuntu 26.04 contra Ubuntu 24.04 contra Debian 13, medidos: la velocidad es un empate, las ventanas de soporte no.
Qué motor de base de datos
Cinco motores contra una tienda real. MariaDB 11.8 y 10.11 son un empate en toda la aplicación; ninguno de los dos MySQL puede correrla sin modificar.
6amMart optimizado — los resultados medidos
La franja de destacados 22× más rápida, el barrido de 297 páginas del admin, un informe de 17.5 segundos llevado a 0.7 — con las dos páginas dejadas lentas a propósito, publicadas junto a las victorias.
La prueba de escala
66,701 pedidos reales, 113,231 líneas de pedido — el dataset donde afloraron los defectos silenciosos.
Defectos corregidos
Los que cuestan dinero sin mostrar jamás un error — cupones, relojes, inventario, pagos dobles.
Lo que sigue abierto
La página que hace que valga la pena leer las otras cuatro: lo que no hemos resuelto, dicho sin rodeos.
El changelog
Cada versión, incluidos los errores y lo que nos enseñaron.
Lo que realmente recibes
Agrupado como un comprador piensa el trabajo
Dos cosas llevan una salvedad explícita. La transferencia desde un servidor viejo y la restauración en la misma máquina se verificaron leyendo el código en la ronda del 15 de agosto y no se ejecutaron. Están marcadas abajo. Todo lo demás aquí se ejerció o es una superficie que se entrega y se puede inspeccionar — pero la forma honesta de la frase es “esto se entrega”, no “esto se ha probado en un servidor como el tuyo”.
Ponerlo en marcha
De un servidor alquilado a un login del panel, sin armar el stack a mano.
- Un solo comando. El comando de instalación se descarga, se compara con una huella publicada, y recién entonces se ejecuta. Si las huellas no coinciden, el comando se detiene y no se instala nada.
- Rechaza por nombre un servidor donde no puede correr, antes de descargar nada: sistema operativo equivocado, tipo de procesador equivocado, muy poca memoria, otro panel de control presente, o algo usando ya el puerto 80 o 443.
- Un asistente de configuración en el primer login: básicos → contraseña → dominio → SSL → app → respaldos.
- Autotune en la instalación, y cuando lo pidas después. Dimensiona la base de datos, la caché y los workers de PHP según la máquina real.
- Hace funcionar una tienda completa con 2 núcleos y 4 GB.
- Verificado por lectura, no ejecutado: O mueve aquí una tienda existente. SixPanel puede traer una instalación en vivo desde un servidor viejo por SSH — el archivo de configuración, los archivos subidos y un volcado de base de datos enviado por la conexión. No se ejerció en la ronda del 15 de agosto, solo se verificó por lectura. Pruébalo contra un servidor de repuesto antes de depender de él, y conserva la máquina vieja hasta haberlo hecho.
Por qué importa: el primer día es donde la mayoría de las tiendas pierde una semana — este termina con una página funcionando.
Tu dominio y HTTPS
Certificados reales, renovados automáticamente para ti, y Cloudflare manejado como corresponde.
- Certificados gratuitos de Let's Encrypt, renovados automáticamente por una tarea diaria.
- Más de un dominio por tienda, por destino (admin, tienda web, websocket), cada uno con sus propias marcas de principal, SSL y Cloudflare.
- Tiene en cuenta a Cloudflare. Primero intenta un certificado real de Let's Encrypt a través del proxy de Cloudflare, que funciona con Full (strict). Si eso no se puede, cae a un certificado de origen autofirmado de 10 años, que necesita Full. Incluye los rangos de IP de Cloudflare para que tus logs muestren la dirección real del visitante, no la de Cloudflare.
- Un token de Cloudflare, y el panel administra por ti un conjunto de opciones de Cloudflare. Muestra el valor deseado frente al valor en vivo de cada elemento, y una sincronización push o pull. Tus propias reglas sobreviven a una escritura.
- Una página de firewall que imprime las reglas exactas para tu servidor, además de las dos listas de rangos de Cloudflare y los comandos para comprobarlas. El panel nunca toca el firewall de tu proveedor.
Por qué importa: las fallas de HTTPS son el clásico asesino silencioso — un certificado que vence un sábado se lleva la tienda consigo.
Publicar cambios de código
Dos tipos de actualización que nunca se confunden entre sí.
- Push para desplegar. Un webhook firmado desde tu servicio de git inicia el despliegue.
- Deploys → Update mueve tu código de 6amMart. Settings → self-update mueve SixPanel. Ninguno de los dos toca tu archivo de configuración, tu carpeta data/ ni tu base de datos.
- Historial y rollback, con los últimos 30 despliegues guardados.
- Un guard de árbol limpio. Si editaste archivos en el servidor, la actualización se rechaza y nombra los archivos en vez de sobrescribir tu trabajo.
Por qué importa: los minutos más riesgosos de operar una tienda son los que vienen justo después de "deploy" — esto los vuelve aburridos.
No perder nada
Programados, incrementales, y comprobados una vez por semana en vez de darlos por hecho.
- Respaldos incrementales (restic), con horario y política de retención.
- Cuatro destinos: el mismo servidor, S3, SFTP o Google Drive.
- Una prueba de restauración automática semanal en una base de datos descartable — tus datos en vivo nunca se tocan, y el resultado aparece tanto en la página de Respaldos como en la de Salud.
- Un respaldo contiene la base de datos de cada proyecto, los archivos subidos y el archivo de configuración de la aplicación. No contiene tu código — ese vuelve desde git.
- Una sola contraseña de respaldo compartida, generada una vez y guardada en el estado del panel. Si la pierdes, ningún respaldo se podrá volver a abrir nunca.
- Verificado por lectura, no ejecutado: La restauración se verificó por lectura, no se ejecutó, en la ronda del 15 de agosto. Mira también los dos límites de restauración más abajo — son la razón por la que esto importa.
Por qué importa: un respaldo sin abrir es una esperanza, no un respaldo. La prueba semanal de restauración es la diferencia.
Usarlo día a día, sin ser sysadmin
El panel nombra el problema y te da el botón.
- Página de Salud: unas 20 comprobaciones, ordenadas en necesita atención, correcto e informativo, cada una con una frase de consecuencia y un botón para arreglarlo. Cada comprobación está limitada a 2 segundos y la página entera a 10, así que una comprobación colgada no puede colgar la página.
- Tres fuentes no coinciden en esa cifra. El manual que se entrega dice «más de veinte», el inventario del código cuenta unas 20 comprobaciones y una especificación de página más antigua dice unas quince. Esta página imprime unas 20 — la menor de las dos cifras respaldadas por el producto entregado.
- Un watchdog que reinicia servicios que están ejecutándose pero no funcionando. Un supervisor de procesos no reiniciará algo que está vivo pero roto, porque nada ha colapsado. El propio loop de SixPanel sí, y sus checks prueban si el trabajo se está realizando en lugar de si el proceso existe.
- Un motor de trabajos. Un trabajo largo cada vez, el resto en cola. El registro se transmite en vivo al navegador. Se guardan los últimos 20 trabajos, 2.000 líneas cada uno.
- Un editor del archivo de ajustes de tu aplicación que conserva tus comentarios, tu orden y tus líneas ajenas, da a cada clave el tipo de campo adecuado y marca como solo lectura las claves que gestiona la pila.
- Un gestor de archivos limitado a exactamente dos carpetas: el código de tu panel de administración y el de tu tienda.
- phpMyAdmin bajo demanda — se arranca y se para desde la página de Base de datos, nunca queda corriendo.
- Captura de consultas lentas que puedes activar y vaciar desde la página de Base de datos.
- Un comando sixpanel en el servidor, con página de manual, chuleta, menú numerado, corrector de «quizás quisiste decir» y autocompletado del intérprete.
- El manual completo del cliente dentro del panel, tras el mismo inicio de sesión — 24 páginas de tareas.
- Un paquete de soporte en un solo comando. Recoge versiones, resultados de salud, estado de los servicios, uso de disco y las últimas 500 líneas de cada registro. Antes de escribirlo, tu archivo de ajustes se reduce a los nombres de las claves, el archivo de estado del panel no se recoge en absoluto, y el código secreto de tu enlace al panel más los valores con forma de contraseña quedan enmascarados.
Por qué importa: el panel que de verdad abres cada día debería responder "¿está todo bien?" en un vistazo, no en una hora.
Dejar entrar a otras personas
Acceso con tiempo limitado en vez de entregar tu contraseña.
- Logins temporales para un desarrollador: su propio nombre y contraseña, que expiran a la 1 hora, a las 8 horas, a las 24 horas o a los 7 días, hasta 20 activos a la vez. La contraseña se muestra exactamente una vez. Pueden operar el sitio. No pueden cambiar quién entra, y no pueden leer tus secretos.
- Un login de demo de solo lectura para mostrarle el panel a alguien. Sesiones de dos horas, toda escritura rechazada, valores sensibles enmascarados.
- Un registro de actividad, y una lista de sesiones activas que puedes revocar de a una o todas juntas.
- Verificado por lectura, no ejecutado: El registro de actividad no cubre todo. Crear, editar y ejecutar manualmente una tarea programada quedan registrados, pero borrar una no escribe ningún registro de auditoría.
Por qué importa: la mayoría de las intrusiones a paneles no son ingeniosas — son una contraseña adivinada en una página de inicio de sesión visible. Esta no es visible.
Más de una tienda en un solo servidor
Separadas por diseño, no por convención.
- Cada proyecto obtiene su propio usuario unix, su propia base de datos y usuario de base de datos, su propia carpeta de aplicación, su propia configuración de sitio y su propia instancia de caché en su propio socket — así que una tienda no puede leer los secretos en caché de otra, y borrar la caché en una nunca puede vaciar otra.
- Dos proyectos no pueden acabar compartiendo base de datos: el nombre se deriva de un identificador validado y único.
- Cuenta con unos 2 GB más de RAM y 1–2 núcleos más por cada tienda adicional — presupuesta 2 núcleos, el extremo alto de ese rango, porque quedarse corto es el error caro.
Por qué importa: la segunda tienda de una agencia no debería poder leer los datos de la primera ni siquiera en teoría — aquí eso lo impone el kernel, y lo atacamos para comprobarlo.
Velocidad que ya viene configurada
Un micro-caché de cinco segundos en el servidor web en tu propia máquina, diseñado alrededor de los propios patrones de solicitud de 6amMart.
- Un caché de cinco segundos en nginx sobre una lista fija de endpoints públicos del catálogo. Si 100 solicitudes llegan al endpoint de config dentro de una ventana de cinco segundos, el caché las convierte en un inicio de PHP en lugar de 100 — esa es aritmética de la ventana de caché, no un resultado de throughput medido. El almacenamiento se limita a 64 MB, con evicción de inactividad de 60 segundos.
- Por qué importa aquí en concreto: la tienda se renderiza en el servidor, así que cada página que ve un comprador se convierte en varias llamadas de API a esa misma máquina, y cada arranque en frío de la app móvil son otras 15–20 llamadas.
- Nunca sirve una respuesta personal o de sesión iniciada. Cualquier cabecera Authorization la salta. Cualquier cookie la salta. nginx se niega a almacenar cualquier respuesta que lleve Set-Cookie. Una lista de exclusión aparte cubre administración, panel de vendedor, inicio de sesión, pago, carrito, pedido y avisos de pago.
- La zona, el módulo y el idioma forman parte de la clave de caché, así que las tiendas de una ciudad nunca pueden servirse a otra.
- Mantiene la tienda en pie cuando PHP no lo hace. Si el grupo de procesos de PHP se atasca, nginx sirve la copia ligeramente antigua y la refresca por detrás — una tienda que funciona en lugar de un muro de errores 502.
- Todo lo demás sigue el hardware también: la base de datos, el caché de código compilado de PHP, memoria de caché y buffers del servidor web se dimensionan todos por ajuste automático desde la máquina real.
- Límites de peticiones dimensionados para redes reales. Límites estrictos en inicio de sesión, códigos de un solo uso y restablecimiento de contraseña; más amplios para navegar; y aparte para la búsqueda y para las escrituras de carrito y pedido. La documentación lo llama por su nombre — un escudo contra avalanchas, no protección DDoS — porque los límites por dirección no pueden ser precisos cuando una ciudad entera comparte una sola IP de operador.
- «Edge» en este sitio significa Cloudflare, que es la capa de borde de verdad. Esta caché no es eso, y no se llama así.
Por qué importa: la velocidad es lo único que un cliente siente en cada visita — y la razón por la que estos números se publican con su método.
Piezas opcionales
Actívalas cuando la tienda las necesite.
- Seguimiento de pedidos en vivo por websockets (Reverb).
- El sitio web de cliente opcional en Next.js, con sus assets estáticos servidos como inmutables.
- Vender solo por las apps móviles, sin sitio web, es una forma soportada.
Por qué importa: las herramientas que necesitas rara vez no deberían costar nada mientras están inactivas — estas arrancan bajo demanda y se quitan del camino.
Revisión de la tienda (SixPreflight, incluido)
Revisa los ajustes dentro de tu tienda, a diferencia del servidor, del que se ocupa SixPanel.
- SixPreflight viene incluido y montado dentro del panel como la página de Revisión de la tienda. Trae unas 134 comprobaciones, un puntaje ponderado y una calificación con letra.
- Por qué 134 y no un número más grande: tres fuentes internas dan tres respuestas. Un conteo directo de las claves únicas de comprobación en el código da 163; el documento de entrega de ingeniería registra 134–136 e indica usar la menor de las dos; una especificación de página más vieja dice unas 100. Esta página imprime ~134, la cifra más baja que defiende una fuente actual.
- Cuando corre dentro de SixPanel cambia de comportamiento a propósito: los bloques de configuración para copiar y pegar desaparecen en las capas que administra el panel, y los ajustes que pertenecen al panel de administración de tu propia tienda se puntúan por separado del servidor.
Por qué importa: el servidor puede estar perfecto mientras un ajuste incorrecto dentro de la tienda cuesta pedidos en silencio — un segundo par de ojos revisa esos ajustes.
Lo que corre solo
La automatización, mapeada
"Automatizado" es una palabra fácil de imprimir. Aquí está cada tarea que el panel ejecuta sin ti: qué la dispara y qué estarías haciendo a mano a medianoche si no.
- Una vez, al inicio
Todo el servidor, desde un comando
Un solo pegado en un servidor Ubuntu recién creado instala el servidor web, la base de datos, PHP, la caché, el worker de colas, el scheduler, el servidor de websockets y el propio panel — cada uno dimensionado para la máquina donde aterriza. Escribes un dominio; todo lo demás se coloca, se configura y se arranca.
- Antes de cada vencimiento
HTTPS que se renueva solo
Los certificados se emiten automáticamente — por DNS cuando Cloudflare administra el dominio, así funcionan antes de que internet siquiera pueda llegar al servidor — y cada renovación recarga el servidor web mediante un hook por certificado, de modo que un certificado roto nunca puede congelar a los demás.
- Según tu horario
Respaldos que sí se ejecutan
Respaldos incrementales en el horario que definas, al mismo servidor, a S3, SFTP o Google Drive, con retención aplicada después de cada corrida. La base de datos, los archivos subidos y la configuración de cada proyecto — el código vuelve desde git.
- Cada semana
Una prueba de restauración, no un mensaje de éxito
Una vez por semana el panel restaura el respaldo más reciente en una base de datos desechable y cuenta las filas. Un respaldo que en realidad no puede abrirse pone en rojo la página de Salud — porque un mensaje de éxito no es evidencia.
- Cada pocos minutos
Autorreparación para las fallas silenciosas
El watchdog reinicia un servicio que corre pero está roto — el caso que un supervisor común pasa por alto por completo, porque nada se ha caído. Cada reinicio que ejecuta aparece en el registro de actividad con su motivo.
- Al instalar y actualizar
Ajuste a la medida de la máquina
El buffer pool de la base de datos, la memoria de caché, los tamaños de tablas temporales y los workers de PHP se calculan a partir de la memoria y los núcleos reales de la máquina — una sola escalera de dimensionamiento, medida en 36 configuraciones de servidor, aplicada de forma idéntica por el instalador y por el panel.
- Cada noche
Mantenimiento de la base de datos
Un barrido nocturno elimina las filas vencidas que la aplicación misma nunca borra, y los domingos se optimizan las tablas — solo cuando el margen de disco lo permite, y con cada resultado inspeccionado en lugar de asumido.
- En cada deploy
Índices medidos, mantenidos en su lugar
Un paquete de índices de base de datos — cada uno medido en una tienda real de 66,701 pedidos antes de ser admitido — se verifica y se vuelve a aplicar después de cada cambio de código. Se verifica por lo que cada índice cubre, no por su nombre, así que un índice renombrado no puede engañarlo.
- En cada git push
Push-to-deploy, de punta a punta
Haz push a tu repositorio y la tienda se actualiza sola: pull, dependencias, migraciones de base de datos, la caché de configuración reconstruida solo donde está medido que es seguro para tu código exacto, PHP recargado sin perder una sola petición. Un botón de rollback conserva la versión anterior.
- Continuamente
Chequeos de salud que nombran la solución
Más de treinta chequeos corren con sus propios horarios — servicios, disco, certificados, DNS, Cloudflare, los propios archivos del panel contra la versión que los publicó. Una fila en falla nombra la solución exacta, no solo el problema.
- Cuando algo te necesita
Correo que respeta tu bandeja de entrada
Como máximo un correo por problema cada seis horas, con un veredicto en color legible desde la vista previa de la bandeja — y un "resuelto" en verde cuando el problema desaparece, para que el silencio nunca tenga que interpretarse.
- Cuando presionas el botón
Actualizaciones de un botón, con firma verificada
Un botón descarga la versión, verifica su firma contra la clave fijada en tu servidor — un host de descargas reemplazado no puede cambiarle la clave a tu máquina —, la aplica y reinicia los servicios en un orden medido que mantiene la tienda sirviendo.
El patrón detrás de todo esto: el panel hace el trabajo, anota lo que hizo y verifica su propio resultado — y lo que no puede verificar, lo reporta en lugar de afirmarlo.
Bajo el capó
Ingeniería avanzada que funciona sola
Nada de esto es una casilla en una lista de funciones. Cada pieza es maquinaria real con comportamiento medido, reglas de seguridad estrictas y un informe que puedes leer.
Supervisor con autorreparación
Un bucle de 60 segundos repara lo que de verdad rompe una tienda en vivo: una cola atascada, un certificado caducado, el modo mantenimiento olvidado. Con reglas estrictas: nunca arranca lo que tú detuviste y nunca actúa durante un despliegue o una copia de seguridad.
Copias incrementales y cifradas
Basado en restic: cada ejecución guarda solo lo nuevo o lo modificado desde la anterior, deduplicado y cifrado — las copias diarias siguen siendo rápidas y pequeñas y cada instantánea se restaura completa. Destinos: disco local, S3, SFTP, Google Drive.
Copias probadas, no supuestas
Un trabajo de copia en verde no es una prueba. Una verificación programada abre la instantánea más reciente y comprueba que el volcado de tu base de datos está realmente dentro: la respuesta honesta a «¿podré restaurar?» sale del artefacto, no del código de salida.
Ajustado a tu servidor, automáticamente
Una escalera de dimensionado medida calcula el buffer pool de la base de datos, la memoria de Redis y los workers de PHP a partir de la RAM y CPU de tu máquina — al instalar y de nuevo al redimensionar. El instalador y el panel comparten una única definición, sujeta por una puerta de build.
Una micro-caché probada como segura
Los endpoints calientes de la API responden desde la caché de nginx — de 16,9 ms a 0,6 ms, medido — pero solo entran endpoints probados como independientes del solicitante: una puerta estática lee los handlers de la app y una sonda en vivo de tres brazos confirma que ningún cliente puede ver jamás los datos de otro.
Cada proyecto totalmente aislado
Cada tienda tiene su propio usuario unix, su propio pool PHP-FPM y su propia instancia de Redis con contraseña; sus workers corren en un sandbox de systemd con sistema de solo lectura y sin escalada de privilegios. Un proyecto comprometido no puede leer otro.
Actualizaciones firmadas criptográficamente
Cada versión incluye un manifiesto firmado con ed25519 y fecha de caducidad. El panel rechaza cualquier cosa sin firma, caducada o firmada con la clave equivocada — y una clave rotada debe probarse contra la versión antes de recibir confianza.
Lee tu aplicación antes de actuar
El panel no afirma nada a ciegas. El cacheo de configuración se decide leyendo el propio código de tu 6amMart, así que una build que lee ajustes en tiempo de ejecución nunca se rompe en silencio. El código CodeCanyon intacto y la build optimizada reciben ambos la respuesta correcta.
Autorreparación, copias incrementales, actualizaciones firmadas — no configuras nada de esto. Es simplemente cómo está construido el panel.
Por qué se siente fácil
Lo fácil es una decisión de diseño, no una capa de pintura
Nada de esto es un modo simplificado que esconde los controles reales. Son los controles reales, organizados para que el siguiente paso siempre sea obvio.
Un solo pegado, sin prerrequisitos
Sin Docker que aprender, sin archivos compose, sin folclore de SSH. El stack son los propios paquetes de Ubuntu supervisados por systemd, y un solo comando lo instala todo.
Un asistente que sugiere sus propias respuestas
Seis pasos — básicos, contraseña, dominio, HTTPS, aplicación, respaldos. Cada paso propone la respuesta sensata; la mayor parte de la configuración es confirmar, no decidir.
Escribe un dominio, recibe el plan completo
A partir de un solo dominio, el panel planifica los hosts del dashboard, de la tienda y del websocket, los registros DNS que hay que crear y cuáles de ellos debe proxear Cloudflare. Los nombres que romperían HTTPS en silencio se rechazan junto con la forma de escribirlos que sí funciona.
Los problemas llegan con su solución adjunta
Nada de un "falló" a secas. Una fila roja te dice el ajuste, archivo o botón exacto que lo resuelve — la diferencia entre un pendiente y un misterio.
Cada acción es una tarea que puedes observar
Instalaciones, deploys, respaldos y arreglos corren como tareas con logs en vivo. Los botones muestran un indicador mientras trabajan, y una tarea se niega a reportar éxito a menos que su propia re-verificación pase.
El manual vive dentro del panel
Cada enlace de Ayuda aterriza en la página sobre lo que estás viendo. El mismo manual viene en la descarga y está publicado en este sitio.
Una línea de comandos para el mal día
Un comando sixpanel en el servidor replica el panel — con página man y autocompletado de shell — para el día en que el navegador no es una opción.
Habla tu idioma
Ocho idiomas. Llega desde este sitio y el panel se abre en el idioma que estabas leyendo; sigue un enlace de vuelta y el sitio hace lo mismo.
Las tres cosas que nadie más hace
Tres afirmaciones, cada una con la razón por la que es verdadera en lugar de un adjetivo
Nos comparamos contra un rival completamente ajustado, y publicamos de dónde viene la victoria
Cualquiera puede publicar un benchmark que ganaron. La prueba que vale la pena ejecutar es la que el otro lado se configura correctamente — así que la caja de aaPanel fue ajustada primero: caché de código compilado duplicada, pool de buffer de base de datos cuatro y media veces más grande, workers corregidos de un over-committed 50 a un dimensionado 14. Su PHP 8.4 y su compilador JIT se dejaron deliberadamente encendidos, porque esas son sus ventajas.
La brecha no se cerró. 1.65× / 1.80× contra la caja como se envía; 1.76× / 1.82× contra la ajustada. Se movió ligeramente en la otra dirección.
Luego la diferencia se desmontó una variable a la vez. Alrededor del 60% es una única restricción de directorio PHP, alrededor del 8% es el modo compilador JIT incorrecto, y la versión de PHP vale exactamente nada. Alrededor del 32% aún está sin explicar, y se publica como sin explicar en lugar de acreditado a nosotros.
Por qué esto cuenta: Una razón sin causa detrás es un número de marketing. Esta tiene una causa medida para dos tercios de sí misma y una admisión para el resto.
Medimos tres sistemas operativos, dio empate, y publicamos el empate
Tres servidores de un proveedor, ordenados juntos, idénticos excepto el sistema operativo. Mismo software, mismo ajuste, mismos datos — una base de datos de tienda real con 66,701 órdenes. Esta ronda pregunta cuál sistema operativo, no cuál runtime; se ejecutó en el runtime de contenedor.
Empataron. La diferencia entre las tres máquinas (3,5 %) fue menor que la diferencia que una de ellas tuvo consigo misma entre dos ejecuciones de su propia configuración (8,6 %).
Así que la recomendación se decidió por cuánto tiempo sigue recibiendo actualizaciones de seguridad cada sistema, no por velocidad. Y el informe descartó sus propias filas más halagüeñas porque eran aritméticamente imposibles.
Por qué esto cuenta: La disposición a publicar un resultado negativo es la prueba de que el método es real. Cualquiera puede publicar un benchmark que ganó.
Caché y límites moldeados según los patrones de petición del propio 6amMart
La micro-caché de nginx está al alcance de cualquiera. Lo específico aquí es todo lo que la rodea, y nada de eso lo puede escribir alguien que no conoce esta aplicación:
- La lista blanca de exactamente qué endpoints públicos se pueden cachear, comparada sobre la URI cruda, con denegación por defecto.
- La zona, el módulo y el idioma en la clave de caché, porque 6amMart sirve tiendas distintas a ciudades distintas desde la misma URL.
- Cinco reglas de excepción que hacen imposible cachear una respuesta personalizada.
- Niveles de límite de peticiones que separan el login y el OTP de la navegación, de la búsqueda y de las escrituras del carrito.
- Tiempos de espera fijados a propósito unos con otros — PHP 120 s, lectura de nginx 120 s, terminación del worker 130 s — porque 6amMart corre exportaciones a Excel, importaciones masivas e informes pesados de tienda dentro de la petición web en vez de en segundo plano.
Por qué esto cuenta: Una inundación de búsquedas sin autenticación podía llenar el servidor de caché y empezar a expulsar sesiones, cerrando la sesión de compradores conectados en silencio. Hacían falta unas 278 peticiones, alrededor de 67 segundos en una sola conexión, en una máquina de prueba de 8 GB con dos proyectos. Eso se midió, se acotó, y se volvió a medir en la misma máquina — en las tres inundaciones que tabula el archivo de evidencia, cero expulsiones y la sesión viva todas las veces.
SixPanel comparado
SixPanel comparado con aaPanel, CloudPanel y hacerlo a mano
Esta es una comparación para un solo trabajo: hacer funcionar una tienda 6amMart. No es una comparación de estos paneles en general, y sería deshonesto presentarla como tal.
Exactamente qué tenemos sobre los dos competidores, dicho con precisión
La tabla tiene 14 filas y dos columnas de competidores, así 28 celdas de competidores. Cuatro de esos 28 dicen algo diferente de "no hemos probado esto", y aquí está cada uno:
- Una celda registra algo que vimos hacer a un producto competidor. aaPanel revierte silenciosamente la raíz del documento siempre que se guarda cualquier configuración del sitio — registrado en una instalación en vivo. Esa es la fila de Raíz del documento, columna aaPanel.
- Dos celdas se apoyan en el comportamiento de un tercero que verificamos, no en probar los paneles. Ni el archivo de Ubuntu 26.04 ni el de Debian 13 traen MariaDB 10.11, y ambos paneles instalan la base de datos desde los paquetes del host — así que en esos releases no pueden suministrar esa versión. El runtime nativo de SixPanel toma 11.8 del mismo archivo en su lugar, y SixPanel Docker lleva 10.11 en su imagen. Esa es la fila de MariaDB 10.11, en ambas columnas de competidores.
- Una celda reporta nuestra propia medición de un competidor. aaPanel se instaló en hardware idéntico con los datos de la misma tienda, ajustada por nosotros primero, y medida — esa es la fila de Velocidad, columna aaPanel, y el método completo está arriba. CloudPanel no se midió, así que su celda lo dice.
- Las restantes 24 celdas de competidores todos dicen "no probado por nosotros". Esa es la redacción literal, en cada una de ellas — contada, no asumida.
No afirmamos nada sobre la antigüedad de ninguno de los dos competidores. Ninguna fuente de este conjunto establece la edad de ninguno de los dos productos, así que no aparece ninguna afirmación de ese tipo. Lo único que la fila de Trayectoria puede decir con honestidad es lo que sabemos sobre nuestra propia antigüedad.
Ahora hemos comparado SixPanel contra aaPanel — hardware idéntico, los datos de la misma tienda, y aaPanel ajustado antes de que los números se tomaran. El método y cada figura están arriba. CloudPanel no se midió en absoluto, y ninguna afirmación de velocidad sobre él aparece en ningún lugar de esta página.
| Para el trabajo de hacer funcionar 6amMart | SixPanel | aaPanel | CloudPanel | Servidor común, a mano |
|---|---|---|---|---|
| Para qué se construyó | Una aplicación solamente — 6amMart | Hosting web de propósito general — no probado por nosotros; lee tu propia lista de características del proveedor | Hosting web de propósito general — no probado por nosotros; lee tu propia lista de características del proveedor | Lo que construyas |
| Velocidad, mismo hardware e igual tienda | Medido: 1.76× más rápido que un aaPanel completamente ajustado en una solicitud, 1.82× con cuatro a la vez, en los endpoints que alcanzan PHP en ambos | La comparación anterior. Lo instalamos, lo ajustamos, y dejamos su PHP 8.4 y su JIT en su lugar | No probado por nosotros — ninguna afirmación de velocidad se hace sobre él | Lo que tu ingeniero logre |
| MariaDB 10.11 en Ubuntu 26.04 / Debian 13 | Con el runtime Docker, sí — la imagen está fijada en 10.11 sea cual sea el host. El runtime nativo toma MariaDB 11.8 de los propios archivos de esos releases en su lugar, y medido frente a 10.11 en la misma tienda eso es un empate. | No disponible. Ninguno de los dos releases trae 10.11 en su archivo, y este panel instala desde los paquetes del host | No disponible — misma razón | Solo si ejecutas contenedores tú mismo |
| Otros sitios web, correo, DNS, FTP en la misma caja | No. El instalador rechaza un servidor que ya ejecuta aaPanel, CloudPanel, cPanel o Plesk, o tiene algo en los puertos 80/443 | Ganan aquí. Para eso son los paneles generales — no probado por nosotros; verifica el proveedor | Ganan aquí — no probado por nosotros; verifica el proveedor | Posible, y completamente tu problema |
| Usuarios, roles, equipos | No. Una cuenta de administrador. Más logins temporales y un login de demostración de solo lectura | Ganan aquí. No probado por nosotros; verifica el proveedor | Ganan aquí. No probado por nosotros; verifica el proveedor | Lo que configures |
| Ajustado para esta aplicación fuera de la caja | El ajuste automático escribe workers PHP, pool de buffer de base de datos, memoria de caché, tablas temporales, buffers y el redo log desde la máquina real, 1 núcleo / 2 GB → 16 núcleos / 32 GB — y los dos lugares que lo calculan se verifican uno contra el otro en cada build | No probado por nosotros; verifica el proveedor | No probado por nosotros; verifica el proveedor | Lo que sepas |
| Micro-caché moldeado para 6amMart | Construido: allowlist, zona/módulo/idioma en la clave, 5 bypasses, servicio obsoleto cuando PHP se atasca | El micro-caching de nginx está disponible en cualquier lugar — alguien tiene que escribir las reglas específicas de 6amMart. No probado por nosotros | Lo mismo. No probado por nosotros | Lo mismo |
| Backups | restic, programado, retención, cuatro destinos, prueba de restauración automática semanal | No probado por nosotros — compara la prueba de restauración automática específicamente | No probado por nosotros — lo mismo | Lo que escribas |
| HTTPS Gratis | Sí, con renovación automática e issuance consciente de Cloudflare | No probado por nosotros; verifica el proveedor | No probado por nosotros; verifica el proveedor | certbot, por ti |
| Despliegues | Push a git; historial y rollback con los últimos 30 despliegues guardados; rechaza sobrescribir tus ediciones | No probado por nosotros; verifica el proveedor | No probado por nosotros; verifica el proveedor | Lo que escribas |
| Document root stays where you put it | Yes | Registrado en una instalación real: aaPanel revierte en silencio el directorio raíz cada vez que se guarda cualquier ajuste del sitio | Not tested by us | Yours to get right |
| Track record | SixPanel está en su versión actual, y es nuevo. No podemos enseñarte años que no hemos tenido | No probado por nosotros; comprueba cuánto tiempo lleva publicando el fabricante | No probado por nosotros; comprueba cuánto tiempo lleva publicando el fabricante | Linux is 30+ years old |
| Código fuente legible en tu servidor | Podrían ganar aquí. El backend del panel se envía como bytecode V8 con los fuentes legibles removidos. Lo llamamos disuasión, no seguridad | No probado por nosotros; verifica el proveedor | No probado por nosotros; verifica el proveedor | Todo es legible |
| Quién lo arregla cuando se rompe | La página de salud nombra el fix; bundle de soporte en una orden | No probado por nosotros; verifica qué soporte ofrece el proveedor | No probado por nosotros; verifica qué soporte ofrece el proveedor | Tú |
No hay fila de precio porque no hay precio. SixPanel es gratuito, se publica en CodeCanyon y el comando de instalación es el mismo comando público para todo el mundo — sin clave que introducir, sin código que pegar, sin registrarse en nada. La primera instalación y configuración también es gratis. Las actualizaciones llegan por CodeCanyon, y el panel también puede actualizarse a sí mismo.
Cuándo aaPanel o CloudPanel es la mejor opción
Cinco casos reales. Si alguno eres tú, compra el panel general y no compres este:
- 1Quieres más de un sitio web en ese servidor. SixPanel toma la máquina completa y se niega a compartirla.
- 2Necesitas correo, DNS o FTP en la misma máquina. SixPanel no hace nada de eso.
- 3Necesitas varias cuentas de personal con permisos distintos. SixPanel tiene una cuenta de administrador y no tiene roles.
- 4Estás corriendo algo que no es 6amMart. Cada ventaja de esta página viene de conocer bien una sola aplicación.
- 5Una trayectoria larga en producción es tu primer criterio. SixPanel es nuevo. Esa es una razón justa para esperar.
Y una para hacerlo a mano: si tienes un sysadmin, un servidor armado a mano no es peor. Un ingeniero competente puede afinar MariaDB, escribir reglas de caché y programar respaldos. Lo que SixPanel elimina es la necesidad de tener a esa persona, y la de acordarse de volver a revisar todo eso.
Sistema operativo
Qué sistema operativo instalar, y por qué la razón es el margen de soporte y no la velocidad
Ambos runtimes recomiendan Ubuntu 26.04 LTS. Ubuntu 24.04 LTS y Debian 13 son los otros dos releases soportados.
No porque sea más rápido. Se midieron seis ejes en hardware idéntico — el sistema operativo, PHP, MariaDB, nginx, Redis y el kernel — y ningún cambio de versión produjo una diferencia reportable. Dos máquinas idénticas byte a byte discreparon entre sí en un 11,6 % en 20 de 20 filas, así que el suelo de ruido es mayor que cualquier efecto encontrado.
El runtime nativo toma PHP, MariaDB, nginx y Redis del propio archivo de la distribución del release, y los tres releases soportados traen un conjunto que funciona: Ubuntu 26.04 da PHP 8.5 y MariaDB 11.8, Debian 13 da 8.4 y 11.8, Ubuntu 24.04 da 8.3 y 10.11. Con la velocidad empatada, el único eje que queda es cuánto tiempo siguen llegando las actualizaciones de seguridad — y 26.04 recibe parches hasta abril de 2031.
SixPreflight recomienda Ubuntu 26.04 LTS, por la misma razón que el runtime nativo.
| Elección | SixPanel / SixPanel Docker | SixPreflight |
|---|---|---|
| Recomendado | Ubuntu 26.04 LTS, en ambos runtimes | Ubuntu 26.04 LTS |
| También compatible | Ambos runtimes: Ubuntu 24.04 LTS y Debian 13. El runtime Docker además se instala en Debian 12, que el nativo rechaza por nombre | Ubuntu 24.04 LTS, Debian 13 |
| Por qué | La velocidad está empatada en los tres, así que lo que decide es el margen de soporte: 26.04 recibe parches hasta abril de 2031. El runtime nativo toma PHP y MariaDB del release que elijas. | La misma razón: la base de datos viene del sistema operativo, cada release soportado trae una versión que funciona, y lo que queda por decidir es el margen. |
Soportado no es lo mismo que medido. El runtime nativo soporta tres releases, y los tres se midieron — Ubuntu 24.04, Ubuntu 26.04 y Debian 13. Debian 12 se rechaza por nombre: su soporte de seguridad gratuito terminó en julio de 2026. El runtime Docker sigue instalándose en él, y aun así no deberías arrancar una tienda nueva ahí, porque el kernel, glibc, Docker y OpenSSH vienen del archivo del host sin importar qué corra dentro de un contenedor.
Por qué ahora todo apunta en la misma dirección
Una ronda anterior de motores de base de datos puso a MariaDB 10.11 en primer lugar, y durante un tiempo eso dividió la recomendación, porque solo Ubuntu 24.04 la traía. Medido de nuevo en máquinas idénticas con la misma tienda de 66.701 pedidos, esa división ha desaparecido.
MariaDB 11.8 frente a 10.11 en toda la aplicación es un empate. Las mediciones que sugerían lo contrario se descartaron, porque el arnés estaba midiendo un saludo cifrado y no la base de datos.
El único sitio donde 11.8 parecía más lenta no hace ningún trabajo.
Era SELECT 1 — una consulta que no hace ningún trabajo, y que dio 12 ms en un brazo frente a 29 ms y 37 ms en los otros dos. Un suelo que se triplica no es ejecución de consultas: MariaDB 11.8 negocia TLS en el socket unix y 10.11 no, así que la sonda medía un saludo cifrado. Medido directamente: 24 ms por llamada de cliente en 11.8 frente a 6 ms con TLS desactivado y 10 ms en 10.11. Una tienda nunca lo paga — mysqlnd no negocia TLS en un socket, 0,12 a 0,21 ms por conexión.
La vieja cifra de «11.x es 2,7× más lenta» nunca fue sobre 11.8.
Venía de una sola consulta de informe sobre el modelo de costes de MariaDB 11.0, y se retira como afirmación sobre toda la aplicación. Así que ya nada justifica fijar un release más viejo: el runtime nativo toma 11.8 de los propios archivos de Ubuntu 26.04 y Debian 13, y 10.11 del de Ubuntu 24.04.
Una sola respuesta, y no es una respuesta de velocidad. Toma el release que sigue recibiendo parches durante más tiempo.
Cómo se midió
- Medido el 15 de agosto de 2026, sobre la compilación de la pila vigente ese día. SixPanel ha publicado versiones desde entonces, y nada de esta sección se ha vuelto a ejecutar sobre la actual. La fecha es lo que fija la medición.
- Tres servidores del mismo proveedor, pedidos juntos, idénticos salvo el sistema operativo — que son todos los releases que soporta el runtime nativo.
- El mismo procesador en los tres: 2 × AMD EPYC 7713, 2 núcleos. RAM 3.915 / 3.910 / 3.921 MB. Disco 79 GB cada uno.
- El software era idéntico byte a byte en los tres — MariaDB 10.11, la misma compilación de PHP, el mismo servidor web. Esta ronda se corrió en el runtime de contenedores, que es lo que lo hizo posible: mantiene el stack quieto para que el sistema operativo sea lo único que cambia.
- Datos reales, no un banco de pruebas. La base de datos de una tienda en producción: un volcado de 410 MB que restaura a 515 MB, 66.701 pedidos, más 894 MB de archivos subidos reales.
- Una instalación limpia de SixPanel en cada máquina, por el camino normal del cliente. Sin ajuste manual — autotune eligió todos los valores, y eligió los mismos en las tres.
- Calentado y luego medido. Las muestras de calentamiento se descartan; la que se publica es la segunda ejecución.
- Percentiles, not averages.
Peticiones por segundo — el endpoint de búsqueda, 20 personas a la vez, 30 segundos
Este es el número en el que confiar.
| Sistema operativo | Peticiones completadas | Peticiones por segundo |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
Diferencia entre los tres: 3.5 %. La máquina con Ubuntu 26.04 no coincidió consigo misma por 8.6 % entre dos corridas de su propia configuración idéntica — 49.6, y después 53.9.
Nota aritmética, porque una página que hace virtud de atrapar números imposibles no puede imprimir porcentajes a los que un lector no puede llegar desde los conteos que están al lado. El informe interno imprime la diferencia como 3.7 % y la variación consigo misma como 8.7 %. Los dos están redondeados hacia arriba, así que esta página imprime en su lugar el recálculo truncado: (1,616 − 1,561) ÷ 1,561 = 3.5234 % → 3.5 %, y (53.9 − 49.6) ÷ 49.6 = 8.6694 % → 8.6 %. El hallazgo no cambia — la diferencia entre máquinas sigue siendo menor que la diferencia de una máquina consigo misma. La columna de peticiones por segundo de arriba es el redondeo a 1 decimal de la propia fuente: 1,616 ÷ 30 = 53.8666 y 1,595 ÷ 30 = 53.1666 truncan a 53.8 y 53.1, y solo 52.0 ya está truncado. La columna se deja como la imprime la fuente para poder poner los dos archivos lado a lado; los porcentajes son de esta página, y son los números que se citan.
Lee todo el bloque como “unas 53 peticiones por segundo en 2 núcleos, en el endpoint de búsqueda, con 20 usuarios concurrentes, durante 30 segundos” — y nada más. Cada uno de esos matices viaja con la cifra donde sea que se repita en esta página.
Latencia en reposo — registrada, y deliberadamente no impresa
La latencia en serie se midió en cada rama: portada de la tienda web, login del admin y los endpoints de la API, una petición a la vez en una máquina en reposo.
Esos números celda por celda no están en esta página, y esta es la razón. El informe interno prohíbe cualquier cifra de “X % más rápido” sacada de esas tablas. Una tabla de tres columnas con valores en milisegundos es esa cifra a una resta de distancia: cualquier lector con una calculadora, y cualquier resumidor de IA sin ella, va a producir la comparación que el informe descarta. Imprimir la tabla y agregar “pero no compares esto” no funciona, porque una cita se queda con los números y deja fuera la salvedad.
- Las tres máquinas empataron en el número que importa, y una máquina no coincidió consigo misma por más de lo que las tres no coincidieron entre sí.
- Sí apareció una diferencia pequeña y constante en la latencia en serie en reposo de una de las ramas. Está registrada en el informe interno y deliberadamente no se afirma, por tres razones que ahí se explican: es un costo más o menos fijo y no proporcional, que es la firma de una espera y no de trabajo; desaparece por completo bajo carga, que es justo donde importaría; y con una sola máquina por sistema operativo, no se pueden separar la versión del kernel y ese host físico en particular.
- Las filas de percentiles bajo carga de dos ramas se descartaron por completo.
Se descartaron filas, y que se hayan descartado importa
Los percentiles bajo carga de la rama de Ubuntu 26.04 son aritméticamente imposibles. Veinte workers durante 30 segundos son 600 worker-segundos, así que 1,616 peticiones completadas dan una media aritmética de 371 ms. Esa rama reportó tanto su p50 como su p99 por debajo de esa media — un p99 más rápido que la petición promedio. Sus dos corridas lo muestran, así que es sistemático de esa máquina, no una muestra suelta.
Tomadas al pie de la letra, esas filas harían ver a esa máquina dramáticamente mejor bajo carga. No lo es — su conteo de peticiones completadas está dentro del 3.5 % de las otras. Los dos valores de percentil en sí no se imprimen en esta página: el informe interno descarta como clase las cifras de latencia bajo carga de Ubuntu 26.04. La aritmética de arriba alcanza para mostrar por qué se descartaron, y el descarte es el punto.
El arnés de pruebas ahora lleva una verificación cruzada basada en la ley de Little, así que una muestra echada a perder se delata sola en vez de convertirse en un titular.
La base de datos, sobre el conjunto de datos real de 515 MB
Lee la salvedad antes que los números. Cada diferencia entre máquinas de esta tabla cae dentro del propio rango entre corridas de Ubuntu 24.04, de 85–125 ms en las mismas tres consultas. Las columnas no son un ranking; son tres muestras de un mismo número. El hallazgo real es la última fila.
| Consulta | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| Contar todos los pedidos | 120 ms | 96 ms | 106 ms |
| Contar todas las líneas de pedido | 102 ms | 102 ms | 110 ms |
| Pedidos unidos a líneas de pedido, 50 filas | 85 ms | 80 ms | 81 ms |
| Tasa de acierto del buffer pool | 99.991 % | 99.989 % | 99.987 % |
La última fila es el hallazgo: una base de datos de 515 MB dentro de un buffer pool de 1,024 MB significa que alrededor del 99.99 % de las lecturas se responden desde memoria, y esta carga de trabajo deja de leer el disco una vez que está caliente.
Cuánto tardó la instalación
| Sistema operativo | Instalación desatendida | Problemas |
|---|---|---|
| Ubuntu 24.04 | 303 s | ninguno |
| Ubuntu 26.04 | 281 s | ninguno |
| Debian 13 | 273 s | git falta en la imagen mínima, lo que rompió el clonado por completo — encontrado aquí, corregido aquí |
303 s son cinco minutos y tres segundos, y por eso esta página dice “unos cinco minutos” y no “menos de cinco minutos”.
Por qué abril de 2031 lo decidió
Con la velocidad empatada, lo que decide es cuánto tiempo sigue recibiendo actualizaciones de seguridad cada sistema. Que un sistema operativo se quede sin soporte es el único evento que obliga a reconstruir el servidor entero — y reconstruir el servidor es justamente lo único que SixPanel no puede hacer por su dueño.
| Sistema operativo | Soporte de seguridad gratuito hasta | Tiempo restante desde agosto de 2026 |
|---|---|---|
| Ubuntu 26.04 LTS | abril de 2031 | 4 años 8 meses |
| Ubuntu 24.04 LTS | Mayo de 2029 | 2 años 8 meses |
| Debian 13 | Agosto de 2028, después LTS de la comunidad | alrededor de 1 año 10 meses |
| Debian 12 — solo runtime de contenedores, no recomendado | terminó en julio de 2026 | vencido |
MariaDB 10.11 en sí se agota alrededor de febrero de 2028. En el runtime de contenedores eso es un pin de imagen y una decisión aparte; en el nativo solo afecta a Ubuntu 24.04, ya que 26.04 y Debian 13 toman 11.8 de sus propios archivos. En cualquier caso, es justamente por eso que el sistema operativo del host debería ser el que menos a menudo necesite reemplazo.
Si tu empresa de hosting todavía no ofrece Ubuntu 26.04, toma Ubuntu 24.04. Está totalmente soportado y no pierdes nada que se pueda medir.
Se puede afirmar sin riesgo, y esta página lo hace
- SixPanel corre el stack completo de 6amMart en Ubuntu 26.04, Ubuntu 24.04 y Debian 13 — los tres que se midieron — verificado con datos reales de producción.
- Cada release soportado trae en su propio archivo una base de datos que funciona — MariaDB 11.8 en Ubuntu 26.04 y Debian 13, 10.11 en Ubuntu 24.04 — y medido en la misma tienda, 11.8 frente a 10.11 es un empate. El runtime de contenedores fija 10.11 en su imagen si quieres esa versión en concreto.
- Se recomienda Ubuntu 26.04 LTS, y recibe actualizaciones de seguridad hasta abril de 2031.
- Un servidor de 2 núcleos / 4 GB sirvió unas 53 peticiones por segundo en el endpoint de búsqueda, con 20 usuarios concurrentes, durante 30 segundos, sobre un catálogo de tamaño real con 66,701 pedidos, con la base de datos respondiendo el 99.99 % de las lecturas desde memoria.
- Una instalación nueva se completa sin supervisión en unos cinco minutos (273–303 s medidos; el más lento de los tres, 303 s, es la cifra sobre la que está escrito el texto).
No respaldado por las mediciones, y esta página no lo dice
- Que alguno de estos sistemas operativos sea más rápido que otro. Las diferencias medidas son menores que el ruido de una sola máquina.
- Cualquier cifra de porcentaje más rápido derivada de las tablas internas de latencia. La diferencia entre máquinas es de 3.5 % contra 8.6 % de variación consigo misma — por eso no aparece ninguna tabla de latencia celda por celda.
- Las cifras de latencia bajo carga de Ubuntu 26.04. Son aritméticamente imposibles y se excluyeron.
- Nada sobre la velocidad del disco. Esa columna refleja en qué máquina física cayó cada servidor, no el sistema operativo — y de todos modos no aportó nada, porque la base de datos responde el 99.99 % de las lecturas desde memoria y deja de tocar el disco una vez caliente.
- Cualquier cifra general del tipo “6amMart es así de rápido”. 53 peticiones por segundo describe un endpoint, sobre estos datos, en 2 núcleos, con 20 usuarios concurrentes durante 30 segundos.
- Nada sobre servidores de 8 GB o más. En esta ronda solo se midieron máquinas de 4 GB.
- Nada sobre la velocidad de Debian 12. El runtime nativo lo rechaza por nombre, y nunca se midió.
Qué rompió la ronda, y nosotros corregimos
Tres defectos reales salieron a la luz solo porque la medición se corrió en servidores reales con datos reales. Estos son los tres que registra la fuente — la lista está completa, no es una selección.
- 1El instalador falló en Debian 13. La imagen mínima no trae git, así que el clonado se rompió por completo. Corregido.
- 2El arnés de pruebas no estaba midiendo nada en las filas de la API. Sus cabeceras de petición se estaban partiendo, así que cada fila de la API imprimía cero muestras — en silencio, en las tres máquinas. Corregido, y ahora una corrida que no recoge muestras lo dice fuerte en vez de imprimir un resultado silencioso.
- 3Dos scripts no coincidían en el límite de memoria de PHP, mientras un comentario afirmaba que las fórmulas coincidían exactamente. Corregido.
Esta sección se queda en la página. Es la prueba de que la medición fue real.
Qué necesitas
Qué necesitas, y cuánto lleva de verdad una instalación nueva
| Requisito | Detalle |
|---|---|
| Sistema operativo | Ubuntu 26.04 (recomendado), Ubuntu 24.04 o Debian 13 — exactamente tres. Nada más: los releases más viejos, incluido Debian 12, y cualquier otra distribución se rechazan por nombre antes de descargar nada. El soporte de seguridad gratuito de Debian 12 terminó en julio de 2026; el runtime de contenedores sigue instalándose en él, pero una tienda nueva no debería empezar ahí. |
| Tipo de procesador | x86_64, o arm64 (también escrito aarch64). |
| Núcleos de CPU | 2 núcleos es el tamaño cómodo para una tienda. Autotune soporta desde 1 núcleo hasta 16 núcleos. |
| RAM | 2 GB es el mínimo práctico. El instalador rechaza por debajo de unos 1.2 GB y advierte por debajo de 2 GB. 4 GB es el tamaño cómodo para una tienda. |
| Disco | No es uno de los filtros del instalador. Las tres máquinas medidas tenían 79 GB cada una. El panel rechaza una subida que dejaría menos espacio libre que el menor entre 2 GB y el 10 % del disco. Para una instalación de 6amMart nativa (sin contenedores), SixPreflight pide 20 GB libres y prefiere 40 GB. |
| Estado del servidor | Nuevo. Sin aaPanel, CloudPanel, cPanel ni Plesk. Nada escuchando ya en los puertos 80 o 443. |
| Puertos abiertos en tu proveedor | Exactamente tres: el puerto de tu panel (un número alto aleatorio elegido en la instalación), 80 y 443. Nada más, nunca. |
| Acceso | El acceso root del servidor. El instalador se niega a correr como cualquier otro usuario. |
| Tu código | Tu código de 6amMart en un repositorio git privado. SixPanel instala desde git, no desde un zip. |
| Tu teléfono | Una app de autenticación. El acceso de dos factores es obligatorio para la cuenta del dueño y no se puede apagar. |
| Un dominio | Y poder editar sus registros DNS. |
| Una segunda tienda | Unos 2 GB más de RAM y 1–2 núcleos más por cada tienda extra. Planifica el tope de ese rango — 2 núcleos — que es el extremo conservador. |
| Lo que cuesta | Nada. SixPanel es gratuito y está publicado en CodeCanyon, y la primera instalación y configuración también es gratis. No hay servidor de licencias, ni clave que renovar, ni código de compra en el comando de instalación. |
Lo que SixPanel instala: nginx, PHP-FPM, MariaDB, Redis y un servicio de panel Node.js, todos supervisados por systemd y todos desde el propio archivo de la distribución del release — PHP 8.5 con MariaDB 11.8 en Ubuntu 26.04, 8.4 con 11.8 en Debian 13, 8.3 con 10.11 en Ubuntu 24.04. El runtime Docker instala el mismo stack como contenedores, fijado en PHP 8.4 y MariaDB 10.11. Idiomas de interfaz del panel: 8 — inglés, español, árabe, portugués, francés, alemán, indonesio, bengalí.
Cuánto lleva de verdad una instalación nueva — la línea de tiempo honesta
“Cinco minutos” es el comando de instalación, no el trabajo. El comando de instalación son unos cinco minutos. Ir de un servidor alquilado a una tienda en vivo es alrededor de una hora.
| Paso | Tiempo |
|---|---|
| Poner tu código en un repositorio git privado (una vez, en tu propia computadora) | unos 20 minutos si nunca has usado git |
| Actualizar el servidor y agregar tres herramientas pequeñas | un minuto o dos |
| Correr el comando de instalación — revisa el sistema, instala Docker, verifica la firma, descarga y comprueba los archivos, genera contraseñas, elige un puerto de panel aleatorio, dimensiona todo para la máquina, y después compila y arranca | 273–303 segundos medidos en tres sistemas operativos — unos cinco minutos |
| Abrir los tres puertos en el panel de tu proveedor de hosting | unos minutos |
| Primer inicio de sesión, y configurar los dos factores en tu teléfono | unos minutos |
| Apuntar el dominio y obtener el certificado gratuito | menos de un minuto una vez que el DNS se propagó — crea el registro DNS temprano |
| Instalar tu código de 6amMart desde git | unos minutos |
| Total para un primer servidor | Reserva una hora. Probablemente termines antes. |
Lo que el instalador imprime al final, y lo que tienes que guardar de inmediato: la URL completa del panel, el usuario y la contraseña. La contraseña se muestra una sola vez y se guarda solo como hash — no se puede volver a leer.
La falla más común no es la instalación. Es que el puerto del panel no esté abierto en el proveedor de hosting.
Seguridad
Seguridad — solo lo que se puede demostrar
Cada punto de aquí se puede comprobar en el producto. Nada de esto es una afirmación de seguridad general. Los huecos en esta área están en la lista de límites honestos de más abajo, no escondidos.
Llegar siquiera al panel
- El panel solo responde bajo una dirección secreta. Todo lo demás devuelve una página en blanco de “no encontrado”, así que un escáner de puertos no puede distinguir el panel de un puerto cerrado. El puerto del panel en sí es un número alto aleatorio elegido en la instalación, distinto en cada servidor.
- La dirección secreta es una puerta delante del login, no un reemplazo — el usuario, la contraseña y el código de dos factores siguen corriendo detrás de ella.
- Un código de entrada incorrecto se compara en tiempo constante, y se responde con el mismo “no encontrado” en blanco que cualquier otra cosa, tras una demora fija de 200 ms. Cuenta para un bloqueo por dirección. La demora tiene un tope de 32 fallos en curso; pasado ese tope, el “no encontrado” vuelve de inmediato. Así que un código incorrecto cuesta lo mismo que cualquier otra cosa hasta ese tope, no siempre — de todos modos, 20 códigos incorrectos en 15 minutos bloquean la dirección por 30 minutos.
- En una instalación nueva el nombre de usuario se genera — admin más cuatro caracteres al azar, por ejemplo admin7f3q — así que un robot que encuentra una página de login no tiene un nombre al que apuntar. Una instalación que ya traía un hash de contraseña conserva el nombre simple admin.
- Bloqueo opcional por dominio del panel. Cuando hay un dominio de panel configurado, incluso una petición directa a la dirección IP del servidor recibe el mismo “no encontrado” en blanco. La forma de volver a entrar es por SSH.
Iniciar sesión
- Hash de contraseña (bcrypt), una cookie de sesión firmada, y códigos de dos factores que no se pueden apagar en la cuenta del dueño.
- Un bloqueo que sobrevive a un reinicio: 20 contraseñas fallidas en 15 minutos bloquean esa dirección por 30 minutos. Cinco códigos de dos factores incorrectos hacen lo mismo.
- Una lista blanca de IP opcional en el formulario de login — y guardar una lista que no contiene tu propia dirección se rechaza, así que no te puedes dejar fuera.
Lo que el panel se niega a hacer
- Denegación por defecto en todas las rutas, más una comprobación anti-falsificación en cada cambio. El webhook de despliegue es la única excepción y en su lugar se acredita con una firma sobre el cuerpo original de la petición. Las entregas duplicadas y las de más de cinco minutos se ignoran, y cada rechazo se escribe en el registro de actividad.
- El gestor de archivos no puede alcanzar el stack. Está cercado a dos carpetas — tu código de administrador y tu código de tienda — con tanto una verificación de prefijo como una verificación de ruta real. La carpeta del panel en sí, la carpeta de datos y el archivo de configuración son inalcanzables desde esa API. Esto se afirma como un límite de seguridad, no una preferencia de diseño.
- Las decisiones de confianza usan el par de red real, nunca una cabecera que el cliente pueda escribir.
- El enrutado distingue mayúsculas y minúsculas desde antes del primer middleware, lo que cerró una elusión real en la que una ruta escrita con otras mayúsculas se colaba por delante de una comprobación de autenticación sensible a ellas.
Secretos
- El archivo de estado del panel es solo del propietario (0600) dentro de una carpeta solo del propietario. El archivo de ajustes de la pila es 0600. El socket de la línea de comandos es un socket Unix solo del propietario — solo root por permisos de archivo, nunca expuesto por red.
- La contraseña de primer arranque es hasheada, luego en blanco del archivo de configuración y removida del entorno de proceso, así que no puede leerse después.
- Una instalación por asistente dejaba antes el archivo de ajustes de la aplicación legible por todo el mundo, hablando con una caché sin protección. Eso está corregido — cada instalación, actualización, vuelta atrás y traslado vuelve a fijar las claves de infraestructura y a bloquear el archivo a 0600.
- Las contraseñas SSH usadas en un traslado nunca aparecen en la lista de procesos. Se pasan por el entorno y se borran de cada línea de registro.
- El paquete de soporte se filtra antes de escribirse — los ajustes se reducen a nombres de clave, el archivo de estado del panel no se recoge en absoluto, y el código secreto de acceso y los valores con forma de contraseña quedan enmascarados.
Manteniendo una tienda fuera de los datos de otra tienda
- Cada proyecto corre como su propio usuario unix, con una carpeta de aplicación 0700 y un archivo de configuración 0600. La barrera es el kernel rechazando un usuario diferente — no un check dentro de PHP, que un bug de PHP puede eludir.
- Cada proyecto también obtiene su propio usuario de base de datos con grants limitado a su propio schema, su propio pool de workers PHP en su propio socket, y su propia instancia de caché con su propia contraseña y su propio límite de memoria.
- Esto fue probado atacándolo en lugar de afirmarlo. Cada lectura entre proyectos fue realmente intentada desde dentro de un PHP del proyecto, en este panel y en aaPanel. Todas fallaron en ambos — pero donde los dos se superponen se separan: un archivo privado que otro sitio había escrito en el directorio temporal compartido era legible en aaPanel y rechazado aquí.
- PHP está además confinado por un namespace de montaje del kernel. Cerró el directorio temporal compartido (57 entradas visibles hasta 0), el código del propio panel, la configuración del sitio de cada proyecto — lo que significa cada dominio en la máquina — y la lista de procesos visible (138 hasta 6). Costo medido: ninguno. 217 búsquedas de sistema de archivos por request antes, 217 después.
- Dos propuestas adicionales fueron rechazadas por medición en lugar de enviadas: ocultar la configuración del servidor web no cerró nada y rompió la herramienta de check-up, que la lee, y bloquear el directorio del panel en su totalidad habría derribado la herramienta de administración de base de datos con él.
- El problema de caché compartida única que esto reemplazó fue real, y se describe en su totalidad en la sección de testing abajo en lugar de ser dejado fuera.
Versiones — y el único camino de actualización que no está verificado
- Los artefactos de cada versión están firmados, y la clave de firma está fuera de línea. El Settings → self-update del panel comprueba la firma contra una clave fijada en tu servidor, rechaza un número de build igual o menor al instalado, y comprueba el hash del archivo.
- El comando de instalación se descarga y se comprueba contra una huella publicada antes de ejecutarse. Si el archivo descargado no coincide, el comando se detiene y no se instala nada.
- Así que dos de las tres vías de actualización están verificadas por firma: la autoactualización en Ajustes → del panel, y el comando de instalación.
- El instalador mismo es verificado, no solo el release que aplica. Tu servidor lee un registro publicado de la huella digital del instalador, verifica el archivo contra él, y rechaza ejecutar cualquier cosa que no coincida — así que un servidor de actualización reemplazado o en proxy no puede entregarle a tu servidor un instalador modificado.
- Una nueva clave de firma se adopta solo cuando la clave ya fijada en tu servidor la ha firmado a sí misma — nunca porque el servicio de actualización lo dice, y nunca porque la nueva clave firma el release con el que llegó. Ambas cosas un host comprometido puede producir; la firma de la clave anterior sobre una clave que nunca vio, no puede. Eso es lo que impide que alguien re-firme tu servidor.
Un ataque medido, acotado y vuelto a medir
Esta es la prueba de seguridad de esta página, porque tiene números de los dos lados.
Todo esto se midió en una máquina de prueba de 8 GB con dos proyectos y Redis limitado a 476 MB. Es una máquina distinta de las de 4 GB de la ronda de sistemas operativos de arriba — en esa ronda solo se midieron máquinas de 4 GB, y las dos afirmaciones son ciertas. Las corridas posteriores a la corrección se hicieron con el presupuesto de listados forzado a 64 MB, que es el ajuste que recibe la máquina soportada más chica, no los 245 MB que normalmente le tocarían a una máquina de 8 GB.
Antes de la corrección
| Medición | Valor |
|---|---|
| Techo de memoria de Redis en esa máquina | 476 MB |
| Una entrada de búsqueda de artículos con el tamaño de página más grande (limit=200) | 917,704 bytes |
| Copias escritas por entrada | 2 — una clave viva y una copia vieja del mismo tamaño |
| 20 búsquedas de una sola letra con ese tamaño de página | +34.2 MB en 4.8 segundos — medido, así que unos 1.71 MB por término |
| Peticiones necesarias para llenar todo el servidor de caché | 476 ÷ 1.71 ⇒ unas 278, alrededor de 67 segundos en una sola conexión |
| Sesión de un comprador con sesión iniciada | expulsada — sesión cerrada en silencio |
Nota aritmética, porque esta página no puede hacer virtud de atrapar números imposibles más arriba y después imprimir una tabla que falla su propia multiplicación. El informe interno indica un costo por término de 1.79 MB y una cifra de llenado de unas 279 peticiones. Ninguna se deduce de la otra: 917,704 × 2 = 1,835,408 bytes = 1.835 MB, no 1.79 MB, y 476 ÷ 1.79 = 265.9, no 279. La fila que sí cuadra con todo es la medida — 20 búsquedas cuestan 34.2 MB, es decir exactamente 1.71 MB cada una, y 476 ÷ 1.71 = 278.36, truncado a 278; aquí nada se redondea hacia arriba. Eso también coincide con el tiempo indicado: 20 peticiones tomaron 4.8 s, así que 278 toman 66.7 s ≈ los 67 segundos que reporta la fuente. Esta página imprime la cadena que un lector puede comprobar, y descarta 1.79 MB y 279 en vez de repetirlos.
Después de la corrección — las tres inundaciones que tabula el archivo de evidencia, incluida la que no guarda nada
El archivo de evidencia describe “seis inundaciones concurrentes sin autenticación” encima de una tabla de tres filas y nunca concilia las dos cosas. Si eso significa seis procesos de inundación que producen tres resultados tabulados, o tres de seis corridas reportadas, la fuente no lo dice — así que esta página dice “las tres que reporta la fuente” y no afirma que estén completas.
| Inundación | Entradas guardadas | Bytes de listados en Redis | Expulsiones | Sesión |
|---|---|---|---|---|
| 200 peticiones con el tamaño de página más grande (limit=200) | 0 | 0 | 0 | viva |
| 500 peticiones con un tamaño de página de 50 filas | 206 | 51.5 MB | 0 | viva |
| 2,000 peticiones con un tamaño de página de 50 filas | 207 | 51.8 MB | 0 | viva |
En esas inundaciones, Redis en conjunto llegó a un pico de 53.6 MB de sus 476 MB. Esa cifra es la instancia entera, no la familia de listados: la tabla de arriba limita los bytes de listados a 51.8 MB, así que 53.6 MB no puede ser la caché de listados.
En la máquina soportada más chica, la familia de listados está limitada a 64 MB de una instancia de Redis de 128 MB. A alrededor de 1 KB por sesión, eso deja espacio del orden de 60,000 compradores con sesión iniciada — un espacio que también guarda todo lo demás que Redis hace en esa máquina, así que tómalo como una cifra de margen, no como un número de asientos.
Qué es el panel, dicho claramente
Tres hechos en los que insiste la propia documentación del producto.
- El panel es equivalente a root en la máquina, por construcción: instala paquetes, escribe configuración del sistema y reinicia servicios. En el runtime Docker además monta el socket Docker. Ninguno de los dos arreglos es contención, y ninguno se presenta como uno.
- La dirección secreta de acceso es una verja. El inicio de sesión va detrás de ella, y todo inicio de sesión pide una contraseña y un código de doble factor.
- Hay exactamente una cuenta de administrador y no hay roles. Compartir se hace con accesos temporales y un acceso de demostración de solo lectura.
Cómo probamos
Dos rondas independientes dijeron "no está listo". Aquí está lo que encontraron.
La mayoría de páginas de software te dicen qué hace un producto. Esta también te dice qué estaba mal con él antes del lanzamiento, porque cómo se prueba una cosa es la única evidencia honesta de cuán bien funciona.
- Routes ejercidas, 283 page loads a través de cinco tamaños de pantalla en light y dark
52
Routes ejercidas, 283 page loads a través de cinco tamaños de pantalla en light y dark
- Llaves de texto de interfaz verificadas, en cada uno de 7 idiomas
2.740
Llaves de texto de interfaz verificadas, en cada uno de 7 idiomas
- Flujos de panel conducidos de extremo a extremo, en ambas codebases de 6amMart
34
Flujos de panel conducidos de extremo a extremo, en ambas codebases de 6amMart
- Rondas independientes cuyo veredicto fue "no listo"
2
Rondas independientes cuyo veredicto fue "no listo"
Un tema pasó a través de cada hallazgo serio
Cada defecto peor fue una superficie verde sobre una cosa rota. Una página que dice "éxito", un número de versión que dice "actualizado", un health check que dice "healthy" — cada uno verdadero como afirmación y falso como hecho. Por eso los checks abajo ahora testean el resultado en lugar del código de salida.
Lo que las rondas encontraron, y qué sucedió con ello
Estos son nuestros, eran serios, y están arreglados. Abre cualquiera para el detalle.
Los backups estaban corriendo, reportando éxito, y no contenían base de datosArreglado
La regla de exclusión de la herramienta de backup filtró toda la ejecución, así que excluir el directorio de trabajo también canceló los archivos de dump de base de datos que la misma ejecución había nombrado explícitamente. La herramienta almacenó el directorio vacío y se cerró exitosamente.
Seis snapshots — uno de ellos etiquetado como el backup de base de datos — sostenían 10.888 archivos y ni un dump de base de datos, mientras la página de Backups reportaba éxito y un tamaño de repositorio en todo momento.
Se escondió porque el umbral de verificación era 21 días contra un horario semanal. Ambos eran incorrectos, y ahora ambos son gates en lugar de configuraciones.
Arreglado, y un restore fue entonces probado en lugar de asumido: un backup fresco sostiene un dump de base de datos de 39 MB que restaura 192 tablas y todas las 66.701 órdenes.
La tienda del cliente estaba escuchando en un puerto público, fuera de cada protecciónArreglado
Estaba vinculada a cada interfaz de red en un puerto plano sin encriptar, evitando el servidor web y por lo tanto el certificado, ambos limitadores de velocidad, la caché y cada header de seguridad. Era una suposición llevada adelante del producto de contenedor con nada detrás en una instalación nativa.
El test también estableció que el proveedor de hosting no aplica firewall por defecto, así que esto era sin mitigación en una instalación por defecto en lugar de teórico.
Arreglado, verificado desde internet pública, y verificado de nuevo después de un reboot.
Deploy, rollback y activación actualizaron el código y el sitio siguió sirviendo la versión antiguaArreglado
SixPanel mantiene el cache de código compilado de PHP fijado — una opción de velocidad deliberada y medida — lo que significa código que cambia sin un reload nunca es ejecutado. Solo uno de los cuatro caminos que escriben código realizó ese reload.
Así que un deploy sacó código nuevo, corrió las migraciones de base de datos, reconstruyó los caches y reinició los workers mientras el sitio web servía la versión antigua indefinidamente. Rollback no hizo nada.
Demostrado en lugar de argumentado, a través del servidor web real en un archivo ya almacenado en caché: antes de la edición servía la versión uno; después de la edición sin reload aún servía la versión uno mientras el disco sostenía la versión dos; después del reload servía la versión dos.
Arreglado en los cuatro sitios. La lección se mantuvo: una configuración de rendimiento que depende de la disciplina en otro lugar eventualmente no la tendrá, así que el reload ahora es parte de la misma función que escribe el código.
Una tienda podría leer secretos de pago y email de otra tienda fuera de la caché compartidaArreglado
La caché era un servicio compartido único detrás de una contraseña que cada archivo de configuración del proyecto contiene. Comenzando desde su propio usuario de un proyecto, un probe leyó la contraseña de mail de otro proyecto en caché, credenciales de notificación push, claves de mapas, clave de pasarela SMS, secreto anti-bot y dos claves secretas de pasarelas de pago — y escribir también fue permitido, lo que hizo la configuración de mail en caché de la víctima alterable.
La solución es una instancia de caché por proyecto, en su propio socket, en su propio directorio, con su propia contraseña y su propio límite de memoria. La frontera es el sistema de archivos; la contraseña es el segundo candado.
Probado volteando el ataque de vuelta: el probe fue de siendo exitoso a siendo rechazado en ambas direcciones — rechazado mientras sostenía la propia contraseña del objetivo — y fue verificado de nuevo contra un permiso deliberadamente roto para confirmar la prueba misma aún funciona.
Costo medido: 3,2 MB de memoria por proyecto. El conteo de workers PHP es sin cambios en 18 de 20 combinaciones de servidor y proyecto, y el socket es realmente más rápido que el loopback de red que reemplazó. Mover los datos vivos tomó 13,9 milisegundos y no cerró la sesión a nadie.
Las actualizaciones estaban llegando al disco sin tomar efecto, tres veces en una rondaArreglado
Un servidor tomó una actualización, reportó la nueva versión, y siguió sirviendo con la configuración escrita el día que fue instalada. Cuatro caminos diferentes pueden poner estado en un servidor, y no estaban entregando el mismo conjunto.
Una auditoría completa de esos cuatro caminos encontró aproximadamente quince categorías de estado que una instalación fresca produjo y un servidor actualizado nunca recibió — toda la escalera de ajuste, la configuración de base de datos, el pool de PHP por defecto, un archivo incluido por cada sitio, el servicio de alertas y sus hooks de fallo, y más.
Un caso era invisible en dos capas a la vez: cada servidor en el canal publicado estaba fallando el mismo paso en cada actualización, eternamente, y debajo la herramienta de línea de comandos en su propio check de versión se reportaba a sí misma como actual cuando estaba tres releases atrás.
Arreglado, y ahora aplicado por un check que corre en cada build: cada función que escribe estado debe declarar si una actualización la entrega y por qué. Verificado contra 14 sabotajes deliberados, los 14 atrapados.
Entonces probado de extremo a extremo: un servidor actualizado desde el canal publicado y un servidor recién instalado produjeron 1.447 de 1.447 líneas de configuración byte por byte idénticas.
En CodeCanyon 6amMart sin tocar, la instalación terminó y el panel de admin fue inutilizableArreglado
Vendor 6amMart cierra su panel de admin detrás de un paso de activación de código de compra después de login. SixPanel nunca pidió el código, nunca lo mencionó, y reportó el deployment como terminado.
Permaneció invisible por mucho tiempo porque nuestra propia copia optimizada de 6amMart tiene ese check deshabilitado, así que el historial completo de prueba del producto había corrido contra una codebase donde el gate no existe.
El wizard ahora recolecta el código de compra y completa la activación del propio de la aplicación. Una trampa fue cerrada en el camino: la aplicación salta al servidor de licencia completamente cuando el request viene de la máquina misma, que es lo que hace un request de línea de comandos, así que cualquier código inventado habría sido aceptado sin paquete saliendo del servidor.
Dos cosas relacionadas fueron arregladas con ello. La tienda ahora instala desde el zip que un comprador de CodeCanyon realmente tiene, en lugar de requerir un repositorio git. Y los proyectos vendor ya no son deployados en modo de desarrollo, que imprimía la propia respuesta del captcha de login en la página.
La firma de actualización protegía el release pero no el instalador que lo aplicabaArreglado
Doce casos adversariales ahora pasan contra el artefacto publicado, y el mismo harness de prueba produce doce fallos contra el instalador anterior — dos de ellos un instalador de un extraño siendo exitoso y dejando una clave de un extraño fijada en el servidor.
Caminar más atrás encontró algo que vale la pena plantear claramente: una firma atestigua lo que fue construido, no a lo que lo construyó. El build estaba obteniendo sus propias herramientas en la versión más reciente que sucediera ser, así que un árbol de dependencias fue re-resuelto en cada build y se envió dentro del artefacto firmado. Ambas herramientas de build ahora están fijadas a versiones exactas bajo un lockfile comprometido.
Un cerca-fallo separado de la misma ronda: un comando de certificado había ganado una opción que la versión instalada no tiene, que habría hecho cada renovación fallar silenciosamente hasta que los certificados expiraran. Sobrevivió revisión porque pedirle a esa herramienta su versión se cierra exitosamente sin importar qué otra cosa sin sentido esté en la línea.
Veinticuatro lugares donde el panel le dijo al propietario algo que no era del todo verdaderoArreglado
"Saludable en general" en un servidor que el sistema operativo mismo llamó degradado — nada en el código de health jamás lo había preguntado. En el servidor de release un servicio programado había estado fallando cada 60 segundos por un día, disparando su hook de fallo 1.440 veces, mientras el titular leía healthy.
Auto-sanación tratando un check que no podía correr como una observación de salud. Una discrepancia de 135 veces entre dos conteos de error. Uso de disco contabilizado por el 18,4% del espacio usado y presentándolo como la imagen completa — ahora 92,7%.
Un wizard de configuración inacabado que nunca requirió el endpoint de versión en absoluto, y navegación móvil que se colapsó a ancho cero siempre que el aviso de actualización estaba mostrando.
Los 24 cerrados. Dos de los últimos seis defectos reportados resultaron no ser reales, y ambos fueron dejados caer con la evidencia en lugar de arreglados para apariencia.
Cada servidor instalado estaba corriendo archivos propiedad de un usuario que no existe en élArreglado
El propio usuario y grupo de la máquina de build fueron horneados en el artefacto — 459 archivos en un servidor, incluyendo uno que había tomado solo el comando de instalación publicado.
No explotable como estaba, pero significó que el sistema estaba ejecutando código que no poseía, que no es un estado que valga la pena dejar solo.
Corregido por la actualización misma: 459 archivos con el propietario incorrecto se convirtieron en cero.
Qué se mantuvo
Las mismas rondas también confirmaron las cosas que se suponía debían funcionar, y esas valen la pena ser anunciadas con sus números en lugar de como adjetivos.
- Reboot completo
- De vuelta sobre SSH en 79 segundos, cero servicios fallidos, cada servicio en estado byte-idéntico a la snapshot tomada antes del reboot, ambos websockets conectados, ningún paso manual.
- Matar el panel completamente
- De vuelta en aproximadamente 4 segundos.
- Una actualización ordinaria
- Cero segundos de downtime, 91 de 91 requests contestadas normalmente en todo momento.
- Restore desde backup
- 192 tablas y 66.701 órdenes, desde un backup programado real en lugar de uno hecho para la prueba.
Todavía abierto, y planteado aquí en lugar de dejado fuera
- Un contador de base de datos lee mal en el servidor nativo — tablas temporales siendo escritas a disco en el 59,8% de queries. Es un problema de forma de query en lugar de un ajuste, y es nuevo desde la última ronda.
- El producto de contenedor necesita un release para llevar el fix de backup y el trabajo de DNS descrito arriba.
- Un trabajo de fondo fallido obsoleto en el servidor de prueba es la razón entera por la que su propio check-up puntuó 88 en lugar de 97 — la puntuación se fija siempre que cualquier fila es mala, y las puntuaciones crudas subyacentes difieren por 0,03 a través de aproximadamente cien checks.
Nada de esto es inusual para software de servidor. Lo que es inusual es publicarlo. Si una página de marketing de panel no tiene una lista como esta, no significa que no haya nada para encontrar.
Límites honestos
Límites honestos
Cada uno de estos es cierto hoy.
- 1
It takes the whole server.
Ningún otro sitio web, ningún otro panel de control, nada más en los puertos 80 y 443.
- 2
Una sola cuenta de administrador. Sin roles, sin cuentas de equipo.
Los accesos temporales y un acceso de demostración de solo lectura son los mecanismos para compartir.
- 3
El panel es equivalente a root en la máquina.
Cualquiera que pueda conectarse a él puede ejecutar cualquier cosa en ese servidor. Eso es lo que es un panel de servidor. En el runtime Docker, reinicio, actualización del sistema operativo y auto-actualización además funcionan lanzando un contenedor privilegiado que entra en el filesystem del host.
- 4
Restaurar todavía no es un botón de «mover a cualquier servidor».
Una copia de seguridad cubre todos los proyectos, pero la restauración apunta hoy al proyecto por defecto. Restaurar en otra máquina deja en su sitio las contraseñas y rutas de la máquina antigua, y la aplicación no puede conectar hasta que pulses Actualizar. El trabajo de restauración tampoco ejecuta migraciones de base de datos, así que una copia antigua bajo código nuevo se queda por detrás del esquema. Ambos tienen un paso manual que funciona; ninguno es automático hoy. El propio camino de restauración se verificó leyendo el código y no se ejecutó en la ronda del 15 de agosto.
- 5
Volver atrás el código no deshace las migraciones de base de datos.
Si una migración ya se ha ejecutado, volver atrás el código requiere restaurar una copia de seguridad.
- 6
El panel toma un certificado renovado al reiniciarse.
La renovación diaria recarga nginx; el panel lee su propio certificado una sola vez al arrancar.
- 7
Traer una tienda desde un servidor antiguo se verificó leyendo el código, no ejecutándolo.
Eso fue en la ronda del 15 de agosto. Tómalo como compatible, no como probado en tu tipo de servidor.
- 8
El watchdog de auto-curación solo ve servicios que declaran un health check.
En el runtime de contenedor los contenedores opcionales de websocket y tienda no declaran uno aún. Separadamente, y encontrado por prueba en lugar de lectura: auto-curación una vez reportó una reparación exitosa mientras un worker en segundo plano se había atascado durante 14 minutos con 250 trabajos congelados detrás de él. Todo lo que puede genuinamente observar, ahora lo reporta como una observación; todo lo que no puede, ahora dice que no puede.
- 9
El código del propio panel no es legible en tu servidor.
Su parte de servidor se entrega como bytecode de V8 y las fuentes legibles se quitan de la compilación; los archivos del navegador están minimizados y ofuscados. Eso es disuasión, no protección — quien se empeñe puede seguir averiguando qué hace. Tu código de 6amMart y tus datos quedan intactos.
- 10
Una firma acredita lo que se compiló, no quién lo compiló.
Ahora todos los caminos de actualización verifican su firma, y también lo hace el instalador que la aplica. Pero retroceder desde la firma encontró algo que merece decirse en voz alta: la máquina de compilación venía descargando sus propias herramientas en la versión que fuera la más reciente en ese momento, así que un árbol de dependencias se resolvía de nuevo en cada compilación y viajaba dentro del artefacto firmado — genuinamente firmado, y no los mismos bytes dos veces de forma reproducible. Ambas herramientas de compilación están ahora fijadas a versiones exactas bajo un archivo de bloqueo versionado. El punto general vale para cualquier software firmado que instales: la firma cubre el resultado, y sigues confiando en quien ejecutó la compilación.
- 11
El registro de actividad tiene un hueco, y las reglas de reautenticación son desiguales.
Borrar una tarea programada no escribe registro de auditoría, mientras que crear, editar y ejecutar una a mano sí lo hacen — así que borrar una tarea root a nivel de panel no deja rastro. Aparte: una tarea programada a nivel de panel te obliga a volver a escribir tu contraseña, pero reiniciar, actualizar el sistema operativo y actualizar el panel — todos root en la máquina — solo requieren una sesión válida.
- 12
Tres ajustes del panel son configuración muerta.
En el runtime Docker el límite de tasa de API del panel, su límite de tasa de ruta pesada y su límite de tamaño de carga se leen por el código pero nunca se pasan al contenedor del panel, así que establecerlos en el archivo de configuración cambia nada. La documentación dice nunca apuntar un administrador a ellos.
- 13
No Kubernetes.
No hay controlador de Kubernetes en el panel.
- 14
El compilador JIT de PHP está encendido en un runtime y apagado en el otro.
SixPanel ejecuta el JIT de tracing de PHP. Contra el modo que aaPanel envía, medido más rápido en 9 de 9 endpoints en una solicitud y 9 de 9 con cuatro a la vez; si apagar JIT completamente sería más rápido aún en este runtime no ha sido probado. En el runtime de contenedor JIT está apagado, porque allá medido más lento en 11 de 12 endpoints y empatado en el doceavo. Mismo ajuste, dos stacks, respuestas opuestas — ambas son lo que la medición dijo. Brotli y HTTP/3 en el origen están apagados en ambos, deliberadamente: Cloudflare hace esa capa.
- 15
La cola en segundo plano usa la base de datos, no Redis.
Redis midió 1,76× más rápido en rendimiento de cola y aun así se descartó, porque bajo presión de memoria una cola en Redis puede desalojarse en silencio — 50 trabajos en cola pasaron a 0 sin nada registrado y sin ningún error. Nada crítico para los pedidos se encola siquiera.
- 16
El límite de peticiones es un escudo contra avalanchas, no protección DDoS.
Los límites por dirección no pueden ser precisos cuando una ciudad entera comparte una sola IP de operador. Cloudflare es la capa de verdad para eso.
SixPanel y 6amMart
SixPanel es el servidor. El código optimizado es 6amMart en sí.
SixPanel hace que una instalación de 6amMart sea rápida de configurar, segura de actualizar y barata de operar.
Hacer más rápidas las pantallas del propio 6amMart es un trabajo aparte, y viene con el servicio de instalación en vez de ser un extra — medido en 10× a 22× más rápido en todas las pantallas que ve el cliente, en un servidor en vivo. Esas pantallas pasaron de 0.5–8.19 s a 45–370 ms.
Los dos conjuntos de números miden cosas diferentes y nunca se mezclan en una tabla. Los de SixPanel son números de servidor — la misma aplicación, servida por stacks diferentes. Los del código optimizado son números de aplicación — el mismo stack, ejecutando código diferente. La cosa más lenta medida en cualquier lugar en esta ronda fue ninguna de las dos: un reporte de administrador de 6amMart de 20.9 segundos, que ningún ajuste de servidor movió.
El código optimizado no es algo que compres por separado. No hay una segunda licencia, ni un segundo precio, ni una segunda línea de versiones — es la forma en que se entrega el servicio de instalación de 6amMart que ya existía, con la misma instalación de $300. Cuando el proveedor de 6amMart publica una versión nueva, la regla publicada del catálogo aplica sin cambios: actualizar o pasar a una versión más nueva del script cuesta el 50 % del precio de instalación. Cada instalación sale sobre la última versión de 6amMart.
Preguntas frecuentes
Preguntas que la gente hace de verdad
Catorce preguntas, respondidas con los mismos números que el resto de la página.
¿Qué es SixPanel?
Un panel de control de servidor para un trabajo: ejecutar una tienda 6amMart en tu propio servidor. Instala el servidor web, base de datos, PHP, caché, worker en segundo plano, scheduler, servidor websocket y certificado HTTPS, y luego te da una página web para ejecutarlo todo. Viene en dos runtimes — uno que instala directamente en la máquina, que es el recomendado, y uno que usa contenedores.
¿SixPanel incluye el script 6amMart?
No. 6amMart lo compras en CodeCanyon. SixPanel instala el código que ya posees, desde tu propio repositorio git privado. SixPanel es gratis y se publica aparte en CodeCanyon, y su comando de instalación es público — el mismo para todo el mundo.
¿Qué sistema operativo debería instalar?
Ubuntu 26.04 LTS, en cualquiera de los dos runtimes. El nativo soporta exactamente tres releases — Ubuntu 26.04, Ubuntu 24.04 y Debian 13 — y toma PHP, MariaDB, nginx y Redis del que elijas. La velocidad no es la razón: en seis ejes medidos ningún cambio de versión produjo una diferencia reportable. Las actualizaciones de seguridad sí lo son: 26.04 recibe parches hasta abril de 2031, frente a mayo de 2029 para 24.04 y agosto de 2028 para Debian 13. Debian 12 lo rechaza por nombre el runtime nativo; el de contenedores sigue instalándose en él, pero su soporte de seguridad terminó en julio de 2026, así que no arranques una tienda nueva ahí.
¿Por qué la recomendación va de margen de soporte y no de velocidad?
Porque la velocidad no decidió nada. Se midieron seis ejes en hardware idéntico — el sistema operativo, PHP, MariaDB, nginx, Redis y el kernel — y ningún cambio de versión produjo una diferencia reportable. Dos máquinas idénticas byte a byte discreparon entre sí en un 11,6 % en 20 de 20 filas, lo que es mayor que cualquier efecto encontrado. Lo que sí difiere es cuánto tiempo sigue recibiendo parches de seguridad cada release, y que un sistema operativo se quede sin soporte es el único evento que obliga a reconstruir el servidor entero. Ubuntu 26.04 LTS tiene el margen más largo de los tres, hasta abril de 2031.
How small a server can I use?
Dos núcleos de procesador y 4 GB de RAM mueven una tienda entera — ese es el tamaño sobre el que medimos. El instalador rechaza por debajo de unos 1,2 GB y avisa por debajo de 2 GB. Para una segunda o tercera tienda, cuenta con unos 2 GB más de RAM y 1–2 núcleos más por cada una.
¿Qué tan rápido es?
Medido contra aaPanel en hardware idéntico — 2 núcleos, 4 GB, la misma tienda con 66,701 órdenes — SixPanel respondió 1.76× más rápido en una solicitud y 1.82× más rápido con cuatro llegando a la vez, en los endpoints que alcanzan PHP en ambas máquinas. aaPanel fue completamente ajustado primero. La tabla completa, el método y la parte aún sin explicar están todos arriba.
¿Cuánto tarda la instalación?
Alrededor de cinco minutos, desatendido, en el runtime de contenedor — 273 a 303 segundos medidos en tres sistemas operativos. El runtime nativo no ha sido cronometrado de la misma forma, así que ningún número para él se imprime aquí. Ir desde un servidor alquilado a una tienda en vivo, incluyendo DNS, el certificado e instalar tu código, toma alrededor de una hora en el primer servidor de cualquier forma.
¿Puedo alojar mis otros sitios web en el mismo servidor?
No. El instalador rechaza un servidor que ya ejecute aaPanel, CloudPanel, cPanel o Plesk, o que tenga algo usando los puertos 80 o 443. SixPanel gestiona el servidor web, los certificados y el plan de cortafuegos de toda la máquina, y dos sistemas haciendo eso en una misma máquina se rompen entre sí. Ejecutar más tiendas 6amMart en el mismo servidor sí está soportado.
¿Puedo dar acceso a mi desarrollador sin darle mi contraseña?
Sí. Crea un acceso temporal con su propio nombre y contraseña, que caduca a la hora, a las 8 horas, a las 24 horas o a los 7 días. Puede llevar el sitio. No puede cambiar quién entra ni ver tus secretos. También hay un acceso de demostración de solo lectura para enseñarle el panel a alguien.
¿Actualizar SixPanel toca mis datos o mi código?
No. Actualizar SixPanel reemplaza el código propio de SixPanel. Tu configuración, tus datos — base de datos, cargas, certificados, backups locales — y tu código de aplicación se dejan exactamente como están. Una cosa que vale la pena saber, porque lo encontramos de la forma difícil: una actualización que aterriza archivos en disco no es lo mismo que una actualización que toma efecto. Cada ruta que escribe estado ahora tiene que declarar si una actualización la entrega, una verificación se ejecuta en cada build, y un servidor recién instalado y uno actualizado fueron probados para producir 1,447 de 1,447 líneas de configuración idénticas.
¿Cómo sé que las copias de seguridad funcionan de verdad?
El panel lo prueba, y la razón por la que lo prueba es que esto salió mal una vez. Los backups se ejecutaron, reportaron éxito y no contenían base de datos en absoluto durante cuatro días, porque la regla de exclusión de la herramienta canceló los archivos de volcado que la misma ejecución había nombrado. Eso está arreglado, y ahora es un gate en lugar de un ajuste: un restore se carga en una base de datos desechable, se cuenta y se elimina — 192 tablas y 66,701 órdenes, desde un backup programado real. Dos advertencias honestas permanecen: restaurar en un servidor diferente necesita un paso manual después, y restore actualmente apunta al proyecto predeterminado.
Is SixPanel open source?
No. La parte de servidor del panel se entrega como bytecode de V8 con las fuentes legibles quitadas, y los archivos del navegador están minimizados. Lo llamamos disuasión, no seguridad — quien se empeñe puede seguir averiguando qué hace el código. Tu código de 6amMart y tus datos son tuyos y nada de esto los oculta. Si tener fuentes legibles en tu propio servidor es un requisito, un panel abierto de propósito general es la mejor opción para ti.
¿Cuál es la diferencia entre SixPanel y SixPanel Docker?
El mismo panel, los mismos comandos y el mismo manual — solo difiere la forma en que se instala el software de debajo. SixPanel instala nginx, PHP, MariaDB y Redis directamente desde el propio archivo de la distribución del release y deja que systemd los supervise. SixPanel Docker corre el mismo stack como contenedores, fijado en PHP 8.4 y MariaDB 10.11 sea cual sea el host. El nativo es más rápido en todos los endpoints medidos y aísla los proyectos en el kernel en lugar de dentro de PHP, así que es la recomendación, y es donde va el desarrollo nuevo. Elige el de contenedores si quieres el stack aislado en contenedores, o si necesitas MariaDB 10.11 en un release cuyo archivo no la trae.
Tu página enumera defectos de vuestro propio producto. ¿Por qué?
Porque es la única prueba honesta de que las pruebas son reales. Dos rondas independientes de extremo a extremo dictaminaron «no está listo» antes de dar esto por terminado, y encontraron copias de seguridad que informaban de éxito sin ninguna base de datos dentro, una tienda escuchando fuera de todas las protecciones, y despliegues que actualizaban el código mientras el sitio seguía sirviendo la versión anterior. Todo está corregido, cada cosa con la comprobación que ahora lo mantiene así. Si la página de un panel no lleva una lista como esta, no significa que no hubiera nada que encontrar.
Empieza con la revisión gratuita, y después decide
SixPreflight te dice si el servidor que tienes está listo para 6amMart, y exactamente qué cambiar. Si prefieres que nosotros nos encarguemos de todo, habla con nosotros.
Mira qué cambió en cada versión