FAQ

Respostas rápidas para as perguntas que surgem com mais frequência. Cada resposta aponta para a página completa que trata do assunto em profundidade.

Primeiros passos

Onde fica minha interface de administração? Instalações padrão via systemd vinculam o CMS apenas ao loopback (127.0.0.1:3001 por padrão para a instância 1) e colocam Caddy ou nginx na frente, então você acessa o admin através do domínio de admin do seu site. Instalações quick e offline servem o admin diretamente na porta 8080 do host.

O build do site acontece automaticamente quando eu edito? Não: builds são operações explícitas, disparadas do dashboard, via um build webhook configurado, ou executadas à mão. Cada build é registrado em log, e uma falha nunca sobrescreve o site no ar.

Eu instalei e ele continua me mandando para /setup. Uma instalação nova vem com uma senha de admin placeholder, e toda requisição é redirecionada para a página de setup até você definir uma real (12+ caracteres com maiúscula, minúscula e dígito). Depois de definida, a página de setup desaparece.

O endpoint /health? Cada instância expõe um endpoint de saúde para monitoramento: {"status":"ok","db":"ok"} em caso de sucesso, 503 quando o banco de dados está inacessível.

Contas e acesso

Qual a diferença entre admin e editor? Admins gerenciam usuários, builds, configurações, chaves de API e todo o conteúdo. Editors não têm acesso a isso; o acesso deles pode ser ainda mais restrito por tipos de conteúdo e idiomas permitidos.

Por que um editor não pode publicar? Se o approval workflow está ativado (Settings → Workflow), tentativas de publicação por não-admins se tornam submit-for-review. Desative-o para publicação direta.

Por que todo mundo é deslogado depois de trocar o secret? A variável de ambiente CHINASKI_SECRET assina as sessões e deriva a chave que criptografa as credenciais armazenadas. Rotacione-a deliberadamente: as sessões morrem imediatamente, e as configurações criptografadas (senha SMTP, secrets) precisam ser salvas novamente depois.

Estou bloqueado por tentativas de login fracassadas. Os bloqueios são fixos por IP: 60 segundos após 5 falhas, 5 minutos após 10, 30 minutos após 20, e sobrevivem a reinicializações. Não é possível ajustá-los na área de administração; a configuração de limiar de falhas é apenas para alertas no event log.

Conteúdo e builds

As alterações não aparecem no site. Publicar conteúdo atualiza o banco de dados, não a saída estática; o site só muda quando um build roda. Dispare um pelo dashboard (ou via API/webhook), depois verifique o status do build e o histórico de builds, incluindo eventuais bloqueios do promotion guard.

Um build terminou mas o site parece antigo. Os builds só promovem saída saudável: erros de render, violações do quality guard (queda no número de páginas, links quebrados, regressões de acessibilidade) ou falhas de manifest interrompem a promoção e mantêm o site anterior no ar. O histórico de builds mostra qual checagem recusou; você pode forçar a promoção daquele build se aceitar a regressão.

Quanto tempo pode durar um build? Os builds têm um teto fixo de 30 minutos; um build que estoura o tempo é encerrado e deixa a saída no ar intocada.

Onde foi parar meu post? Conteúdo excluído vai para a lixeira (Trash), não deixa de existir de imediato; purgas dos itens na lixeira rodam periodicamente. Verifique a lista da Trash para restaurar.

Backups e recuperação

O que é incluído no backup? O backup diário do sistema captura o banco de dados (retenção padrão de 14 dias) e faz mirror da mídia. Backups no app criam arquivos tar.gz completos (banco de dados, mídia, temas, templates), verificados após a criação por padrão e, opcionalmente, enviados para o DigitalOcean Spaces.

Restaurando em um novo host: problemas de conexão? Restaure o arquivo de env antigo antes de qualquer outra coisa: a chave de criptografia das credenciais armazenadas deriva do seu CHINASKI_SECRET, então um banco de dados restaurado e aberto com um secret diferente perde silenciosamente os secrets armazenados; defina o secret original primeiro. Runbook completo na página de disaster recovery.

Postura de segurança

Os cookies de sessão são assinados, Secure, HttpOnly e SameSite=Lax; tokens CSRF protegem toda requisição de admin que muda estado; um nonce de CSP por requisição bloqueia scripts inline.
Integrações de saída são validadas contra faixas de endereços privadas/internas (webhooks não podem mirar sua rede interna), nunca seguem redirects e limitam o tamanho da resposta.
Uploads são identificados pelo conteúdo do arquivo, não pela extensão; uploads de SVG são rejeitados de imediato; a importação em massa de CSV tem teto (4 MiB, 5.000 linhas, transação única).

Pontos rápidos de troubleshooting

Os logs vão para o journal do sistema (com linhas JSON estruturadas para eventos de alto sinal, incluindo IPs de clientes; o README documenta um snippet de política de retenção do journald que você pode adotar para alinhar com sua política de privacidade).
Um build está “busy” apenas enquanto um está em execução; o lock expira sozinho se um build morre sem informar.
Conflitos de porta / incompatibilidade de proxy têm uma página própria (veja Troubleshooting → Port Conflicts).

Mapa honesto de recursos

Sem ecossistema de plugins, sem arquitetura de hooks, sem marketplace de temas; sem editor drag-and-drop; sem Postgres (multi-tenancy é um item do roadmap). Estender o sistema significa mudanças de código, não instalações.
O core é licenciado sob MIT.

Idioma e questões multilíngues

Múltiplos idiomas, modos de URL por caminho/subdomínio, alternates hreflang e um seletor de idioma estático são embutidos e documentados em suas próprias páginas. Configurações por idioma cobrem títulos do blog e textos do aviso de cookies, e a própria UI do admin vem localizada.
A publicação agendada respeita o timezone do site; conteúdo cujo idioma você remove do conjunto ativo não pode ficar “órfão”: o admin recusa a remoção até que aquele conteúdo seja excluído ou reatribuído.