Como hospedar o Wallos em 2026: renovações, notificações e SQLite

A maioria das instruções de instalação do Wallos termina no primeiro carregamento da página. Isso é cedo demais: as datas de renovação mudam porque o TZ está incorreto ou porque o diretório do SQLite é somente leitura. Um teste de produção útil é mais exigente: crie assinaturas em diferentes ciclos de cobrança, defina as datas de renovação, execute o fluxo de notificações e confira os totais na moeda selecionada.

O papel do Wallos é simples: um rastreador de assinaturas com datas de renovação e notificações. Seu limite operacional inclui mais do que o processo web, portanto a dependência, o estado armazenado e a rota pública precisam ser identificados explicitamente antes da chegada de dados reais.

Mapeie o Wallos antes de tocar no Docker

Separe quatro aspectos do Wallos: ingress, o listener na porta 80, o estado durável e os serviços de suporte ou a capacidade local. O requisito do runtime local é contar com diretórios persistentes para o banco de dados e o upload de logos, além da entrega de notificações. Dimensione e monitore esse recurso junto com o container, em vez de expor um serviço de rede não relacionado.

Execute a transação conhecida — crie assinaturas em diferentes ciclos de cobrança, defina as datas de renovação, execute o fluxo de notificações e confira os totais na moeda selecionada — antes de considerar essa separação concluída. Meça o trabalho de notificações agendadas, o armazenamento de logos, as gravações no SQLite e a correção do fuso horário, mantendo o resultado junto ao registro do deployment. Isso fornece tanto um critério de aceitação quanto a primeira referência de capacidade.

Diagnostique um Wallos com aparência saudável

No Wallos, monitore uma transação em vez de um processo: crie assinaturas em diferentes ciclos de cobrança, defina as datas de renovação, execute o fluxo de notificações e confira os totais na moeda selecionada. Combine a latência e a taxa de erros com o trabalho de notificações agendadas, o armazenamento de logos, as gravações no SQLite e a correção do fuso horário, para que um alerta identifique o componente limitado.

O ensaio de upgrade precisa abranger o teste das migrações do banco de dados do Wallos com dados de datas e moedas antes da substituição da imagem em execução. Restaure, faça a migração e execute a transação antes da substituição em produção. Se as datas de renovação mudarem porque o TZ está incorreto ou porque o diretório do SQLite é somente leitura, não apague os dados para fazer o startup ficar verde; compare versão, variáveis, mounts e alcance das dependências, nessa ordem.

Transforme o smoke test do Wallos em uma verificação de release

O registro de release do Wallos precisa de fatos, não de um “parece bom”. Armazene o digest da imagem selecionada, o checksum da configuração, o hostname público e um resultado com timestamp para: criar assinaturas em diferentes ciclos de cobrança, definir as datas de renovação, executar o fluxo de notificações e conferir os totais na moeda selecionada. Use dados de exemplo que não sejam de produção, para que a verificação possa ser executada após cada deployment.

Comprove separadamente dois eventos do ciclo de vida. A substituição de um container precisa preservar a operação normal; uma recuperação limpa deve mostrar que assinaturas, categorias, logos e configurações de notificações retornam com as datas de renovação inalteradas. Enquanto as verificações são executadas, meça o trabalho de notificações agendadas, o armazenamento de logos, as gravações no SQLite e a correção do fuso horário, mantendo o resultado como o envelope esperado para essa versão.

Teste também uma condição negada ou inválida: envie uma entrada inofensiva próxima do limite de recurso ou formato associado a este cenário: as datas de renovação mudam porque o TZ está incorreto ou porque o diretório do SQLite é somente leitura. O Wallos deve falhar de maneira diagnosticável e não deve sobrescrever um estado saudável. Retorne à condição válida, execute novamente o exemplo e anexe os logs relevantes com os dados sensíveis redacted. Esses artefatos fornecem evidências concretas para uma futura decisão de rollback.

Torne o startup do Wallos reproduzível

Um launch com formato de produção é intencionalmente monótono: estado nomeado, porta explícita e nenhum secret dentro da imagem.

docker run -d \
  --name wallos \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallos-data:/var/www/html/db \
  -e TZ=UTC \
  bellamy/wallos:latest

O exemplo é uma referência básica, não uma stack de suporte completa. Confirme o requisito local antes da exposição: diretórios persistentes para o banco de dados e o upload de logos, além da entrega de notificações. Verifique os mounts efetivos e o listener; em seguida, tente criar assinaturas em diferentes ciclos de cobrança, definir as datas de renovação, executar o fluxo de notificações e conferir os totais na moeda selecionada. Fixe a imagem que está funcionando antes do próximo restart.

