SiebotCitizen Apps
Estudo técnico · MVP
Relatório de infraestrutura / Recursos e Docker

Recursos e Docker

Respostas documentadas às tasks de CPU, RAM, armazenamento e suporte a containers isolados, fundamentadas na análise do código e nas especificações dos provedores.

Módulo 03 de 07 · Hostinger / AWSCitizen Apps / Pesquisa de infraestrutura
Siebot Infrastructure Lab

Dimensionamento baseado em evidências

CPU, memória, disco e isolamento de containers: descubra o que os provedores oferecem e o que ainda precisa ser medido.

Hostinger / AWSLimites cgroupsIsolamento
CITIZEN APPSGOVERNANÇA PROXY HTTPSTLS • ROTAS CONTÊINER Acontrole_visitas CONTÊINER Boutra_app
O que foi efetivamente examinado

Inventário do código recebido

A leitura foi realizada sobre o arquivo ZIP entregue nesta conversa. Trata-se de análise estática, sem bancos corporativos ou ambiente produtivo conectado.

Implementado no pacote

  • Portal PHP integrado à sessão do Siebot Hub.
  • Cadastro de apps, estados de aprovação e responsáveis.
  • Solicitações de APIs por conexão, aceite e auditoria.
  • DAO MySQL nos bancos auth e sie_dash_dev.
  • Registro de ID e sufixo de token, sem guardar o bearer completo no módulo.
Referências: index.php; public/api/citizen_apps.php; src/model/CitizenAppsDAO.php; README.md.

Não identificado no pacote

  • Dockerfile, compose.yaml ou docker-compose.yml.
  • Imagens, registry, pipeline de deploy ou rollback.
  • Configuração de proxy Nginx/Traefik e certificado.
  • Limites e políticas dos containers, volumes e healthchecks.
  • Inventário de CPU/RAM/disco de um host real ou testes de carga.
Busca no inventário do ZIP: arquivos de configuração de infraestrutura ausentes.
Separação essencial: cadastrar uma Citizen App não cria um container. O portal é o plano de governança; Docker, rede e deploy integram o plano de hospedagem. O MVP pode começar com publicação manual padronizada e aprovação prévia.
Task 01 • Validar plano e recursos

CPU, RAM, armazenamento, transferência e limites

Os planos indicam limites contratados. A capacidade de execução simultânea depende de consumo real, carga concorrente, banco externo, picos de CPU e margem para o sistema operacional.

Confirmado em fonte oficialProjeção calculadaSem benchmark operacional
Planos de referência, consultados em 08/10/2026
ServiçoPlanovCPURAMDiscoTransferência publicadaBase mensal
HostingerKVM 114 GB50 GB NVMe4 TBR$ 29,99 promocional; R$ 59,99 renovação
HostingerKVM 228 GB100 GB NVMe8 TBR$ 43,99 promocional; R$ 77,99 renovação
HostingerKVM 4416 GB200 GB NVMe16 TBR$ 59,99 promocional; R$ 149,99 renovação
AWSLightsail 4 GB24 GB80 GB SSD4 TB*US$ 24
AWSLightsail 8 GB28 GB160 GB SSD5 TB*US$ 44
AWSLightsail 16 GB416 GB320 GB SSD6 TB*US$ 84
AWSEC2Personalizado: instância, EBS, rede e região selecionados à parte.Solicitar cotação regional

Hostinger: preço mensal equivalente de contrato promocional, cobrado conforme período contratado, e preço de renovação anunciado. AWS Lightsail: Linux com IPv4 público. *Em São Paulo, a franquia de transferência é metade da tabela geral (ex.: 5 TB → 2,5 TB); excedentes e serviços adicionais podem ser cobrados. EC2: preços On-Demand dependem de região e instância; EBS, IPv4 e tráfego são custos separados. Fonte: S1–S4.

CPU (vCPU)

Representa capacidade de processamento compartilhada pelos containers. Dois containers com teto cpus: "0.50" não recebem meia CPU reservada; cada um apenas não pode ultrapassar essa cota. Instâncias compartilhadas podem ter política de burst/créditos.

