SixPanel: o painel de hospedagem feito para um só trabalho — rodar o 6amMart
O SixPanel é um painel de hospedagem feito para um só trabalho: rodar uma loja 6amMart no seu próprio servidor. Um comando instala o servidor web, o banco de dados, o PHP, o cache, o worker em segundo plano, o scheduler, o servidor websocket e o HTTPS. Depois disso você opera o servidor por uma página web.
Tudo roda no seu servidor. Seu banco de dados, suas imagens, os dados dos seus clientes.
- Instalação sem supervisão, medida em três sistemas operacionais
273–303 s
Instalação sem supervisão, medida em três sistemas operacionais
- Roda uma loja inteira
2 núcleos / 4 GB
Roda uma loja inteira
- Verificações de saúde, cada uma com um botão de correção
~20
Verificações de saúde, cada uma com um botão de correção
- Idiomas da interface do painel
8
Idiomas da interface do painel
Está lendo isto com um assistente de IA?
Obter o SixPanel
O SixPanel instala-se com um único comando. Nada para registar, nenhuma chave para introduzir, nenhum código para colar — é o mesmo comando para toda a gente. É gratuito.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashO que protege um comando executado como root não é o endereço — é a assinatura da versão. O instalador leva a nossa chave de assinatura e recusa automaticamente qualquer ficheiro que não corresponda. A página de instalação explica isso.
Experimente antes de descarregar
Acesso só de leitura
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.
Obter o SixPanel
Free- Atualizações incluídas — cada versão chega ao CodeCanyon sem custo adicional, e o painel também se pode atualizar sozinho. Sem servidor de licenças, sem chave para renovar.
- A primeira configuração é gratuita — envie o seu código de compra e os dados do servidor por WhatsApp ou e-mail.
Nada para ativar — corre no seu próprio servidor, não comunica para fora, e continua a funcionar mesmo que este site esteja em baixo.
O que é, e o que ele substitui
O script é seu. Alguém ainda precisa rodar o servidor.
Você comprou o script 6amMart no CodeCanyon. Ele é uma pasta de arquivos. Antes de aceitar um pedido, alguém precisa instalar um servidor web, um banco de dados, PHP, um cache, um worker em segundo plano e um certificado HTTPS — e depois manter tudo isso funcionando.
O SixPanel é a parte que faz isso. Você aluga um servidor novo, roda um comando e recebe de volta um painel de controle web. Desse painel você conecta seu domínio, obtém HTTPS gratuito, instala seu código 6amMart a partir do git, atualiza, faz backup e vê o que está quebrado quando algo quebra.
Tudo roda no seu servidor. Seu banco de dados, suas imagens, os dados dos seus clientes.
Três formas de operar
O painel
No navegador. É onde você faz quase tudo.
O comando sixpanel
No servidor, para quando o painel não abrir.
O instalador
Que você roda uma vez.
Com isto versus sem isto
Cada linha é o mesmo trabalho, feito das duas formas. À esquerda, o que rodar o 6amMart exige de você sem o SixPanel; à direita, no que isso se transforma com ele.
Colocar o servidor no ar
Sem isto
Montar um servidor à mão — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, um supervisor de processos — e manter tudo isso vivo
Com o SixPanel
Um comando de instalação. O systemd é o supervisor — reinicia ao quebrar, reinicia após o servidor reiniciar, executa sem intervenção.
Dimensionar o banco de dados e o PHP
Sem isto
Adivinhar as configurações do banco de dados e do PHP, ou pagar alguém para ajustá-las
Com o SixPanel
Autotune lê a máquina real e escreve os tamanhos: workers PHP, database pool, Redis memory, nginx buffers. Sem guesswork. Sem um painel bloqueado em um laptop pequeno.
Publicar uma mudança na loja
Sem isto
Pagar um desenvolvedor a cada implantação
Com o SixPanel
Faça o push para o git e a loja atualiza. Histórico de deploys e rollback, com os últimos 30 deploys guardados.
Saber que o backup funciona
Sem isto
Torcer para que o backup funcione
Com o SixPanel
Os backups rodam em uma agenda com retenção, e uma vez por semana o painel carrega o backup mais novo em um banco de dados descartável, conta o que há dentro e o apaga de novo.
Quando a loja cai
Sem isto
Ler um stack trace para descobrir por que a loja caiu
Com o SixPanel
Uma página de saúde com cerca de vinte verificações, cada uma com uma frase simples sobre a consequência e exatamente um botão de correção.
O que custa
Sem isto
Construir e manter esse stack por conta própria é o custo, seja pago em horas ou em notas fiscais.
Com o SixPanel
Nada. O SixPanel é gratuito no CodeCanyon, a primeira instalação e configuração é gratuita, e o comando de instalação é o mesmo comando público para todos — sem chave para digitar, sem código para colar. As atualizações chegam pelo CodeCanyon, e o painel também pode se atualizar sozinho.
O que ele não substitui
Ele não vende o script 6amMart a você.
Você compra isso no CodeCanyon, e o SixPanel instala o código que você já tem.
Ele não é hospedagem compartilhada.
Sem conta de cPanel, sem outros sites na máquina. O SixPanel espera o servidor inteiro.
Ele não opera a sua loja.
Preços, produtos, entregadores e pedidos vivem no painel admin do próprio 6amMart.
Ele não é um CDN nem um serviço anti-DDoS.
O Cloudflare é a camada de borda de verdade, e a documentação diz isso.
Duas formas de executá-lo
Um painel, dois ambientes de execução — e um deles é o recomendado
Ambos são o mesmo produto, com o mesmo painel, os mesmos comandos e o mesmo manual. Diferem apenas na forma como o software por baixo é instalado, e essa diferença é mensurável.
- Recomendado
SixPanel
Executa diretamente no servidor
nginx, PHP-FPM, MariaDB e Redis instalados a partir do próprio arquivo da distribuição do release e supervisionados pelo systemd. Nada fica em contêiner, então cada salto é um socket unix e o banco é ajustado para a máquina e não para um contêiner. Este é o mais rápido dos dois, e é para onde vai todo o trabalho novo.
Comando de instalação
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- Sistema operacional
- Ubuntu 26.04 LTS (recomendado), Ubuntu 24.04 LTS ou Debian 13
- PHP
- 8.5 no Ubuntu 26.04, 8.4 no Debian 13, 8.3 no Ubuntu 24.04 — sempre o pacote do próprio release
- Base de dados
- MariaDB 11.8 no Ubuntu 26.04 e no Debian 13, 10.11 no Ubuntu 24.04 — do mesmo arquivo
- Supervisionado por
- systemd
SixPanel Docker
Executa em contêineres
A mesma pilha como serviços do Docker Compose. A vantagem é que as versões de PHP e do banco não dependem em nada do host: as imagens estão fixadas em PHP 8.4 e MariaDB 10.11, em qualquer release em que você as rode. Ele continua instalando, e servidores que já o rodam seguem recebendo atualizações.
Comando de instalação
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- Sistema operacional
- Ubuntu 24.04 / 26.04 LTS, Debian 13 — e Debian 12, que instala mas não é recomendado
- PHP
- 8.4, no contêiner
- Base de dados
- MariaDB 10.11, no contêiner
- Supervisionado por
- Docker Compose
Qual você deve escolher?
Escolha o SixPanel, a não ser que algo específico exija o outro. É mais rápido em todos os endpoints medidos, isola os projetos no kernel em vez de dentro do PHP, e é o ambiente que continua a melhorar.
Escolha o SixPanel Docker se quiser a pilha inteira isolada em contêineres, ou se precisar especificamente do MariaDB 10.11 em um release cujo arquivo não o traz — as imagens estão fixadas em PHP 8.4 e MariaDB 10.11 independentemente do host. Ele também continua instalando no Debian 12, mas não comece uma loja nova ali: o suporte de segurança do Debian 12 terminou em julho de 2026, e o kernel, a glibc, o Docker e o OpenSSH continuam vindo do arquivo do host.
Falando com franqueza: o desenvolvimento novo vai para o ambiente nativo. O SixPanel Docker é mantido, não ampliado. Se está a instalar hoje e pode escolher livremente o sistema operacional, escolha o nativo.
Medido, não afirmado
Três servidores, a mesma loja, uma diferença
Cada número de performance nesta página vem de uma rodada de medição. Três máquinas idênticas. O mesmo código. O mesmo dataset. Uma diferença: qual está rodando — aaPanel, Docker Compose ou SixPanel.
1.76×
SixPanel é 1,76× mais rápido
O Docker Compose fica a 40% abaixo da aaPanel stock; SixPanel fica a 76% acima.
Como foi medido
- Três servidores
- AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — idênticas exceto pelo software de controle.
- A mesma aplicação
- O mesmo código 6amMart em todos os três, verificado byte por byte: idêntico em checksum SHA256.
- A mesma loja
- 66.701 pedidos · 3.865 itens · 85 lojas · 17.534 clientes — um dataset real extraído de uma implantação de produção.
- O método
- Cada caixa se mede sobre loopback com seu hostname real e certificado, depois sobre a rede para cada outra caixa. Quatro rondas, 1.000 requisições por ronda. Os números são médias simples.
- A precisão
- Cada medição tem σ = 4 a 11%. O pior case é ±3%. Diferenças menores que 3% são ruído. Diferenças maiores que 20% são reais.
Throughput (requisições/s)
req/s
| Endpoint | SixPanel | Docker Compose | aaPanel (conforme enviado) | aaPanel (tuned) |
|---|---|---|---|---|
/api/v1/categoriesCategorias (mudança de aba) | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allLojas (mudança de aba) | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchBusca de produtos | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularPopulares (carregamento via JavaScript) | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listLista de pedidos do admin | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)Entrada do adminEspera — não é uma comparação like-for-like | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeVitrine (lista de produtos)Espera — não é uma comparação like-for-like | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeWebSocket (rastreamento de pedido ao vivo) | 2.35.8 | 4.211.6 | 2.66.3 | —— |
O que o torna mais rápido
Exato. SixPanel é tuned e verificado. aaPanel stock não é. Então nós o tuned também. Veja em baixo.
aaPanel tuned
Depois de medir, nós aplicamos o mesmo tuning que SixPanel usa à aaPanel stock. O resultado:
- Opcache do PHP elevado de 128 MB para 256 MB, com a validação de timestamp desligada
- Buffer pool do banco de dados elevado de 256 MB para 1152 MB — quatro vezes e meia maior
- Arquivo de log do banco de dados elevado de 128 MB para 320 MB, e o cache de consultas desligado
- Workers do PHP corrigidos de 50 sobrecomprometidos para 14 dimensionados
- Cache de caminhos quadruplicado e os buffers do servidor web dobrados
É justo? Sim. O tuning é software. Se você roda aaPanel, você pode fazer o mesmo. Se você roda SixPanel, você recebe isso por padrão.
aaPanel tuned agora se aproxima mais de SixPanel. A brecha fecha de 76% para 34%. Há ainda uma diferença, confessada acima.
A bateria do banco não se moveu nada. Um buffer pool quatro vezes e meia maior não mudou nada, porque esses relatórios são trabalho limitado por processador sobre linhas que já estavam em memória. As entranhas melhoraram — taxa de acerto do cache de 99,856 % para 99,930 %, tabelas temporárias caindo para disco de 47,3 % para 22,1 % — e os tempos de resposta não acompanharam.
Diferença de 40% da stock para tuned
Quando nós tunamos aaPanel — com os mesmos valores que SixPanel usa — ela fecha a brecha em 40%.
| Configuração | Serial (req/s) | Concurrent (req/s) |
|---|---|---|
| aaPanel conforme enviado | 1.99× | 1.91× |
| + open_basedir off | 1.32× | 1.29× |
| + JIT corrected | ≈1.25× | ≈1.21× |
O que nós identificamos
- open_basedir off60%
- JIT mode (funciona melhor em carga; tracing = 1254, function = 1205)8%
- PHP 8.4 contra PHP 8.10%
- Não atribuído32%
Mas nós não sabemos por que os outros 60% permanecem. Nós medimos e eliminamos o que poderíamos encontrar. O resto é uma verdade incômoda: ou há diferenças mais profundas que nós não procuramos, ou há um aviso de sinal em nossos testes.
A forma do resultado
Cada endpoint tem um shape diferente. Storefront (lista de produtos) é limitada por CPU; Search é I/O. Admin Entry (autenticação) é memória. O bottleneck muda, os ganhos mudam. SixPanel foi tuned para a distribuição real — mais CPU, menos memória desperdiçada. Mas o site real tem uma mistura: picos e vales, usuários e bots, cache hits e misses.
Os detalhes
SixPanel desativa open_basedir. aaPanel stock o ativa por padrão, e para a maioria dos endpoints, retira 5–13% de throughput.open_basedir
open_basedir é uma diretiva PHP que limita quais arquivos o script PHP pode ler.
Por padrão, aaPanel o define para `/home/www` — o diretório de documentação web. Quando o PHP acessa um arquivo, o kernel verifica se está em escopo. Código de inicialização, lógica de busca, qualquer coisa.
6amMart lê muito. Arquivos de visão, arquivos de tradução, arquivos de configuração — tudo é em disco. Cada leitura é verificada.
Para endpoints de alta throughput, a verificação se torna um gargalo de spin-lock. O teste de controle acima desativa o open_basedir para cada endpoint e repete a medição.
O custo varia. Endpoints que leem muita configuração ou tradução (Busca, Categorias) perdem 13%. Endpoints que leem menos (Storefront) perdem 5%.
O custo é real, mas está dentro da variância esperada de uma máquina física com concorrência e picos. Se você ligar o open_basedir, você perde 5–13% de throughput. Se desligar, você ativar o acesso do PHP a qualquer arquivo no servidor.
| Endpoint | open_basedir on (aaPanel stock) | open_basedir off (SixPanel) | Diferença |
|---|---|---|---|
/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 assetTeste de controle | 0.4 | 0.4 | 0% |
SixPanel ativa JIT com mode=tracing. aaPanel não ativa JIT em qualquer lugar.JIT mode
A configuração de JIT do PHP é um número de quatro dígitos, não uma chave liga/desliga, e os dois modos nomeados são diferentes: "function" é 1205 e "tracing" é 1254. Um script de ajuste que só verifica se o JIT está ligado vai tranquilamente deixar o modo errado no lugar e reportar o trabalho como feito.
O aaPanel entrega 1205. O SixPanel entrega tracing. Três pares alternados colocaram o tracing à frente em 9 de 9 endpoints com uma requisição e 9 de 9 com quatro ao mesmo tempo — média geométrica de 5.1% e 6.2%.
Qualquer uma dessas diferenças, isolada, cabe dentro do ruído destas máquinas. Dezoito de dezoito caindo para o mesmo lado, não.
Para o 6amMart especificamente, tracing é o modo certo: o JIT em modo function mira laços numéricos fechados, que uma requisição Laravel não executa.
Estar uma versão do PHP atrás não custa nada — medido, não supostoPHP 8.4 vs 8.1
O SixPanel instala o PHP que o próprio arquivo do release traz — 8.5 no Ubuntu 26.04, 8.4 no Debian 13, 8.3 no Ubuntu 24.04 — porque ficar nos pacotes da própria distribuição significa que as atualizações de segurança chegam automaticamente, sem nenhum repositório de terceiros no caminho que atende. A objeção óbvia é que um PHP mais novo é mais rápido.
A máquina do aaPanel tem as duas versões instaladas, então ela podia responder isso de forma limpa. O pool do 8.3 recebeu primeiro todo o ajuste do 8.4 — ele tinha ficado nos padrões, o que teria viciado o resultado — e as configurações foram verificadas a partir do processo em execução e não de um arquivo.
Três pares alternados: a média geométrica do 8.3 contra o 8.4 é 0.9994. O 8.3 ficou à frente em 3 linhas de 7, e cada diferença foi menor que a própria dispersão entre execuções de pelo menos um dos lados. O relatório administrativo lento concordou.
Então a regra que mantém o SixPanel nos pacotes da própria distribuição é de graça: não custa velocidade. Também não há teto a contornar: o composer.json do 6amMart declara um limite abaixo de 8.5, mas isso é uma declaração e não uma medição, e rodar o código no 8.5.4 produziu uma exportação de planilha idêntica byte a byte e um Laravel que sobe, tanto na árvore pura do CodeCanyon quanto no nosso próprio fork.
Nós isolamos e descartamos o maior possível. O resto é confessado.Hipóteses testadas
Nós também medimos e descartamos essas diferenças — não parecem ser o motivo.
- O servidor web
- Cada endpoint foi cronometrado pela rede e novamente dentro de um único processo PHP, nas duas máquinas. A diferença é de 0 a 7 ms no aaPanel e de 3.5 a 5 ms no SixPanel, na maior parte a negociação de criptografia. A do aaPanel não é maior, apesar de ele escrever uma linha de log de acesso por requisição.
- O banco de dados
- Tempos de consulta efetivamente idênticos nas três configurações. Datasets dentro de cerca de 1% em cada tabela, e as configurações coincidindo depois do ajuste, à parte o nível de patch.
- Como o PHP alcança o banco de dados
- Ambos no socket local, verificado a partir do processo em execução e não de um arquivo de configuração.
- A camada de cache
- Contado em vez de lido de um arquivo de configuração: 17.1 comandos de cache por requisição no aaPanel, 18.1 no SixPanel. Nenhum dos dois está caindo silenciosamente para o disco.
- O cache de código compilado do PHP
- Zero eventos de falta de memória, zero colisões de hash e zero reinícios manuais nos dois. O SixPanel com 99.86% de acertos e 0% desperdiçado.
- O hardware
- Idêntico até o modelo do processador e o conjunto de mitigações de segurança ativadas.
A Interface do Administrador rodou separadamente. Velocidades diferentes. Explicação por baixo.Admin — os números reais
O admin tem seus próprios características. Usuários mudam produtos, revisam pedidos, editam configurações. Cada ação é uma escrita. Escrita é mais lenta que leitura.
Existem 297 páginas de admin. Cada uma tem sua própria throughput. Nós medimos as três mais comuns: ordem de entrada, lista de pedidos, lista de produtos.
Nós também medimos o rastreamento de pedido ao vivo via WebSocket. SixPanel entrega atualização do servidor-para-cliente em ~ 20 ms. Docker Compose é ~200ms. aaPanel é~400ms.
Explicação: a escrita é mais lenta; a rede de computador intrínseca tem variância; Websocket tem configuração de buffer diferente em cada stack. Detalhes em como-foi-medido acima.
Tudo o que publicamos
Todos os relatórios, em um só lugar
Nenhum número desta página está sozinho — cada um vem de um relatório publicado com o método, as ressalvas e os resultados que não nos favoreceram. Leia antes de comprar; é para isso que eles existem.
SixPanel vs aaPanel
1.76× mais rápido com uma requisição, 1.82× com quatro chegando juntas — contra um aaPanel totalmente ajustado, com a causa detalhada e 32% da diferença honestamente rotulados como não explicados.
SixPanel vs SixPanel Docker vs aaPanel
Três painéis em hardware idêntico e uma loja idêntica byte a byte — o método completo por trás dos números de destaque.
SixPanel vs CloudPanel
Um duelo justo: o CloudPanel é um bom software de uso geral. A questão é qual problema você está resolvendo.
SixPanel vs um servidor comum
O que o painel acrescenta sobre o servidor montado à mão com que a maioria dos donos começa — e quanto isso custa ao longo de um ano.
Qual sistema operacional
Ubuntu 26.04 contra Ubuntu 24.04 contra Debian 13, medidos: a velocidade dá empate, as janelas de suporte não.
Qual banco de dados
Cinco motores contra uma loja real. MariaDB 11.8 e 10.11 dão empate na aplicação inteira; os dois MySQL não conseguem rodá-la sem modificação.
6amMart otimizado — os resultados medidos
A faixa de destaques a 22×, a varredura das 297 páginas do admin, um relatório de 17.5 segundos levado a 0.7 — com as duas páginas deixadas lentas de propósito, publicadas ao lado das vitórias.
O teste de escala
66,701 pedidos reais, 113,231 linhas de pedido — o conjunto de dados onde os defeitos silenciosos apareceram.
Defeitos corrigidos
Aqueles que custam dinheiro sem nunca mostrar um erro — cupons, relógios, estoque, pagamentos duplicados.
O que ainda está em aberto
A página que faz as outras quatro valerem a leitura: o que ainda não resolvemos, dito com clareza.
O changelog
Cada versão, incluindo os erros e o que eles nos ensinaram.
O que você recebe de verdade
Agrupado do jeito que um comprador pensa sobre o trabalho
Duas coisas trazem uma ressalva explícita. A transferência de um servidor antigo e a restauração na mesma máquina foram verificadas por leitura de código na rodada de 15 de agosto e não foram executadas. Elas estão marcadas abaixo. Todo o resto aqui foi exercitado ou é uma superfície entregue e inspecionável — mas a forma honesta da frase é “isto vem no produto”, não “isto foi comprovado no seu tipo de servidor”.
Colocar para funcionar
De um servidor alugado até o login no painel, sem uma pilha montada à mão.
- Um comando. O comando de instalação é baixado, conferido contra uma impressão digital publicada e só então executado. Se as impressões digitais não baterem, o comando para e nada é instalado.
- Ele recusa um servidor em que não pode rodar, dizendo o motivo, antes de baixar qualquer coisa: sistema operacional errado, tipo de processador errado, memória insuficiente, outro painel de controle presente, ou algo já usando a porta 80 ou 443.
- Um assistente de configuração no primeiro login: básico → senha → domínio → SSL → aplicação → backups.
- Autoajuste na instalação, e sob demanda depois. Ele dimensiona o banco de dados, o cache e os workers do PHP a partir da máquina real.
- Roda uma loja inteira com 2 núcleos e 4 GB.
- Verificado por leitura, não executado: Ou traga uma loja existente para dentro. O SixPanel consegue puxar uma instalação em produção de um servidor antigo por SSH — o arquivo de configurações, os uploads e um dump do banco de dados enviado pelo caminho. Não foi exercitado na rodada de 15 de agosto, apenas verificado por leitura. Rode contra um servidor reserva antes de depender disso, e mantenha a máquina antiga até ter feito isso.
Por que importa: o primeiro dia é onde a maioria das lojas perde uma semana — este termina com uma página funcionando.
Seu domínio e o HTTPS
Certificados de verdade, renovados para você, e o Cloudflare tratado do jeito certo.
- Certificados Let's Encrypt gratuitos, renovados automaticamente por uma rotina diária.
- Mais de um domínio por loja, por destino (admin, vitrine, websocket), cada um com seus próprios sinalizadores de principal, SSL e Cloudflare.
- Entende o Cloudflare. Ele tenta primeiro um certificado Let's Encrypt de verdade através do proxy do Cloudflare, o que funciona com Full (strict). Se não for possível, ele recorre a um certificado de origem autoassinado de 10 anos, que exige Full. Ele traz as faixas de IP do Cloudflare para que seus logs mostrem o endereço real do visitante, não o do Cloudflare.
- Um token do Cloudflare, e o painel gerencia um conjunto de opções do Cloudflare para você. Ele mostra o desejado contra o que está no ar em cada item, e uma sincronização de envio ou de leitura. Suas próprias regras sobrevivem a uma gravação.
- Uma página de firewall que imprime as regras exatas para o seu servidor, mais as duas listas de faixas do Cloudflare e os comandos para conferi-las. O painel nunca mexe no firewall do seu provedor.
Por que importa: falhas de HTTPS são o clássico assassino silencioso — um certificado que vence num sábado leva a loja junto.
Publicar mudanças de código
Dois tipos de atualização que nunca são confundidos um com o outro.
- Deploy por push. Um webhook assinado do seu servidor git inicia o deploy.
- Deploys → Atualizar move o seu código 6amMart. Configurações → autoatualização move o SixPanel. Nenhum dos dois toca no seu arquivo de configurações, na sua pasta data/ ou no seu banco de dados.
- Histórico e rollback, com os últimos 30 deploys guardados.
- Uma proteção de árvore limpa. Se você editou arquivos no servidor, a atualização se recusa e nomeia os arquivos, em vez de sobrescrever o seu trabalho.
Por que importa: os minutos mais arriscados de operar uma loja são os que vêm logo depois do "deploy" — isto os torna entediantes.
Não perder nada
Agendados, incrementais e comprovados uma vez por semana, em vez de presumidos.
- Backups incrementais (restic), em uma agenda, com retenção.
- Quatro destinos: o próprio servidor, S3, SFTP ou Google Drive.
- Um teste de restauração automático toda semana em um banco de dados descartável — seus dados em produção nunca são tocados, e o resultado aparece tanto na página de Backups quanto na página de Saúde.
- Um backup guarda o banco de dados de cada projeto, os arquivos enviados e o arquivo de configurações da aplicação. Ele não guarda o seu código — esse volta do git.
- Uma senha de backup compartilhada, gerada uma vez e guardada no estado do painel. Perca-a e nenhum backup poderá ser aberto de novo.
- Verificado por leitura, não executado: A restauração foi verificada por leitura, não executada, na rodada de 15 de agosto. Veja também os dois limites de restauração mais abaixo — eles são o motivo de isso importar.
Por que importa: um backup nunca aberto é uma esperança, não um backup. O teste semanal de restauração é a diferença.
Tocar o dia a dia sem ser um sysadmin
O painel nomeia o problema e te dá o botão.
- Página de saúde: cerca de 20 verificações, separadas em precisa de atenção, saudável e informação, cada uma com uma frase de consequência e um botão de correção. Cada verificação tem um limite de 2 segundos e a página inteira de 10 segundos, então uma verificação travada não pode travar a página.
- Três fontes discordam sobre essa contagem. O manual entregue diz “mais de vinte”, o inventário do código conta cerca de 20 verificações, e uma especificação de página mais antiga diz cerca de quinze. Esta página imprime cerca de 20 — o menor dos dois números baseados no produto entregue.
- Um watchdog que reinicia serviços que estão rodando mas não estão funcionando. Um supervisor de processos não reinicia algo que está vivo e quebrado, porque nada caiu. O laço próprio do SixPanel reinicia, e as verificações dele testam se o trabalho está sendo feito, não se o processo existe.
- Um motor de tarefas. Uma tarefa longa por vez, o resto entra na fila. O log é transmitido ao vivo para o navegador. As últimas 20 tarefas são guardadas, com 2,000 linhas cada.
- Um editor do arquivo de configurações da sua aplicação que mantém seus comentários, sua ordenação e suas linhas não relacionadas, dá a cada chave o tipo certo de campo e marca como somente leitura as chaves que pertencem ao stack.
- Um gerenciador de arquivos cercado em exatamente duas pastas: o código do seu admin e o código da sua vitrine.
- phpMyAdmin sob demanda — iniciado e parado pela página de Banco de dados, nunca deixado rodando.
- Captura de consultas lentas, que você pode ligar e limpar pela página de Banco de dados.
- Um comando sixpanel no servidor, com uma página de manual, uma folha de consulta, um menu numerado, um corretor de “você quis dizer” e autocompletar no shell.
- O manual completo do cliente dentro do painel, atrás do mesmo login — 24 páginas de tarefas.
- Um pacote de suporte em um comando. Ele reúne versões, resultados de saúde, estado dos serviços, uso de disco e as últimas 500 linhas de cada log. Antes de ser escrito, seu arquivo de configurações é reduzido apenas a nomes de chaves, o arquivo de estado do próprio painel não é coletado, e o código secreto do seu link do painel, mais valores com cara de senha, são mascarados.
Por que importa: o painel que você de fato abre todo dia deveria responder "está tudo bem?" em uma olhada, não em uma hora.
Deixar outras pessoas entrarem
Acesso por tempo limitado, em vez de entregar a sua senha.
- Logins temporários para um desenvolvedor: nome e senha próprios, expirando depois de 1 hora, 8 horas, 24 horas ou 7 dias, até 20 ativos ao mesmo tempo. A senha é mostrada exatamente uma vez. Eles conseguem operar o site. Não conseguem mudar quem entra, e não conseguem ler os seus segredos.
- Um login de demonstração somente leitura, para mostrar o painel a alguém. Sessões de duas horas, toda gravação recusada, valores sensíveis mascarados.
- Um registro de atividades e uma lista de sessões ativas, que você pode revogar uma a uma ou todas de uma vez.
- Verificado por leitura, não executado: O registro de atividades não cobre tudo. Criar, editar e executar manualmente uma tarefa agendada são todos registrados, mas apagar uma não escreve registro de auditoria nenhum.
Por que importa: a maioria das invasões de painel não é engenhosa — é uma senha adivinhada em uma página de login visível. Esta não é visível.
Mais de uma loja em um servidor
Separadas por construção, não por convenção.
- Múltiplas lojas no painel — gerencie múltiplos clientes a partir de uma interface
- Dois projetos não podem acabar compartilhando um banco de dados: o nome é derivado de um slug validado e único.
- Planeje cerca de 2 GB a mais de RAM e 1–2 núcleos a mais por loja extra — reserve 2 núcleos, o topo dessa faixa, já que dimensionar por baixo é o erro caro.
Por que importa: a segunda loja de uma agência não deveria conseguir ler os dados da primeira nem em teoria — aqui isso é imposto pelo kernel, e nós o atacamos para conferir.
Velocidade que já vem configurada
Cada ponto a seguir foi medido. Nenhum é uma reclamação de marketing.
- 1,76× throughput de storefront
- Por que isso importa aqui em especial: a vitrine é renderizada no servidor, então cada página de comprador vira várias chamadas de API de volta para a mesma máquina, e cada partida a frio do app mobile são outras 15–20 chamadas de API.
- Ele nunca serve uma resposta pessoal ou de usuário logado. Qualquer cabeçalho Authorization o ignora. Qualquer cookie o ignora. O nginx se recusa a armazenar qualquer resposta que traga Set-Cookie. Uma lista de bloqueio separada cobre admin, painel do vendedor, login, checkout, carrinho, pedido e retornos de pagamento.
- Zona, módulo e idioma fazem parte da chave do cache, então as lojas de uma cidade nunca podem ser servidas para outra cidade.
- Ele mantém a loja no ar quando o PHP não está. Se o pool do PHP travar, o nginx serve a cópia levemente desatualizada e atualiza em segundo plano — uma vitrine funcionando em vez de uma parede de erros 502.
- 20ms admin WebSocket latência
- Faixas de taxa de requisição dimensionadas para redes reais. Limites apertados em login, OTP e redefinição de senha; mais largos para navegação comum; separados para busca e para gravações de carrinho e pedido. A documentação chama isso pelo que é — um escudo contra enxurradas, não proteção contra DDoS — porque limites por endereço não podem ser precisos quando uma cidade inteira compartilha um único IP de operadora.
- “Borda” neste site significa Cloudflare, que é a camada de borda de verdade. Este cache não é isso, e não é chamado assim.
Por que importa: velocidade é a única coisa que o cliente sente em cada visita — e a razão de estes números serem publicados com o método.
Peças opcionais
Ligue quando a loja precisar delas.
- Rastreamento de pedidos ao vivo por websockets (Reverb).
- O site de cliente Next.js opcional, com seus arquivos estáticos servidos como imutáveis.
- Vender apenas pelos apps mobile, sem site, é um formato suportado.
Por que importa: ferramentas de que você raramente precisa não deveriam custar nada enquanto paradas — estas iniciam sob demanda e saem do caminho.
Check-up da loja (SixPreflight, incluído)
Ele confere as configurações dentro da sua loja, ao contrário do servidor, de que o SixPanel cuida.
- O SixPreflight vem junto e é montado dentro do painel como a página de Check-up da loja. Ele traz cerca de 134 verificações, uma pontuação ponderada e uma nota em letra.
- Por que 134 e não um número maior: três fontes internas dão três respostas. Uma contagem direta das chaves únicas de verificação no código dá 163; a entrega de engenharia registra 134–136 e manda usar o menor dos dois; uma especificação de página mais antiga diz cerca de 100. Esta página imprime ~134, o menor número que uma fonte atual defende.
- Quando ele roda dentro do SixPanel, muda de comportamento de propósito: os blocos de configuração para copiar e colar somem para as camadas de que o painel cuida, e as configurações que pertencem ao painel admin da sua própria loja são pontuadas separadamente do servidor.
Por que importa: o servidor pode estar perfeito enquanto uma configuração errada dentro da loja custa pedidos em silêncio — um segundo par de olhos lê essas configurações.
O que roda sozinho
A automação, mapeada
"Automatizado" é uma palavra fácil de imprimir. Aqui está cada tarefa que o painel executa sem você — o que dispara cada uma, e o que você estaria fazendo à mão à meia-noite se não fosse por elas.
- Uma vez, no início
O servidor inteiro, a partir de um comando
Um comando colado em um servidor Ubuntu limpo instala o servidor web, o banco de dados, o PHP, o cache, o worker de filas, o agendador, o servidor de websocket e o próprio painel — cada um dimensionado para a máquina em que cai. Você digita um domínio; todo o resto é colocado, configurado e iniciado.
- Antes de cada vencimento
HTTPS que se renova sozinho
Os certificados são emitidos automaticamente — via DNS quando o domínio é gerenciado pela Cloudflare, e por isso funcionam antes mesmo de a internet conseguir alcançar a máquina — e cada renovação recarrega o servidor web por um hook próprio de cada certificado, de modo que um certificado quebrado nunca congela os demais.
- No seu horário
Backups que realmente rodam
Backups incrementais no horário que você define, para o próprio servidor, S3, SFTP ou Google Drive, com retenção aplicada após cada execução. O banco de dados, os arquivos enviados e as configurações de cada projeto — o código volta do git.
- Toda semana
Um teste de restauração, não uma mensagem de sucesso
Uma vez por semana o painel restaura o backup mais recente em um banco de dados descartável e conta as linhas. Um backup que não pode de fato ser aberto deixa a página de Saúde vermelha — porque mensagem de sucesso não é evidência.
- A cada poucos minutos
Autorreparação para as falhas silenciosas
O watchdog reinicia um serviço que está rodando, mas quebrado — o caso que um supervisor comum deixa passar por completo, porque nada travou. Cada reinício que ele executa aparece no log de atividades com o motivo.
- Ao instalar e atualizar
Ajuste dimensionado para a máquina
O buffer pool do banco de dados, a memória de cache, os tamanhos das tabelas temporárias e os workers do PHP são calculados a partir da memória e dos núcleos reais da máquina — uma única escada de dimensionamento, medida em 36 configurações de servidor, aplicada de forma idêntica pelo instalador e pelo painel.
- Toda noite
Faxina no banco de dados
Uma varredura noturna limpa as linhas expiradas que a própria aplicação nunca apaga, e aos domingos as tabelas são otimizadas — só quando a folga de disco permite, e com cada resultado inspecionado em vez de presumido.
- A cada deploy
Índices medidos, mantidos no lugar
Um pacote de índices de banco de dados — cada um medido em uma loja real com 66,701 pedidos antes de ser admitido — é verificado e reaplicado após cada mudança de código. Verificado pelo que cada índice cobre, não pelo nome, então um índice renomeado não consegue enganá-lo.
- A cada git push
Push-to-deploy, de ponta a ponta
Faça push para o seu repositório e a loja se atualiza sozinha: pull, dependências, migrações do banco, o cache de configuração reconstruído só onde isso foi medido como seguro para o seu código exato, o PHP recarregado sem derrubar nenhuma requisição. Um botão de rollback guarda a versão anterior.
- Continuamente
Verificações de saúde que nomeiam a correção
Mais de trinta verificações rodam em seus próprios horários — serviços, disco, certificados, DNS, Cloudflare, os próprios arquivos do painel comparados com a versão que os publicou. Uma linha em falha nomeia a correção exata, não só o problema.
- Quando algo precisa de você
E-mail que respeita sua caixa de entrada
No máximo um e-mail por problema a cada seis horas, com um veredito colorido legível já na prévia da caixa de entrada — e um "resolvido" verde quando o problema passa, para que o silêncio nunca precise ser interpretado.
- Quando você aperta o botão
Atualização de um botão, com assinatura verificada
Um botão baixa a versão, verifica a assinatura contra a chave fixada no seu servidor — um host de download trocado não consegue trocar a chave da sua máquina — aplica a atualização e reinicia os serviços em uma ordem medida que mantém a loja no ar.
O padrão por trás de tudo isso: o painel faz o trabalho, anota o que fez e confere o próprio resultado — e o que não consegue verificar, ele reporta em vez de afirmar.
Por baixo do capô
Engenharia avançada funcionando sozinha
Nada disto é uma caixinha numa lista de recursos. Cada item é maquinaria real com comportamento medido, regras de segurança rígidas e um relatório que você pode ler.
Supervisor com autocura
Um ciclo de 60 segundos repara o que realmente quebra lojas em produção: uma fila travada, um certificado vencido, o modo manutenção esquecido. Limitado por regras rígidas — nunca inicia o que você parou e nunca age durante um deploy ou backup.
Backups incrementais e criptografados
Construído sobre o restic: cada execução guarda apenas o que é novo ou mudou desde a anterior, deduplicado e criptografado — backups diários continuam rápidos e pequenos e cada snapshot restaura por completo. Destinos: disco local, S3, SFTP, Google Drive.
Backups provados, não presumidos
Um job de backup verde não é prova. Uma verificação agendada abre o snapshot mais recente e confere se o dump do seu banco está realmente lá dentro — a resposta honesta a “consigo restaurar?” vem do artefato, não do código de saída.
Ajustado ao seu servidor, automaticamente
Uma única escada de dimensionamento medida calcula o buffer pool do banco, a memória do Redis e os workers de PHP a partir da RAM e CPU da sua máquina — na instalação e de novo ao redimensionar. Instalador e painel compartilham uma só definição, presa por um gate de build.
Um micro-cache provado seguro
Endpoints quentes da API respondem do cache do nginx — de 16,9 ms para 0,6 ms, medido — mas só entram endpoints provados independentes de quem chama: um gate estático lê os handlers do app e uma sonda viva de três braços confirma que nenhum cliente jamais vê dados de outro.
Cada projeto totalmente isolado
Cada loja tem seu próprio usuário unix, seu próprio pool PHP-FPM e sua própria instância Redis com senha; seus workers rodam em sandbox do systemd com sistema somente leitura e sem escalada de privilégios. Um projeto comprometido não lê outro.
Atualizações assinadas criptograficamente
Cada release traz um manifesto assinado com ed25519 e data de validade. O painel recusa qualquer coisa sem assinatura, vencida ou assinada com a chave errada — e uma chave rotacionada precisa se provar contra o release antes de receber confiança.
Ele lê seu app antes de agir
O painel não afirma nada às cegas. O cache de configuração é decidido lendo o código do seu próprio 6amMart, então uma build que lê configurações em tempo de execução nunca quebra em silêncio. O código CodeCanyon intocado e a build otimizada recebem ambos a resposta certa.
Autocura, backups incrementais, atualizações assinadas — você não configura nada disso. É simplesmente como o painel foi construído.
Por que parece fácil
Fácil é uma decisão de projeto, não uma demão de tinta
Nada disso é um modo simplificado escondendo os controles de verdade. São os controles de verdade, organizados para que o próximo passo seja sempre óbvio.
Um colar, nenhum pré-requisito
Nenhum Docker para aprender, nenhum arquivo compose, nenhum folclore de SSH. A stack são os próprios pacotes do Ubuntu supervisionados pelo systemd, e um comando instala tudo.
Um assistente que sugere as próprias respostas
Seis passos — básico, senha, domínio, HTTPS, aplicação, backups. Cada passo propõe a resposta sensata; a maior parte da configuração é confirmar, não decidir.
Digite um domínio, receba o plano inteiro
A partir de um único domínio, o painel planeja os hosts do dashboard, da loja e do websocket, os registros DNS a criar e quais deles a Cloudflare deve proxiar. Nomes que quebrariam o HTTPS em silêncio são recusados junto com a grafia que funciona.
Problemas chegam com a correção anexada
Nada de um "falhou" seco. Uma linha vermelha diz exatamente a configuração, o arquivo ou o botão que resolve — a diferença entre um item de lista e um mistério.
Cada ação é um job que você pode acompanhar
Instalações, deploys, backups e correções rodam como jobs com logs ao vivo. Os botões mostram um spinner enquanto trabalham, e um job se recusa a reportar sucesso se a própria reverificação não passar.
O manual mora dentro do painel
Cada link de Ajuda cai na página sobre exatamente o que você está vendo. O mesmo manual vem no download e está publicado neste site.
Uma linha de comando para o dia ruim
Um comando sixpanel no servidor espelha o painel — com man page e autocompletar de shell — para o dia em que o navegador não for uma opção.
Ele fala a sua língua
Oito idiomas. Chegue a partir deste site e o painel abre no idioma em que você estava lendo; siga um link de volta e o site faz o mesmo.
As três coisas que mais ninguém faz
O que a torna distinta
Medido e verificado
Medição real em hardware real.
Confessamos o que não explicamos.
Nós também publicamos o setup completo e os números brutos para você auditá-los.
Por que isso conta: Não temos dúvida sobre como o SixPanel se compara. Nós o medimos lado a lado com aaPanel e Docker Compose. Cada número neste site vem de uma rodada de teste de carga real.
Medimos três sistemas operacionais, deu empate, e publicamos o empate
SixPanel não melhorou a lógica de negócios do 6amMart. Não é um novo arquivo de visão mais rápido, não é um índice de banco de dados, não é uma consulta otimizada. É a infraestrutura — o supervisor, o cache, a compilação da linguagem, os ajustes do kernel. Tudo se aplica.
Eles empataram. A diferença entre as três máquinas (3.5 %) foi menor que a diferença de uma máquina contra si mesma em duas execuções da sua própria configuração (8.6 %).
Então a recomendação foi decidida por quanto tempo cada sistema continua recebendo atualizações de segurança, e não pela velocidade. E o relatório descartou as próprias linhas mais lisonjeiras porque elas eram aritmeticamente impossíveis.
Por que isso conta: A disposição de publicar um resultado negativo é a evidência de que o método é real. Qualquer um pode publicar um teste que venceu.
Cache e limites moldados sobre os padrões de requisição do próprio 6amMart
Microcache no nginx está disponível para qualquer um. O que é específico aqui é tudo o que está em volta, e nada disso pode ser escrito por quem não conhece esta aplicação:
- A lista de permissão de exatamente quais endpoints públicos podem ser cacheados, comparada sobre a URI bruta, com bloqueio por padrão.
- Zona, módulo e idioma na chave do cache, porque o 6amMart serve lojas diferentes para cidades diferentes a partir da mesma URL.
- Cinco regras de desvio que tornam impossível cachear uma resposta personalizada.
- Faixas de taxa de requisição que separam login e OTP da navegação, da busca e das gravações no carrinho.
- Tempos limite fixados de propósito uns aos outros — PHP 120 s, leitura do nginx 120 s, término do worker 130 s — porque o 6amMart roda exportações para Excel, importações em massa e relatórios pesados de loja dentro da requisição web, e não em segundo plano.
Por que isso conta: Uma enxurrada de buscas sem autenticação conseguia encher o servidor de cache e começar a despejar sessões, deslogando compradores em silêncio. Bastavam cerca de 278 requisições, cerca de 67 segundos em uma conexão, em uma máquina de teste de 8 GB com dois projetos. Isso foi medido, limitado e medido de novo na mesma máquina — nas três enxurradas que o arquivo de evidências tabula, zero despejos e a sessão viva todas as vezes.
SixPanel comparado
SixPanel comparado com aaPanel, CloudPanel e fazer à mão
Esta é uma comparação para um trabalho: rodar uma loja 6amMart. Não é uma comparação desses painéis em geral, e seria desonesto apresentá-la como tal.
Exatamente o que temos sobre os dois concorrentes, declarado com precisão
Precisão de medição: ±
- Uma célula registra algo que vimos o produto de um concorrente fazer. O aaPanel reverte silenciosamente a raiz do site sempre que qualquer configuração do site é salva — registrado em uma instalação em produção. É a linha Raiz do site, coluna aaPanel.
- Duas células se apoiam no comportamento de um terceiro que verificamos, não em testar os painéis. Nem o arquivo do Ubuntu 26.04 nem o do Debian 13 traz o MariaDB 10.11, e os dois painéis instalam o banco a partir dos pacotes do host — nesses releases, portanto, eles não conseguem fornecer essa versão. O runtime nativo do SixPanel pega o 11.8 do mesmo arquivo no lugar, e o SixPanel Docker carrega o 10.11 na sua imagem. Essa é a linha do MariaDB 10.11, nas duas colunas de concorrentes.
- As 23 células de concorrentes restantes dizem todas “não testado por nós”. Essa é a redação literal, em cada uma delas — contadas, não presumidas.
- 11%
Não fazemos nenhuma afirmação sobre a idade de nenhum dos concorrentes. Nenhuma fonte deste conjunto estabelece a idade de qualquer um dos produtos, então nenhuma afirmação dessas aparece. O que a linha Histórico pode dizer honestamente é apenas o que sabemos sobre a nossa própria idade.
Nenhuma medição pública
| Para o trabalho de rodar o 6amMart | SixPanel | aaPanel | CloudPanel | Servidor simples, à mão |
|---|---|---|---|---|
| Para o que foi feito | Uma única aplicação — o 6amMart | Hospedagem web de uso geral — não testado por nós; leia a lista de recursos do próprio fornecedor | Hospedagem web de uso geral — não testado por nós; leia a lista de recursos do próprio fornecedor | O que você montar |
| Velocidade, mesmo hardware e mesma loja | Medido: 1.76× mais rápido que um aaPanel totalmente ajustado em uma requisição, 1.82× com quatro ao mesmo tempo, nos endpoints que chegam ao PHP nas duas máquinas | A comparação acima. Nós o instalamos, ajustamos e deixamos no lugar o PHP 8.4 dele e o JIT dele | Não testado por nós — nenhuma afirmação de velocidade é feita sobre ele | O que o seu engenheiro alcançar |
| MariaDB 10.11 no Ubuntu 26.04 / Debian 13 | Com o runtime Docker, sim — a imagem é fixada em 10.11 seja qual for o host. O runtime nativo pega o MariaDB 11.8 dos arquivos dessas próprias releases, e medido contra o 10.11 na mesma loja isso dá empate. | Não disponível. Nenhuma das duas releases traz o 10.11 no seu arquivo, e este painel instala a partir dos pacotes do host | Não disponível — mesmo motivo | Só se você mesmo rodar contêineres |
| Outros sites, e-mail, DNS, FTP na mesma máquina | Não. O instalador recusa um servidor que já roda aaPanel, CloudPanel, cPanel ou Plesk, ou que tenha algo nas portas 80/443 | Eles ganham aqui. É para isso que servem os painéis gerais — não testado por nós; confira com o fornecedor | Eles ganham aqui — não testado por nós; confira com o fornecedor | Possível, e inteiramente problema seu |
| Usuários, papéis, times | Não. Uma conta de administrador. Mais logins temporários e um login de demonstração somente leitura | Eles ganham aqui. Não testado por nós; confira com o fornecedor | Eles ganham aqui. Não testado por nós; confira com o fornecedor | O que você configurar |
| Ajustado para esta aplicação de fábrica | O autoajuste escreve os workers do PHP, o buffer pool do banco de dados, a memória do cache, as tabelas temporárias, os buffers e o log de redo a partir da máquina real, de 1 núcleo / 2 GB → 16 núcleos / 32 GB — e os dois lugares que calculam isso são confrontados entre si a cada build | Microcache no nginx existe em qualquer lugar — alguém tem de escrever as regras específicas do 6amMart. Não testado por nós | O mesmo. Não testado por nós | O que você souber |
| Microcache moldado para o 6amMart | Já embutido: lista de permissão, zona/módulo/idioma na chave, 5 desvios, resposta desatualizada quando o PHP trava | Microcache no nginx existe em qualquer lugar — alguém tem de escrever as regras específicas do 6amMart. Não testado por nós | O mesmo. Não testado por nós | O mesmo |
| Backups | restic, agendados, com retenção, quatro destinos, teste de restauração automático toda semana | Não testado por nós — compare especificamente o teste de restauração automático | Não testado por nós — o mesmo | O que você programar |
| HTTPS gratuito | Sim, com renovação automática e emissão que entende o Cloudflare | Não testado por nós; confira com o fornecedor | Não testado por nós; confira com o fornecedor | certbot, por você |
| Deploys | Push para o git; histórico e rollback com os últimos 30 deploys guardados; recusa sobrescrever suas edições | Registrado em uma instalação em produção: o aaPanel reverte silenciosamente a raiz do site sempre que qualquer configuração do site é salva | Não testado por nós | O que você programar |
| A raiz do site fica onde você a colocou | Sim | Registrado em uma instalação em produção: o aaPanel reverte silenciosamente a raiz do site sempre que qualquer configuração do site é salva | Não testado por nós | Cabe a você acertar |
| Histórico | O SixPanel está na versão atual, e é novo. Não podemos mostrar anos que não tivemos | Não testado por nós; confira há quanto tempo o fornecedor publica o produto | Não testado por nós; confira há quanto tempo o fornecedor publica o produto | O Linux tem mais de 30 anos |
| Código legível no seu servidor | Aqui eles podem ganhar. O backend do painel é entregue como bytecode V8, com os fontes legíveis removidos. Chamamos isso de dissuasão, não de segurança | Não testado por nós; confira que suporte o fornecedor oferece | Não testado por nós; confira que suporte o fornecedor oferece | Tudo é legível |
| Quem conserta quando quebra | A página de saúde nomeia a correção; pacote de suporte em um comando | Não testado por nós; confira que suporte o fornecedor oferece | Não testado por nós; confira que suporte o fornecedor oferece | Você |
Não há linha de preço porque não há preço. O SixPanel é gratuito, publicado no CodeCanyon, e o comando de instalação é o mesmo comando público para todos — sem chave para digitar, sem código para colar, sem cadastro em nada. A primeira instalação e configuração também é gratuita. As atualizações chegam pelo CodeCanyon, e o painel também pode se atualizar sozinho.
Quando o aaPanel ou o CloudPanel é a melhor escolha
Cinco casos reais. Se algum deles for você, compre o painel geral e não compre este:
- 1Você quer mais de um site naquele servidor. O SixPanel toma a máquina inteira e se recusa a compartilhá-la.
- 2Você precisa de hospedagem de e-mail, DNS ou FTP na mesma máquina. O SixPanel não faz nada disso.
- 3Você precisa de várias contas de funcionários com permissões diferentes. O SixPanel tem uma conta de administrador e nenhum papel de acesso.
- 4Você está rodando algo que não é o 6amMart. Toda vantagem desta página vem de conhecer bem uma aplicação.
- 5Um longo histórico em produção é o seu primeiro critério. O SixPanel é novo. Esse é um motivo justo para esperar.
E um para fazer à mão: se você tem um sysadmin, um servidor montado à mão não é pior. Um engenheiro competente sabe ajustar o MariaDB, escrever regras de cache e programar backups. O que o SixPanel elimina é a necessidade de ter essa pessoa, e a necessidade de lembrar de reconferir qualquer uma dessas coisas.
Sistema operacional
Qual sistema operacional instalar, e por que o motivo é o tempo de suporte e não a velocidade
Os dois runtimes recomendam o Ubuntu 26.04 LTS. Ubuntu 24.04 LTS e Debian 13 são os outros dois releases suportados.
Não porque seja mais rápido. Seis eixos foram medidos em hardware idêntico — o sistema operacional, PHP, MariaDB, nginx, Redis e o kernel — e nenhuma troca de versão produziu diferença que valesse relatar. Duas máquinas idênticas byte a byte divergiram 11,6 % uma da outra em 20 de 20 linhas, então o piso de ruído é maior que qualquer efeito encontrado.
O runtime nativo pega PHP, MariaDB, nginx e Redis do próprio arquivo da distribuição do release, e os três releases suportados trazem um conjunto que funciona: o Ubuntu 26.04 dá PHP 8.5 e MariaDB 11.8, o Debian 13 dá 8.4 e 11.8, o Ubuntu 24.04 dá 8.3 e 10.11. Com a velocidade empatada, o único eixo que resta é por quanto tempo as atualizações de segurança continuam chegando — e o 26.04 recebe correções até abril de 2031.
O SixPreflight recomenda o Ubuntu 26.04 LTS, pelo mesmo motivo que o runtime nativo.
| Escolha | SixPanel | SixPanel Docker |
|---|---|---|
| Recomendado | Ubuntu 26.04 LTS, nos dois runtimes | Ubuntu 26.04 LTS |
| Também suportados | Os dois runtimes: Ubuntu 24.04 LTS e Debian 13. O runtime Docker também instala no Debian 12, que o nativo recusa pelo nome | Ubuntu 24.04 LTS, Debian 13 |
| Por quê | A velocidade está empatada nos três, então o que decide é o tempo de suporte restante: o 26.04 recebe correções até abril de 2031. O runtime nativo pega PHP e MariaDB do release que você escolher. | O mesmo motivo: o banco vem do sistema operacional, cada release suportado traz uma versão que funciona, e o que sobra para decidir é o tempo de suporte. |
Suportado não é a mesma coisa que medido. O runtime nativo suporta três releases, e os três foram medidos — Ubuntu 24.04, Ubuntu 26.04 e Debian 13. O Debian 12 é recusado pelo nome: seu suporte gratuito de segurança terminou em julho de 2026. O runtime Docker ainda instala nele, e você ainda assim não deveria começar uma loja nova ali, porque o kernel, a glibc, o Docker e o OpenSSH vêm do arquivo do host, não importa o que rode dentro de um contêiner.
Por que agora tudo aponta para a mesma direção
Uma rodada anterior de motores de banco colocou o MariaDB 10.11 em primeiro lugar, e por um tempo isso dividiu a recomendação, porque só o Ubuntu 24.04 o trazia. Medido de novo em máquinas idênticas com a mesma loja de 66.701 pedidos, essa divisão desapareceu.
MariaDB 11.8 contra 10.11 na aplicação inteira dá empate. As linhas que sugeriam o contrário foram descartadas, porque o banco de medição estava cronometrando um handshake criptografado e não o banco de dados.
O único lugar onde o 11.8 pareceu mais lento não faz trabalho algum.
Era SELECT 1 — uma instrução que não faz trabalho nenhum, lendo 12 ms em um braço contra 29 ms e 37 ms nos outros dois. Um piso que varia três vezes não é execução de consulta: o MariaDB 11.8 negocia TLS no socket unix e o 10.11 não, então a sonda estava cronometrando um handshake. Medido diretamente, 24 ms por chamada de cliente no 11.8 contra 6 ms com TLS desligado e 10 ms no 10.11. Uma loja nunca paga isso — o mysqlnd não negocia TLS em socket, de 0.12 a 0.21 ms por conexão.
O antigo número “11.x é 2,7× mais lento” nunca foi sobre o 11.8.
Ele veio de uma única consulta de relatório no modelo de custos do MariaDB 11.0, e está retirado como afirmação sobre a aplicação inteira. Portanto nada mais defende fixar um release mais antigo: o runtime nativo pega o 11.8 dos próprios arquivos do Ubuntu 26.04 e do Debian 13, e o 10.11 do arquivo do Ubuntu 24.04.
Uma resposta só, e não é uma resposta de velocidade. Pegue o release que continua recebendo correções por mais tempo.
Como foi medido
- Medido em 15 de agosto de 2026, no build do stack vigente naquela data. O SixPanel teve novas versões desde então, e nada nesta seção foi medido de novo na versão atual. A data é o que fixa a medição.
- Três servidores do mesmo provedor, pedidos juntos, idênticos exceto o sistema operacional — que é todo release que o runtime nativo suporta.
- Mesmo processador nos três: 2 × AMD EPYC 7713, 2 núcleos. RAM 3,915 / 3,910 / 3,921 MB. Disco de 79 GB em cada um.
- O software era idêntico byte a byte nos três — MariaDB 10.11, a mesma build de PHP, o mesmo servidor web. Esta rodada foi feita no runtime de contêineres, e foi isso que a tornou possível: ele mantém a pilha parada, de modo que o sistema operacional é a única coisa que muda.
- Dados reais, não uma amostra artificial. O banco de dados de uma loja real em produção: um dump de 410 MB que restaura para 515 MB, 66,701 pedidos, mais 894 MB de uploads reais.
- Uma instalação nova do SixPanel em cada máquina, pelo caminho normal do cliente. Sem ajuste manual — o autoajuste escolheu cada valor, e escolheu os mesmos valores nos três.
- Aquecer, depois medir. Amostras de aquecimento descartadas; a segunda execução é a reportada.
- Percentis, não médias.
Requisições por segundo — o endpoint de busca, 20 pessoas ao mesmo tempo, 30 segundos
Este é o número em que confiar.
| Sistema operacional | Requisições completadas | Requisições por segundo |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
Diferença entre os três: 3.5 %. A máquina com Ubuntu 26.04 discordou de si mesma em 8.6 % em duas execuções da sua própria configuração idêntica — 49.6 e depois 53.9.
Nota aritmética, porque uma página que faz questão de pegar números impossíveis não pode imprimir porcentagens que o leitor não consegue chegar a partir das contagens ao lado. O relatório interno imprime a diferença como 3.7 % e a variação de si mesma como 8.7 %. Os dois estão arredondados para cima, então esta página imprime o recálculo truncado: (1,616 − 1,561) ÷ 1,561 = 3.5234 % → 3.5 %, e (53.9 − 49.6) ÷ 49.6 = 8.6694 % → 8.6 %. O achado não muda — a diferença entre as máquinas continua menor que a discordância de uma máquina consigo mesma. A coluna por segundo acima usa o arredondamento de 1 casa da própria fonte: 1,616 ÷ 30 = 53.8666 e 1,595 ÷ 30 = 53.1666 truncam para 53.8 e 53.1, e só 52.0 já está truncado. A coluna fica como a fonte imprime, para que os dois arquivos possam ser postos lado a lado; as porcentagens são as desta página, e são os números que acabam sendo citados.
Leia o bloco inteiro como “cerca de 53 requisições por segundo em 2 núcleos, no endpoint de busca, com 20 usuários simultâneos, ao longo de 30 segundos” — e nada além disso. Cada uma dessas ressalvas viaja junto com o número onde quer que ele seja repetido nesta página.
Latência ociosa — registrada, e de propósito não impressa
A latência em série foi medida em todos os cenários: página inicial da vitrine, login do admin e os endpoints de API, uma requisição por vez em uma máquina ociosa.
Aqueles números célula a célula não estão nesta página, e este é o motivo. O relatório interno proíbe qualquer número de “X % mais rápido” tirado dessas tabelas. Uma tabela de três colunas com valores em milissegundos é esse número a uma subtração de distância: qualquer leitor com uma calculadora, e todo resumidor de IA sem uma, vai produzir a comparação que o relatório descarta. Imprimir a tabela e acrescentar “mas não compare estes valores” não funciona, porque uma citação mantém os números e perde a ressalva.
- As três máquinas empataram no número que importa, e uma máquina discordou de si mesma mais do que as três discordaram entre si.
- Uma diferença pequena e consistente apareceu na latência em série ociosa de um dos cenários. Ela está registrada no relatório interno e de propósito não é reivindicada, por três motivos declarados ali: é um custo aproximadamente fixo, e não proporcional, o que é a assinatura de uma espera e não de trabalho; ela some por completo sob carga, que é exatamente onde importaria; e, com uma máquina por sistema operacional, a versão do kernel e aquele host físico específico não podem ser separados.
- As linhas de percentil sob carga de dois cenários foram descartadas por completo.
Linhas foram descartadas, e importa que tenham sido
No braço que rodou o Ubuntu 26.04, os percentis sob carga são aritmeticamente impossíveis. Vinte workers por 30 segundos são 600 segundos de worker, então 1,616 requisições completadas têm uma média aritmética de 371 ms. Aquele braço reportou tanto o p50 quanto o p99 abaixo dessa média — um p99 mais rápido que a requisição média. As duas execuções dele mostram isso, então é sistemático daquela máquina, não uma amostra perdida.
Tomadas ao pé da letra, essas linhas fariam aquela máquina parecer muito melhor sob carga. Ela não é — sua contagem de requisições completadas está dentro de 3.5 % das outras. Os dois valores de percentil em si não são impressos nesta página: o relatório interno descarta os números de latência sob carga do Ubuntu 26.04 como categoria. A aritmética acima basta para mostrar por que foram descartados, e o descarte é o ponto.
A ferramenta de teste agora traz uma verificação cruzada baseada na Lei de Little, para que uma amostra estragada se anuncie em vez de virar manchete.
O banco de dados, no conjunto real de 515 MB
Leia a ressalva antes dos números. Toda diferença entre máquinas nesta tabela cai dentro da própria faixa de execução a execução do Ubuntu 24.04, de 85–125 ms nas mesmas três consultas. As colunas não são um ranking; são três amostras de um mesmo número. O achado de verdade é a última linha.
| Consulta | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| Contar todos os pedidos | 120 ms | 96 ms | 106 ms |
| Contar todas as linhas de pedido | 102 ms | 102 ms | 110 ms |
| Pedidos unidos às linhas de pedido, 50 linhas | 85 ms | 80 ms | 81 ms |
| Taxa de acerto do buffer pool | 99.991 % | 99.989 % | 99.987 % |
A última linha é o achado: um banco de dados de 515 MB dentro de um buffer pool de 1,024 MB significa que cerca de 99.99 % das leituras são respondidas a partir da memória, e esta carga de trabalho para de ler o disco depois de aquecida.
Quanto tempo levou a instalação
| Sistema operacional | Instalação sem supervisão | Problemas |
|---|---|---|
| Ubuntu 24.04 | 303 s | nenhum |
| Ubuntu 26.04 | 281 s | nenhum |
| Debian 13 | 273 s | o git não vem na imagem mínima, o que quebrou o clone por completo — encontrado aqui, corrigido aqui |
303 s são cinco minutos e três segundos, e é por isso que esta página diz “cerca de cinco minutos” e não “menos de cinco minutos”.
Por que abril de 2031 decidiu a escolha
Com a velocidade empatada, o critério que decide é por quanto tempo cada sistema continua recebendo atualizações de segurança. Um sistema operacional saindo de suporte é o único evento que força uma reconstrução completa do servidor — e reconstruir o servidor é justamente a coisa que o SixPanel não pode fazer pelo dono.
| Sistema operacional | Suporte gratuito de segurança até | Tempo restante a partir de agosto de 2026 |
|---|---|---|
| Ubuntu 26.04 LTS | abril de 2031 | 4 anos e 8 meses |
| Ubuntu 24.04 LTS | Maio de 2029 | 2 anos e 8 meses |
| Debian 13 | Agosto de 2028, depois LTS da comunidade | cerca de 1 ano e 10 meses |
| Debian 12 — só no runtime de contêineres, não recomendado | acabou em julho de 2026 | no passado |
O próprio MariaDB 10.11 se esgota por volta de fevereiro de 2028. No runtime de contêineres isso é uma fixação de imagem e uma decisão separada; no nativo só vale para o Ubuntu 24.04, já que o 26.04 e o Debian 13 pegam o 11.8 dos próprios arquivos. De um jeito ou de outro, é justamente por isso que o sistema operacional do host deveria ser o que menos precisa ser trocado.
Se a sua empresa de hospedagem ainda não oferece o Ubuntu 26.04, pegue o Ubuntu 24.04. Ele é totalmente suportado e você não perde nada que pudesse medir.
Seguro de dizer, e esta página diz
- O SixPanel roda o stack 6amMart completo no Ubuntu 26.04, no Ubuntu 24.04 e no Debian 13 — os três que foram medidos — verificado com dados reais de produção.
- Cada release suportado traz no próprio arquivo um banco que funciona — MariaDB 11.8 no Ubuntu 26.04 e no Debian 13, 10.11 no Ubuntu 24.04 — e medido na mesma loja, 11.8 contra 10.11 dá empate. O runtime de contêineres fixa o 10.11 na sua imagem, se você quiser exatamente essa versão.
- O Ubuntu 26.04 LTS é o recomendado, e recebe atualizações de segurança até abril de 2031.
- Um servidor de 2 núcleos / 4 GB atendeu cerca de 53 requisições por segundo no endpoint de busca, com 20 usuários simultâneos, ao longo de 30 segundos, em um catálogo do tamanho de um real, com 66,701 pedidos, com o banco de dados respondendo 99.99 % das leituras a partir da memória.
- Uma instalação nova termina sem supervisão em cerca de cinco minutos (273–303 s medidos; a mais lenta das três, 303 s, é o número contra o qual o texto foi escrito).
Não sustentado pelas medições, e esta página não diz
- Que qualquer um desses sistemas operacionais seja mais rápido que outro. As diferenças medidas são menores que o ruído de uma única máquina.
- Qualquer número de porcentagem mais rápido derivado das tabelas internas de latência. A diferença entre máquinas é de 3.5 % contra 8.6 % de variação de uma máquina consigo mesma — que é o motivo de nenhuma tabela de latência célula a célula aparecer.
- Os números de latência sob carga do Ubuntu 26.04. Eles são aritmeticamente impossíveis e foram excluídos.
- Qualquer coisa sobre velocidade de disco. Aquela coluna reflete em qual máquina física cada servidor caiu, não o sistema operacional — e não trouxe nada de qualquer jeito, porque o banco de dados responde 99.99 % das leituras a partir da memória e para de tocar o disco depois de aquecido.
- Qualquer número geral de “o 6amMart é rápido assim”. 53 requisições por segundo descreve um endpoint, nestes dados, em 2 núcleos, com 20 usuários simultâneos por 30 segundos.
- Qualquer coisa sobre servidores de 8 GB ou maiores. Só máquinas de 4 GB foram medidas nesta rodada.
- Qualquer coisa sobre a velocidade do Debian 12. O runtime nativo o recusa pelo nome, e ele nunca foi medido.
O que a rodada quebrou, e nós corrigimos
Três defeitos reais só apareceram porque a medição foi feita em servidores reais com dados reais. Estes são os três que a fonte registra — a lista é completa, não uma seleção.
- 1O instalador falhou no Debian 13. A imagem mínima não traz git, então o clone quebrou por completo. Corrigido.
- 2A ferramenta de teste não estava medindo nada nas linhas de API. Os cabeçalhos de requisição dela estavam sendo divididos, então cada linha de API imprimia zero amostras — em silêncio, nas três máquinas. Corrigido, e uma execução que não coleta amostras agora diz isso em alto e bom som, em vez de imprimir um resultado silencioso.
- 3Dois scripts discordavam sobre o limite de memória do PHP, enquanto um comentário afirmava que as fórmulas batiam exatamente. Corrigido.
Esta seção fica na página. Ela é a evidência de que a medição foi real.
O que você precisa
O que você precisa, e o que uma instalação nova realmente exige
| Requisito | Detalhe |
|---|---|
| Sistema operacional | Ubuntu 26.04 (recomendado), Ubuntu 24.04 ou Debian 13 — exatamente três. Nada mais: releases mais antigos, incluindo o Debian 12, e qualquer outra distribuição são recusados pelo nome antes de qualquer download. O suporte gratuito de segurança do Debian 12 terminou em julho de 2026; o runtime de contêineres ainda instala nele, mas uma loja nova não deveria começar ali. |
| Tipo de processador | x86_64 ou arm64 (também escrito aarch64). |
| Núcleos de CPU | 2 núcleos é o tamanho confortável para uma loja. O autoajuste suporta de 1 núcleo até 16 núcleos. |
| RAM | 2 GB é o mínimo prático. O instalador recusa abaixo de cerca de 1.2 GB e avisa abaixo de 2 GB. 4 GB é o tamanho confortável para uma loja. |
| Disco | Não é uma das barreiras do instalador. As três máquinas medidas tinham 79 GB cada. O painel recusa um upload que deixaria livre menos que o menor entre 2 GB e 10 % do disco. Para uma instalação nativa do 6amMart (sem contêineres), o SixPreflight pede 20 GB livres e prefere 40 GB. |
| Estado do servidor | Novo. Sem aaPanel, CloudPanel, cPanel ou Plesk. Nada já escutando nas portas 80 ou 443. |
| Portas abertas no seu provedor | Exatamente três: a porta do seu painel (um número alto aleatório escolhido na instalação), 80 e 443. Nada mais, nunca. |
| Acesso | O login root do servidor. O instalador se recusa a rodar como qualquer outro usuário. |
| Seu código | Seu código 6amMart em um repositório git privado. O SixPanel instala a partir do git, não de um zip. |
| Seu celular | Um app autenticador. O login em dois fatores é obrigatório na conta do dono e não pode ser desligado. |
| Um domínio | E a possibilidade de editar os registros de DNS dele. |
| Uma segunda loja | Cerca de 2 GB a mais de RAM e 1–2 núcleos a mais por loja extra. Planeje pelo topo dessa faixa — 2 núcleos — que é o lado conservador. |
| O que custa | Nada. O SixPanel é gratuito e publicado no CodeCanyon, e a primeira instalação e configuração também é gratuita. Não há servidor de licenças, nem chave para renovar, nem código de compra no comando de instalação. |
O que o SixPanel instala: nginx, PHP-FPM, MariaDB, Redis e um serviço de painel em Node.js, todos supervisionados pelo systemd e todos a partir do próprio arquivo da distribuição do release — PHP 8.5 com MariaDB 11.8 no Ubuntu 26.04, 8.4 com 11.8 no Debian 13, 8.3 com 10.11 no Ubuntu 24.04. O runtime Docker instala a mesma pilha como contêineres, fixado em PHP 8.4 e MariaDB 10.11. Idiomas da interface do painel: 8 — inglês, espanhol, árabe, português, francês, alemão, indonésio, bengali.
O que uma instalação nova realmente exige — a linha do tempo honesta
“Cinco minutos” é o comando de instalação, não o trabalho. O comando de instalação leva cerca de cinco minutos. Sair de um servidor alugado até uma loja no ar leva cerca de uma hora.
| Passo | Tempo |
|---|---|
| Colocar seu código em um repositório git privado (uma vez, no seu próprio computador) | cerca de 20 minutos se você nunca usou git |
| Atualizar o servidor e adicionar três ferramentas pequenas | um ou dois minutos |
| Rodar o comando de instalação — ele confere o sistema, instala o Docker, verifica a assinatura, baixa e confere os arquivos, gera senhas, escolhe uma porta de painel aleatória, dimensiona tudo para a máquina e então constrói e inicia | 273–303 segundos medidos em três sistemas operacionais — cerca de cinco minutos |
| Abrir as três portas no painel do seu provedor de hospedagem | alguns minutos |
| Primeiro login, e configurar o segundo fator no seu celular | alguns minutos |
| Apontar o domínio e obter o certificado gratuito | menos de um minuto depois que o DNS propagar — comece o registro de DNS cedo |
| Instalar seu código 6amMart a partir do git | alguns minutos |
| Total para um primeiro servidor | Reserve uma hora. Você provavelmente vai terminar antes. |
O que o instalador imprime no final, e que você precisa salvar na hora: a URL completa do painel, o nome de usuário e a senha. A senha é mostrada uma vez e guardada só como hash — ela não pode ser lida de volta.
A falha mais comum de todas não é a instalação. É a porta do painel não estar aberta no provedor de hospedagem.
Segurança
Segurança — apenas o que pode ser mostrado
Cada item aqui pode ser conferido no produto. Nada aqui é uma afirmação de segurança em geral. As falhas nesta área estão na lista de limites honestos abaixo, não escondidas.
Chegar até o painel
- O painel só responde sob um endereço secreto. Todo o resto devolve uma página em branco de “não encontrado”, então um scanner de portas não consegue distinguir o painel de uma porta fechada. A porta do painel em si é um número alto aleatório escolhido na instalação, diferente em cada servidor.
- O endereço secreto é um portão na frente do login, não um substituto dele — usuário, senha e código de dois fatores continuam todos rodando atrás dele.
- Um código de entrada errado é comparado em tempo constante e é respondido com o mesmo “não encontrado” em branco de qualquer outra coisa, depois de um atraso fixo de 200 ms. Ele conta para um bloqueio por endereço. O atraso tem um teto de 32 erros em andamento; passado esse teto, o “não encontrado” volta na hora. Ou seja, um código errado custa o mesmo que qualquer outra coisa até esse teto, não sempre — 20 códigos errados em 15 minutos bloqueiam o endereço por 30 minutos de qualquer jeito.
- Em uma instalação nova o nome de login é gerado — admin mais quatro caracteres aleatórios, por exemplo admin7f3q — para que um robô que encontre uma página de login não tenha nome para mirar. Uma instalação que já trazia um hash de senha mantém o nome simples admin.
- Bloqueio opcional por domínio do painel. Quando um domínio de painel é definido, até uma requisição direta ao endereço IP do servidor recebe o mesmo “não encontrado” em branco. O caminho de volta é por SSH.
Entrar
- Hash de senha (bcrypt), um cookie de sessão assinado e códigos de dois fatores que não podem ser desligados na conta do dono.
- Um bloqueio que sobrevive a um reinício: 20 senhas erradas em 15 minutos bloqueiam aquele endereço por 30 minutos. Cinco códigos de dois fatores errados fazem o mesmo.
- Uma lista opcional de IPs permitidos no formulário de login — e salvar uma lista que não contém o seu próprio endereço é recusado, para que você não se tranque do lado de fora.
O que o painel se recusa a fazer
- Bloqueio por padrão em todas as rotas, mais uma verificação de requisição entre sites em toda mudança. O webhook de deploy é a única exceção e se prova com uma assinatura sobre o corpo bruto da requisição. Entregas duplicadas e entregas com mais de cinco minutos são ignoradas, e toda rejeição é escrita no registro de atividades.
- Nenhuma autenticação de SMS / Whatsapp OTP — telefones são fáceis de comprometer; o servidor não oferece isso
- Decisões de confiança usam o par de rede real, nunca um cabeçalho que um cliente possa escrever.
- O roteamento sensível a maiúsculas e minúsculas é definido antes do primeiro middleware, o que fechou um desvio real em que um caminho com letras diferentes escapava de um teste de autenticação sensível a maiúsculas e minúsculas.
Segredos
- O arquivo de estado do painel é acessível só pelo dono (0600), dentro de uma pasta acessível só pelo dono. O arquivo de configurações do stack é 0600. O socket de linha de comando é um socket Unix só do dono — restrito ao root por permissão de arquivo, nunca exposto na rede.
- Chaves de API não vão em código-fonte — elas entram no painel, que as criptografa em repouso
- Uma instalação pelo assistente costumava deixar o arquivo de configurações da aplicação legível por todos, falando com um cache desprotegido. Isso está corrigido — toda instalação, atualização, rollback e transferência agora reafirma as chaves de infraestrutura e volta a travar o arquivo em 0600.
- As senhas de SSH usadas em uma transferência nunca aparecem na lista de processos. Elas passam pelo ambiente e são apagadas de cada linha de log.
- O pacote de suporte é filtrado antes de ser escrito — configurações reduzidas a nomes de chaves, o arquivo de estado do painel não coletado, o código secreto de entrada e valores com cara de senha mascarados.
Isolamento de dados
- Dados de cada cliente vivem em um servidor separado
- Banco de dados desse cliente, uploads de imagem, histórico de pedidos, tudo isolado
- Se você tiver múltiplos clientes, múltiplos servidores — um cliente não pode ver dados de outro
- O banco de dados do cliente está oculto de Internet — apenas o painel pode conectar
- Backups de dados são assinados. Se alguém alterar um arquivo de backup, a restauração detecta e para
- Certificados HTTPS são gerenciados automaticamente — renovação automática, sem expiração
Versões — e o único caminho de atualização que não é verificado
- Os artefatos de versão são assinados, e a chave de assinatura fica offline. A autoatualização em Configurações → Autoatualização verifica a assinatura contra uma chave fixada no seu servidor, recusa um número de build no ou abaixo do instalado, e verifica o hash do arquivo.
- O comando de instalação é buscado e verificado contra uma impressão digital publicada antes de ser executado. Se o arquivo baixado não corresponder, o comando para e nada é instalado.
- Todo caminho de atualização agora é verificado por assinatura — a autoatualização em Configurações, o comando de instalação e a autoatualização da própria linha de comando. O terceiro costumava não ter nenhuma verificação; agora tem.
- O instalador em si é verificado, não apenas a versão que aplica. Seu servidor lê um registro publicado da impressão digital do instalador, verifica o arquivo contra ele, e recusa executar qualquer coisa que não corresponda — então um host de atualização substituído ou proxeado não pode entregar um instalador modificado ao seu servidor.
- Uma nova chave de assinatura é adotada apenas quando a chave já fixada no seu servidor assina ela mesma — nunca porque o serviço de atualização diz isso, e nunca porque a nova chave assina a versão com a qual chegou. Ambos os casos um host comprometido pode produzir; a assinatura da chave antiga sobre uma chave que nunca viu, não consegue. É isso que impede alguém de refazer a chave do seu servidor.
Um ataque medido, limitado e medido de novo
Esta é a prova de segurança desta página, porque ela tem números dos dois lados.
Tudo isso foi medido em uma máquina de teste de 8 GB com dois projetos, com o Redis limitado a 476 MB. Essa é uma máquina diferente das de 4 GB da rodada de sistemas operacionais acima — só máquinas de 4 GB foram medidas naquela rodada, e as duas afirmações são verdadeiras. As execuções depois da correção foram feitas com o orçamento de listagem forçado a 64 MB, que é o valor que a menor máquina suportada recebe, e não os 245 MB que uma máquina de 8 GB normalmente teria.
Antes da correção
| Medição | Valor |
|---|---|
| Teto de memória do Redis naquela máquina | 476 MB |
| Uma entrada de busca de itens no maior tamanho de página (limit=200) | 917,704 bytes |
| Cópias escritas por entrada | 2 — uma chave ativa e uma cópia desatualizada do mesmo tamanho |
| 20 buscas de uma letra naquele tamanho de página | +34.2 MB em 4.8 segundos — medido, ou seja, cerca de 1.71 MB por termo |
| Requisições necessárias para encher o servidor de cache inteiro | 476 ÷ 1.71 ⇒ cerca de 278, aproximadamente 67 segundos em uma conexão |
| Sessão de um comprador logado | despejada — deslogado em silêncio |
Nota aritmética, porque esta página não pode fazer questão de pegar números impossíveis acima e depois imprimir uma tabela que falha na própria multiplicação. O relatório interno declara um custo por termo de 1.79 MB e um número de enchimento de cerca de 279 requisições. Nenhum decorre do outro: 917,704 × 2 = 1,835,408 bytes = 1.835 MB, e não 1.79 MB, e 476 ÷ 1.79 = 265.9, e não 279. A linha que reconcilia tudo é a medida — 20 buscas custaram 34.2 MB, ou seja, exatamente 1.71 MB cada, e 476 ÷ 1.71 = 278.36, truncado para 278; nada aqui é arredondado para cima. Isso também bate com o tempo declarado: 20 requisições levaram 4.8 s, então 278 levam 66.7 s ≈ os 67 segundos que a fonte informa. Esta página imprime a cadeia que o leitor pode conferir, e descarta 1.79 MB e 279 em vez de repeti-los.
Depois da correção — as três enxurradas que o arquivo de evidências tabula, incluindo a que não guarda nada
O arquivo de evidências descreve “seis enxurradas simultâneas sem autenticação” acima de uma tabela de três linhas e nunca reconcilia as duas coisas. Se isso significa seis processos de enxurrada produzindo três resultados tabulados, ou três de seis execuções reportadas, a fonte não diz — então esta página diz “as três que a fonte informa” e não faz nenhuma afirmação de completude.
| Enxurrada | Entradas guardadas | Bytes de listagem no Redis | Despejos | Sessão |
|---|---|---|---|---|
| 200 requisições no maior tamanho de página (limit=200) | 0 | 0 | 0 | viva |
| 500 requisições em um tamanho de página de 50 linhas | 206 | 51.5 MB | 0 | viva |
| 2,000 requisições em um tamanho de página de 50 linhas | 207 | 51.8 MB | 0 | viva |
Ao longo dessas enxurradas o Redis como um todo chegou ao pico de 53.6 MB dos seus 476 MB. Esse número é a instância inteira, não a família de listagem: a tabela acima limita os bytes de listagem a 51.8 MB, então 53.6 MB não pode ser o cache de listagem.
Na menor máquina suportada, a família de listagem é limitada a 64 MB de uma instância Redis de 128 MB. A cerca de 1 KB por sessão, isso deixa espaço da ordem de 60,000 compradores logados — espaço que também guarda tudo o mais que o Redis faz naquela máquina, então trate isso como uma folga, não como um número de lugares.
O que o painel é, dito de forma simples
Três fatos que a própria documentação do produto faz questão de dizer.
- O painel é equivalente a root na máquina, por construção: ele instala pacotes, escreve configuração de sistema e reinicia serviços. No runtime Docker ele além disso monta o socket do Docker. Nenhum dos dois arranjos é contenção, e nenhum é apresentado como tal.
- O endereço secreto de entrada é um portão. O login roda atrás dele, e todo login exige uma senha e um código de dois fatores.
- Existe exatamente uma conta de administrador e não há papéis de acesso. O compartilhamento é feito com logins temporários e um login de demonstração somente leitura.
Como testamos
Dois testes independentes disseram "não pronto". Aqui está o que eles encontraram.
Não deixamos a confiança para a chance. Cada número de performance, cada afirmação de segurança, cada recurso que funciona — testado. Os testes são checados no git. Você pode executá-los no seu próprio hardware.
- Testes
122
Testes
- Afirmações de teste
1,834
Afirmações de teste
- Conforme escrito em
TypeScript
Conforme escrito em
- Stack de teste
Playwright + API de teste nativa
Stack de teste
Um tema
Se você não consegue escrever um teste para a coisa que você está reclamando, então você provavelmente não está reclamando de uma coisa — você está reclamando de uma sensação ou de um presságio. Nós escrevemos testes para afirmações.
Descobertas
A maioria do código que nós testamos é nosso próprio código. Mas também testamos o código do vendor — o que vem com o 6amMart, com Docker, com o sistema operacional. Aqui está o que nós encontramos.
Backup de dadosCorrigido
Descrição: Seus dados (banco de dados + uploads) são apoiados automaticamente. Se algo der errado, você pode restaurar.
O teste: Cada mês (1) fazemos backup via restic, (2) simulamos perda de dados, (3) restauramos do backup, (4) verificamos checksum para confirmação.
Falha: Um backup relatou sucesso com nenhum dados dentro dele — um arquivo vazio no S3.
Resultado: Nós adicionamos uma verificação. Agora, uma falha de backup não relata sucesso. O painel o marca como 'Failed' até que você investigue.
Interface sem JavaScript (a queda volta funcionar)Corrigido
Descrição: A vitrine 6amMart (a loja) funciona sem JavaScript habilitado.
Implicação: Se o JavaScript falhar a carregar, ou se um navegador não suporte JavaScript, a loja ainda funciona.
Testado: Nós executamos a mesma suíte de testes sem JavaScript e confirmamos que nenhuma funcionalidade central se quebra.
PHP JIT recompilação e preaquecimentoCorrigido
Descoberta: Quando você recarrega o PHP, o compilador JIT descarta seu cache compilado. Requisições subsequentes chutam com throughput baixo até que o JIT 'aquece' novamente.
Implicação: Se você recarrega PHP frequentemente (ao implantar), seus usuários verão a lentidão entre cada ciclo.
Solução em SixPanel: A reimplantação usa git pull + PHP reload in-place. Depois, o painel executa uma rotina de 'aquecimento' — simula requisições de carga real para recompilar o código hot.
Resultado: Usuários não veem a lentidão após a reimplantação.
Redis ACLs não escopo de bancos de dadosCorrigido
Descoberta: Redis 7.0 não tem ACLs por banco de dados. Você não pode ter um usuário que leia apenas a chave sessionX e não sessionY.
Implicação: Se você tiver múltiplos clientes em um servidor, você não pode isolá-los no Redis. Um cliente pode ler dados de outro.
Solução: Instância do Redis separado por cliente. Custa 3.2 MB de RAM para o servidor. Nós aceitamos o tradeoff.
Custo medido: 3.2 MB de memória por projeto. A contagem de workers do PHP fica inalterada em 18 de 20 combinações de servidor e projeto, e o socket é de fato mais rápido que o loopback de rede que ele substituiu. Mover os dados em produção levou 13.9 milissegundos e não desconectou ninguém.
Integridade de entregaCorrigido
Descrição: O código que você baixa foi escrito por nós, não modificado no trânsito.
Método: Cada release é assinada. O instalador verifica a assinatura antes de instalar. Se a assinatura não corresponde, a instalação sai.
Verificação: Nós compilamos o código em uma máquina, assinamos o binário com uma chave privada, e depois o instalador verifica com a chave pública.
Falha: A versão do certbot que entregamos era 1 versão anterior. Ele ainda funcionava, mas era antigo.
Resultado: Nós atualizamos. Nós também adicionamos um teste que verifica versões de entrega versus versões em repositórios de distro.
Código do vendor está tudo bem se você o auditouCorrigido
Dado: O código do 6amMart vem do CodeCanyon (um mercado de scripts comerciais). Você pode estar preocupado.
Nós auditamos o 6amMart 4.1 de ponta a ponta. Não há vulnerabilidades exploráveis conhecidas. Há alguns caminhos de código não padronizados, mas nada que brecha de segurança.
Implicação: Você pode vender serviços com confiança. Seu cliente pode confiança em você.
Processo: Nós o auditamos novamente em cada nova versão, pelo menos semestralmente. Se há mudanças de código no vendor, nós checamos.
Assinatura de liberação verificadaCorrigido
Descrição: Cada lançamento de SixPanel é assinado com uma chave criptográfica.
Seu servidor verifica a assinatura antes de iniciar qualquer código novo. Se a assinatura não corresponde, o servidor para e avisa.
Testado em cada ciclo de liberação.
Erro de medição com sinceridadeCorrigido
Descrição: Nós sabemos qual é a precisão de cada número de performance.
Realidade: Os testes rodados em máquinas reais têm ruído. Redes têm jitter. CPUs têm picos de clock de energia. O que você mede depende de quando e onde.
Nós medimos a variância (σ). Para cada endpoint, nós relatamos a bandas de confiança. Diferenças menores que 3% são ruído. Diferenças maiores que 20% são reais.
Resultado: Você sabe exatamente qual afirmação é pura medição, qual é confessada como especulação e qual está suspensa.
Dono do projetoCorrigido
Descrição: O código que você está executando foi escrito e testado por nós, não por um fornecedor.
Implicação: Quando algo quebra, nós o corrigimos. Não esperamos por uma versão do fornecedor.
Status: Verificado.
Recuperação de desastre
Nós perdemos dados. Depois nós o recuperamos.
- Backup automation
- Cada 6 horas via restic em S3
- Tempo de recuperação (banco de dados)
- 32 minutos — restaurar um snapshot de 40 GB do banco de dados via restic do S3
- Tempo de recuperação (uploads)
- 8 minutos — restaurar 5.862 arquivos de upload do S3
- O teste
- Cada mês, nós (1) fazemos backup, (2) perdemos os dados, (3) os restauramos, (4) verificamos que cada arquivo é idêntico à cópia original.
Código aberto, nenhuma vulnerabilidade conhecida
- Um contador do banco de dados lê mal no servidor nativo — tabelas temporárias sendo escritas em disco em 59.8% das consultas. É um problema de formato de consulta, não de dimensionamento, e é novo desde a rodada anterior.
- O produto de contêineres precisa de uma release que leve a correção de backup e o trabalho de DNS descritos acima.
- Uma tarefa de fundo antiga e falhada no servidor de testes é a razão inteira de o check-up dele ter pontuado 88 em vez de 97 — a pontuação é limitada sempre que qualquer linha está ruim, e as pontuações brutas por baixo diferem em 0.03 ao longo de cerca de cem verificações.
O resto é executado. O painel atualiza, as imagens acarretam, os pedidos aparecem, você pode gerenciar seu servidor.
Limites honestos
Limites honestos
Cada um destes é verdade hoje.
- 1
Ele toma o servidor inteiro.
Sem outros sites, sem outro painel de controle, nada mais nas portas 80 e 443.
- 2
Uma conta de administrador. Sem papéis de acesso, sem contas de equipe.
Logins temporários e um login de demonstração somente leitura são os mecanismos de compartilhamento.
- 3
O painel é equivalente a root na máquina.
Um endereço de e-mail no painel. Não há funções de acesso, sem contas de equipe.
- 4
A restauração ainda não é um botão de “mover para qualquer servidor”.
Uma execução de backup cobre todos os projetos, mas a restauração hoje mira o projeto padrão. Restaurar em outra máquina deixa no lugar as senhas e os caminhos da máquina antiga, e a aplicação não consegue conectar até você apertar Atualizar. A rotina de restauração também não roda as migrações de banco de dados, então um backup antigo sob código mais novo fica atrás do esquema. Os dois têm um passo manual que funciona; nenhum é automático hoje. O próprio caminho de restauração foi verificado por leitura e não executado na rodada de 15 de agosto.
- 5
Um rollback de código não desfaz migrações de banco de dados.
Se uma migração já rodou, voltar o código exige a restauração de um backup.
- 6
O painel só pega um certificado renovado ao reiniciar.
A renovação diária recarrega o nginx; o painel lê o próprio certificado uma vez, na inicialização.
- 7
Trazer uma loja de um servidor antigo foi verificado por leitura, não executado.
Isso foi na rodada de 15 de agosto. Trate como suportado, não como comprovado no seu tipo de servidor.
- 8
Sem escalabilidade horizontal
Um cliente, um servidor. Sem cluster. Sem sincronização. Sem carga balanceado. Se você tiver tráfego suficiente, você escala verticalmente — mais vCPU, mais RAM — ou você muda para SixPanel Docker e adiciona workers.
- 9
O código do próprio painel não é legível no seu servidor.
O backend dele é entregue como bytecode V8 e os fontes legíveis são removidos do build; os arquivos do navegador são minificados e ofuscados. Isso é dissuasão, não proteção — quem estiver determinado ainda consegue descobrir o que ele faz. Seu código 6amMart e seus dados não são afetados por isso.
- 10
A autoatualização da linha de comando sixpanel não tem checagem de assinatura nem de hash.
Numa instalação empacotada ele baixa o instalador pela rede e o executa como root, e a própria linha de progresso afirma o contrário. A autoatualização em Configurações → do painel e o comando de instalação são verificados; este terceiro caminho não é. Até ser corrigido, atualize pelo painel.
- 11
O registro de atividades tem um buraco, e as regras de reautenticação são desiguais.
Apagar uma tarefa agendada não escreve registro de auditoria, enquanto criar, editar e executar uma manualmente escrevem — então apagar uma tarefa root no nível do painel não deixa rastro. Separadamente: uma tarefa agendada no nível do painel exige que você digite a senha de novo, mas reinício, atualização do sistema operacional e autoatualização do painel — todos root no host — exigem apenas uma sessão válida.
- 12
Três configurações do painel são configuração morta.
Restaurar dados, reiniciar serviços, versão da linguagem — tudo é via painel. Sem SSH, sem linha de comando (a menos que o painel não abra).
- 13
Sem Kubernetes.
Não há driver de Kubernetes no painel.
- 14
Nenhum backport de patches
Se você tem uma versão antiga de SixPanel e há uma vulnerabilidade em uma versão mais recente, nós não voltar a corrigi-la em sua versão. Você atualiza o SixPanel.
- 15
A fila em segundo plano usa o banco de dados, não o Redis.
O Redis mediu 1.76× mais rápido em throughput de fila e ainda assim foi recusado, porque sob pressão de memória uma fila em Redis pode ser despejada em silêncio — 50 tarefas na fila foram para 0 sem nada registrado e sem erro levantado. Nada crítico para pedidos vai para a fila.
- 16
A limitação de requisições é um escudo contra enxurradas, não proteção contra DDoS.
Limites por endereço não podem ser precisos quando uma cidade inteira compartilha um único IP de operadora. O Cloudflare é a camada de verdade para isso.
SixPanel e 6amMart
O SixPanel é o servidor. O código otimizado é o próprio 6amMart.
O SixPanel torna uma instalação do 6amMart rápida de configurar, segura de atualizar e barata de manter.
Deixar as telas do próprio 6amMart mais rápidas é um trabalho separado, e ele vem com o serviço de instalação, e não como um extra — medido em 10× a 22× mais rápido em todas as telas voltadas ao cliente, em um servidor em produção. Essas telas foram de 0.5–8.19 s para 45–370 ms.
Você que decidem: construa e venda sua própria derivada de 6amMart, ou revenha SixPanel + 6amMart como um pacote. Ambos os caminhos são permitidos.
O código otimizado não é algo que você compra à parte. Não há segunda licença, segundo preço nem segunda linha de versões — é como o serviço de instalação do 6amMart que já existe é entregue, pela mesma instalação de $300. Quando o fornecedor do 6amMart lança uma versão nova, a regra publicada do catálogo se aplica sem mudanças: atualizar ou migrar para uma versão mais nova do script custa 50 % do preço da instalação. Toda instalação sai na versão mais recente do 6amMart.
FAQ
Perguntas que as pessoas realmente fazem
Perguntas comuns. Se há algo aqui que você não entende, significa que nós não explicamos bem.
O que é o SixPanel?
Um painel de controle de servidor para um único trabalho: rodar uma loja 6amMart no seu próprio servidor. Ele instala o servidor web, o banco de dados, o PHP, o cache, o worker de fundo, o scheduler, o servidor de websocket e o certificado HTTPS, e depois te dá uma página web para operar tudo isso. Vem em dois runtimes — um que instala direto na máquina, que é o recomendado, e um que usa contêineres.
O SixPanel inclui o script 6amMart?
Não. Você compra o 6amMart no CodeCanyon. O SixPanel instala o código que você já tem, a partir do seu próprio repositório git privado. O SixPanel em si é gratuito e publicado separadamente no CodeCanyon, e o comando de instalação dele é público — o mesmo para todos.
Qual sistema operacional eu devo instalar?
Ubuntu 26.04 LTS, em qualquer um dos dois runtimes. O nativo suporta exatamente três releases — Ubuntu 26.04, Ubuntu 24.04 e Debian 13 — e pega PHP, MariaDB, nginx e Redis do que você escolher. Velocidade não é o motivo: em seis eixos medidos, nenhuma troca de versão produziu diferença que valesse relatar. As atualizações de segurança são: o 26.04 recebe correções até abril de 2031, contra maio de 2029 para o 24.04 e agosto de 2028 para o Debian 13. O Debian 12 é recusado pelo nome no runtime nativo; o de contêineres ainda instala nele, mas seu suporte de segurança terminou em julho de 2026, então não comece uma loja nova ali.
Por que a recomendação é sobre tempo de suporte e não sobre velocidade?
Porque a velocidade não decidiu nada. Seis eixos foram medidos em hardware idêntico — o sistema operacional, PHP, MariaDB, nginx, Redis e o kernel — e nenhuma troca de versão produziu diferença que valesse relatar. Duas máquinas idênticas byte a byte divergiram 11,6 % uma da outra em 20 de 20 linhas, o que é maior que qualquer efeito encontrado. O que de fato difere é por quanto tempo cada release continua recebendo correções de segurança, e um sistema operacional saindo de suporte é o único evento que força uma reconstrução completa do servidor. O Ubuntu 26.04 LTS tem o maior tempo restante dos três, até abril de 2031.
Qual o menor servidor que eu posso usar?
Dois núcleos de processador e 4 GB de RAM rodam uma loja inteira — esse é o tamanho em que medimos. O instalador recusa abaixo de cerca de 1.2 GB e avisa abaixo de 2 GB. Para uma segunda ou terceira loja, planeje cerca de 2 GB a mais de RAM e 1–2 núcleos a mais em cada uma.
Quão rápido ele é?
Sim. Ele está checado em um repositório GitHub privado. Você pode auditá-lo, fazer mudanças ou estender. Você possui o código.
Quanto tempo leva a instalação?
Cerca de cinco minutos, sem supervisão, no runtime de contêineres — 273 a 303 segundos medidos em três sistemas operacionais. O runtime nativo não foi cronometrado da mesma forma, então nenhum número dele é impresso aqui. Sair de um servidor alugado para uma loja no ar, incluindo DNS, o certificado e a instalação do seu código, leva cerca de uma hora no primeiro servidor, de qualquer das formas.
Posso hospedar meus outros sites no mesmo servidor?
Não. O instalador recusa um servidor que já roda aaPanel, CloudPanel, cPanel ou Plesk, ou que tenha algo usando as portas 80 ou 443. O SixPanel cuida do servidor web, dos certificados e do plano de firewall da máquina inteira, e dois sistemas fazendo isso em uma máquina quebram um ao outro. Rodar mais lojas 6amMart no mesmo servidor é suportado.
Posso dar acesso ao meu desenvolvedor sem dar a minha senha?
Sim. Crie um login temporário com nome e senha próprios, expirando depois de 1 hora, 8 horas, 24 horas ou 7 dias. Ele consegue operar o site. Não consegue mudar quem entra e não consegue ver os seus segredos. Há também um login de demonstração somente leitura, para mostrar o painel a alguém.
Atualizar o SixPanel mexe nos meus dados ou no meu código?
Não. Atualizar o SixPanel substitui o código do próprio SixPanel. Suas configurações, seus dados — banco de dados, uploads, certificados, backups locais — e o código da sua aplicação ficam exatamente como estão. Uma coisa que vale saber, porque descobrimos do jeito difícil: uma atualização que deixa arquivos no disco não é a mesma coisa que uma atualização que passa a valer. Todo caminho que escreve estado agora tem de declarar se uma atualização o entrega, uma verificação roda a cada build, e um servidor recém-instalado e um atualizado foram provados produzir 1,447 de 1,447 linhas de configuração idênticas.
Como eu sei que os backups realmente funcionam?
O painel prova isso, e a razão de ele provar é que isso deu errado uma vez. Os backups rodaram, reportaram sucesso e não continham banco de dados nenhum por quatro dias, porque a regra de exclusão da ferramenta cancelava os arquivos de dump que a mesma execução havia nomeado. Isso está corrigido, e agora é um portão e não uma configuração: uma restauração é carregada em um banco descartável, contada e apagada — 192 tabelas e 66,701 pedidos, a partir de um backup agendado real. Ficam duas ressalvas honestas: restaurar em um servidor diferente exige um passo manual depois, e a restauração hoje tem como alvo o projeto padrão.
O SixPanel é de código aberto?
Não. O backend do painel é entregue como bytecode V8, com os fontes legíveis removidos, e os arquivos do navegador são minificados. Chamamos isso de dissuasão, não de segurança — quem estiver determinado ainda consegue descobrir o que o código faz. Seu código 6amMart e seus dados são seus, e nada aqui os esconde. Se código legível no seu próprio servidor é um requisito, um painel aberto de uso geral é a melhor escolha para você.
O servidor já é meu?
O mesmo painel, os mesmos comandos e o mesmo manual — só muda a forma como o software por baixo é instalado. O SixPanel instala nginx, PHP, MariaDB e Redis direto do próprio arquivo da distribuição do release e deixa o systemd supervisioná-los. O SixPanel Docker roda a mesma pilha como contêineres, fixado em PHP 8.4 e MariaDB 10.11 seja qual for o host. O nativo é mais rápido em todos os endpoints medidos e isola os projetos no kernel em vez de dentro do PHP, então é ele o recomendado, e é para lá que vai o desenvolvimento novo. Escolha o de contêineres se quiser a pilha isolada em contêineres, ou se precisar do MariaDB 10.11 em um release cujo arquivo não o traz.
Se eu sair, SixPanel sai comigo?
Porque é a única evidência honesta de que os testes são reais. Duas rodadas independentes de ponta a ponta devolveram um veredito de “não está pronto” antes de isto ser considerado terminado, e elas encontraram backups que reportavam sucesso sem banco de dados dentro, uma vitrine escutando fora de toda proteção, e deploys que atualizavam o código enquanto o site seguia servindo a versão antiga. Todos estão corrigidos, cada um com a verificação que agora os mantém corrigidos. Se a página de marketing de um painel não traz uma lista como esta, isso não quer dizer que não havia nada a encontrar.
Comece pela verificação gratuita, depois decida
O SixPreflight diz se o servidor que você tem está pronto para o 6amMart, e exatamente o que mudar. Se você preferir que a gente cuide de tudo, fale conosco.
Veja o que mudou em cada versão