Configuração de Sites

Depois de criar um site, você o ajusta e opera pelas sub-páginas da sua página de detalhe. Esta página cobre o editor de Ambiente (.env), a página de Configurações (tipo, domínios, versões de runtime, interruptores de serviços, migrações, deploy atômico, hooks, webhook e zona de perigo), a governança das versões de runtime disponíveis, e as páginas de Logs e Atividade.

#Ambiente

O editor de Ambiente deixa você gerenciar o arquivo .env do site diretamente pelo painel, sem SSH.

#Editar variáveis

1. Abra a aba Ambiente na página do site.
2. Edite as variáveis individualmente, ou adicione novas com chave e valor.
3. Clique em Salvar. As mudanças são escritas no servidor imediatamente.

Para proteger dados sensíveis, os valores de segredos (senhas, chaves de API, APP_KEY, credenciais de banco) aparecem mascarados por padrão. Um botão Mostrar Segredos revela os valores quando você precisa conferi-los, e você pode ocultá-los de novo — assim ninguém vê seus segredos por cima do seu ombro em uma sessão compartilhada.

Depois de editar variáveis de ambiente, refaça o deploy do site (ou reinicie os containers) para que as mudanças tenham efeito. A maior parte da configuração do Laravel é cacheada e só é relida em um novo deploy.

#Variáveis geradas automaticamente

O PrimeForge define estas variáveis durante a preparação do site e reabastece as chaves faltantes a partir do .env.example a cada deploy, então uma app Laravel nova geralmente sobe sem edição manual:

#Configurações

A aba Configurações concentra todos os ajustes do site, do runtime aos interruptores de serviço, os hooks de deploy e a zona de perigo.

#Identidade e domínio

• Tipo de site — o tipo escolhido na criação (Laravel, PHP Clássico, etc.).
• Domínios — o domínio em que o site é servido. Para trocar de domínio, atualize o registro DNS para o novo domínio apontar para o IP do servidor, altere o campo aqui e refaça o deploy — o PrimeForge atualiza as rotas do Traefik e solicita um novo certificado TLS automaticamente.
• Versões de PHP / Node — a dupla de runtime em que o site roda. Trocar a versão dispara um redeploy e falha fechado: a imagem de runtime é verificada no servidor primeiro e, se ainda não estiver lá, é transferida do hub antes de qualquer mudança, o que pode levar um ou dois minutos. Seu site nunca é apontado para uma imagem que o servidor não tem.

#Interruptores de serviço

Você pode ligar ou desligar serviços depois da criação do site. Após alterar, refaça o deploy para aplicar:

• Banco de dados — a configuração de conexão no .env do site
• Redis — adiciona ou remove a configuração de Redis
• Horizon — sobe ou para o container de worker de filas do Horizon
• Reverb — registra ou desregistra o site no servidor Reverb
• S3 / Armazenamento — provisiona ou remove o bucket MinIO

#Deploy: migrações, atomicidade e hooks

• Rodar migrações — por padrão o pipeline roda php artisan migrate --force no estágio de Script. Se você roda as migrações por fora (um runner separado, releases controladas), desligue este interruptor: o pipeline pula a migração e o rastreamento de "schema à frente", mas ainda roda optimize:clear e storage:link. A partir daí, você é o dono das migrações.
• Deploy atômico — sites novos já nascem atômicos (cada deploy monta um diretório releases/{id} e só troca o symlink current quando o build e as migrações têm sucesso, então uma falha antes da troca é invisível ao visitante). Sites legados (in-place) podem aderir ao layout atômico por este interruptor — uma migração enfileirada converte o diretório repo/ no layout de releases/shared; o mesmo interruptor reverte. Ele fica oculto para sites que já nasceram atômicos.
• Hooks de deploy — além do script principal deploy.sh (roda depois dos passos internos do Laravel), você tem um hook pré-deploy (hooks/pre-deploy.sh, roda no início do estágio de Script, antes das migrações; em sites atômicos é pré-troca, então o visitante nunca o vê) e um hook pós-deploy (hooks/post-deploy.sh, roda depois que a verificação de saúde passa; falhas nele são apenas registradas, nunca derrubam um deploy já no ar). Hooks vazios são pulados em silêncio.

#Webhook e página de pânico

• Segredo do webhook — cada site tem um webhook_secret (gerado aleatoriamente, criptografado em repouso) embutido em sua URL única de webhook. É com ele que o PrimeForge verifica a assinatura HMAC dos pushes do GitHub para o deploy automático. A URL do webhook aparece com um botão de copiar, para registro manual quando necessário.
• Página de pânico — o Modo de Pânico serve uma página de manutenção estática quando ativado. Cada site tem um diretório maintenance/ no servidor com o HTML dessa página, e você pode personalizá-la a partir das configurações do site, para exibir a mensagem e a identidade visual da sua marca durante uma emergência.

#Zona de perigo

• Excluir site — remove permanentemente o site do PrimeForge: para os containers, remove a rota do Traefik e limpa as referências no painel. É uma ação de confirmação elevada, dado que não há "lixeira".

#Versões de runtime disponíveis

Todo site fixa uma versão de PHP e uma de Node e roda em uma imagem Docker site-runtime construída exatamente para essa dupla. Quais versões você pode escolher é governado por um registro de versões de runtime mantido pela plataforma; cada versão tem um status de ciclo de vida:

O que isso significa no dia a dia:

• Criando um site — o seletor de versões só mostra as não descontinuadas, com uma pré-selecionada como padrão da frota.
• Uma versão que você usava sumiu do seletor — ela foi descontinuada. Seus sites existentes seguem intactos; só sites novos não podem mais escolhê-la.
• Trocando a versão de um site — em Configurações → Runtime. A troca dispara um redeploy e falha fechado (a imagem é verificada/transferida antes de mudar qualquer coisa).
• Rollback de um deploy — cada release grava o runtime com que foi construída, e o rollback de um clique restaura aquela versão de PHP/Node junto com o código.

A página Runtimes do painel é uma visão somente leitura do registro: as versões oferecidas e seus status, os padrões atuais, quais imagens de runtime existem no hub e quantos dos seus sites usam cada combinação. As versões e os padrões são gerenciados pela plataforma.

#Logs

A aba Logs dá acesso aos registros da aplicação a partir de várias fontes, transmitidos do servidor pelo agente.

Use as abas para alternar entre as fontes. Estas são as fontes disponíveis para sites Laravel; sites de outros tipos mostram apenas as fontes que fazem sentido para eles (por exemplo, Aplicação para PHP Clássico e Estático).

#Atividade

A aba Atividade é o registro de auditoria por site: quem fez o quê e quando. Cada deploy, alteração de configuração, ativação de pânico, troca de runtime, edição de .env e mais aparece com autor e horário.

É onde você reconstrói a linha do tempo de um site — útil para investigar uma mudança inesperada de comportamento ou para prestar contas de quem alterou o quê. A atividade por site é um recorte da auditoria geral da organização, filtrado para aquele site.

#Próximos passos

• Sites — crie novos sites e conheça os cinco tipos
• Serviços, Bancos e Armazenamento — os servidores que hospedam o banco, Redis e S3 que você liga aqui
• Monitoramento, Agendador e Firewall — acompanhe o consumo de recursos do site