RAM

A memória deve incluir Linux, Docker, proxy, cache, buffers, aplicações e uma reserva de segurança. Sem mem_limit, uma aplicação pode pressionar todo o host; com limite insuficiente, pode ocorrer OOM.

Disco, I/O e tráfego

Imagens, layers, logs, volumes e atualizações usam armazenamento. A capacidade nominal não mede IOPS ou latência. Transferência mensal e conectividade até o Siebot API Hub são fatores separados.

Para experimentar a inclusão de uma nova aplicação e seu impacto no consumo do servidor, utilize o simulador visual de cadastro.
Conclusão da task 01: a especificação dos planos foi identificada; a capacidade real não está validada. Para um piloto com apps internas pequenas e bancos existentes fora da VPS, 8 GB/2 vCPU é uma hipótese inicial de teste, não aprovação de produção. Se houver CPU concorrente significativa, avaliar 16 GB/4 vCPU.
Task 02 • Docker e isolamento

Um container por Citizen App: viável com restrições

Hostinger KVM aceita Docker em VPS Ubuntu, inclusive com template próprio. Lightsail e EC2 oferecem VMs Linux em que é possível instalar Docker Engine/Compose. Containers compartilham o kernel do host; a separação não equivale a VMs independentes.

01GovernançaCadastro, responsável, aprovação e escopo de API
→
02EntregaImagem Docker imutável e versão revisada
→
03ExecuçãoContainer, volumes, segredos e limites de recursos
→
04ExposiçãoProxy HTTPS e rede Docker controlada

Configuração recomendada

services:
  controle_visitas:
    image: registry-interno/controle_visitas:1.0.0
    restart: unless-stopped
    mem_limit: 512m
    cpus: "0.50"
    pids_limit: 100
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
    networks:
      - visitas_edge
    # Sem ports: o proxy acessa via rede privada

networks:
  visitas_edge:
    external: true

Modelo ilustrativo: depende de usuário não-root, diretórios de escrita, healthcheck específico, volumes quando necessários, política de logs, secrets e rede entre o proxy e a app. O serviço proxy não deve expor docker.sock sem proteção especial.

Isolamento obrigatório para o MVP

  • Um processo/serviço por aplicação e quotas individuais de CPU e RAM.
  • Não utilizar --privileged, rede host nem montar o socket Docker nas apps.
  • Rodar como usuário não-root, com capacidades mínimas e seccomp padrão.
  • Redes restritas: somente o proxy acessa a porta web da aplicação.
  • Tokens fora da imagem/repositório; privilégio mínimo por API e ambiente.
  • Volumes e diretórios com dono e backup definidos.
  • Healthcheck e políticas de restart, log rotation, atualização e rollback.
  • Monitoramento e limite operacional baseado em teste de carga.
Segurança: se as apps forem mantidas por equipes com diferentes níveis de confiança, uma única VM com Docker exige análise de risco. Para isolamento forte, separar também por VM/host ou adotar controles mais robustos.

O que muda por provedor?

EtapaHostinger VPSLightsailEC2
Provisionar LinuxhPanel / KVM / SSHInstância + IP estáticoAMI + instância + EBS + SG
Instalar DockerTemplate ou instalação manualInstalação no SOInstalação no SO ou AMI apropriada
Deploy inicialSSH + Docker ComposeSSH + Docker ComposeSSH/CI + Docker Compose
Ingress e SSLFirewall + Nginx/TraefikFirewall Lightsail + proxySecurity Group + proxy
PersistênciaNVMe / volume local contratadoSSD do bundle / volumes compatíveisEBS / volumes dedicados
Escala verticalMigrar plano KVMAlterar bundle/instância conforme suporteAlterar tipo de instância/recursos
Conclusão da task 02: suporte técnico de Docker confirmado nos provedores, mas a viabilidade do isolamento do Citizen Apps está pendente de implementação e de testes. A etapa 1 deve criar o template Compose de uma app piloto; não automatizar a criação pelo portal PHP.