Encontre todos os bytes duráveis do Wallos

Faça o inventário de todos os artefatos duráveis: banco de dados de assinaturas, logos enviados e configurações de notificações. Monte /var/www/html/db antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para comprovar que esse caminho é realmente persistente. Inclua as configurações que alteram a forma como os dados armazenados são interpretados, não apenas o maior diretório.

Defina a retenção, copie os backups para fora do host e execute uma restauração em ambiente limpo. O exercício do Wallos estará concluído quando assinaturas, categorias, logos e configurações de notificações retornarem com as datas de renovação inalteradas. Se snapshots fizerem parte do plano, use as orientações sobre PITR versus snapshots para documentar o que cada mecanismo consegue recuperar.

Dê ao Wallos um endereço canônico

A emissão de TLS é apenas metade da rota do Wallos. Sirva a aplicação por HTTPS e defina o fuso horário. Envie o tráfego internamente para a porta 80 e encaminhe o esquema externo, para que as URLs geradas e os secure cookies permaneçam consistentes.

Use o cenário completo do Wallos a partir de uma rede limpa, não apenas a página raiz. Um erro 502 ou uma falha de certificado pode ser isolado com a configuração automática de domínio e TLS. Se o tráfego chegar ao processo e as datas de renovação mudarem porque o TZ está incorreto ou porque o diretório do SQLite é somente leitura, diagnostique essa condição no ponto em que ela ocorre, em vez de empilhar redirects.

Proteja a parte valiosa do Wallos

Após o primeiro login, verifique o que um visitante anônimo, um usuário comum e um administrador podem fazer. O problema do Wallos que deve ser evitado é deixar a primeira conta vulnerável em uma instância exposta à internet. A política pretendida é proteger a conta, manter os tokens de notificação privados e definir o TZ explicitamente para que as renovações não mudem.

O TZ controla o comportamento, não a confidencialidade; valide seu tipo e valor e armazene as credenciais reais do Wallos separadamente. Mantenha as contas de dependências separadas das contas humanas, negue o egress não utilizado quando for prático e limite o trabalho influenciado por notificações agendadas, armazenamento de logos, gravações no SQLite e correção do fuso horário.

Onde o Dockup reduz o trabalho com o Wallos

Um template do Dockup deve codificar a imagem, a porta 80, os mounts, o timing do health check, o domínio, o TLS e a entrega de secrets. O Dockup deve preservar as configurações de runtime do Wallos enquanto o operador confirma este requisito local: diretórios persistentes para o banco de dados e o upload de logos, além da entrega de notificações. O mesmo deployment pode ter como destino servidores do Dockup ou capacidade conectada pelo cliente.

Depois que a rota estiver ativa, aplique a configuração pública e tente criar assinaturas em diferentes ciclos de cobrança, definir as datas de renovação, executar o fluxo de notificações e conferir os totais na moeda selecionada. Faça backup do banco de dados de assinaturas, dos logos enviados e das configurações de notificações e mantenha o exercício de restauração no plano operacional; essas são responsabilidades do Wallos que continuam visíveis após o provisionamento da infraestrutura.

Perguntas frequentes

O que o Wallos precisa para um deployment de produção?

Encaminhe o container do Wallos na porta 80 por meio de uma origem HTTPS. O requisito do runtime local é contar com diretórios persistentes para o banco de dados e o upload de logos, além da entrega de notificações. Não considere o Wallos pronto até conseguir criar assinaturas em diferentes ciclos de cobrança, definir as datas de renovação, executar o fluxo de notificações e conferir os totais na moeda selecionada.

Quais dados do Wallos devem fazer parte de um backup?

Persista /var/www/html/db e inclua o banco de dados de assinaturas, os logos enviados e as configurações de notificações no mesmo manifest de recuperação. Uma restauração limpa do Wallos só será bem-sucedida quando assinaturas, categorias, logos e configurações de notificações retornarem com as datas de renovação inalteradas.

O Wallos precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Wallos e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do Wallos: sirva a aplicação por HTTPS e defina o fuso horário. No Wallos, o HTTPS protege credenciais ou conteúdo do usuário durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como um upgrade do Wallos deve ser testado?

Restaure o estado atual do Wallos em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Preste atenção especial, pois as migrações do banco de dados do Wallos devem ser testadas com dados de datas e moedas antes da substituição da imagem em execução. Mantenha a imagem anterior do Wallos até entender os limites da migração de dados e do rollback.