Gerenciamento de servidor Linux via hPanel e SSH, com Docker Compose e proxy instalados na própria VPS.
Estudo de viabilidade • 08 OUT 2026
Quanto custa operar o
Citizen Apps?
Comparativo técnico e financeiro de infraestrutura com Docker. Explore servidores, simule aplicações simultâneas e estime custos mensais e anuais — sem confundir projeções com benchmark real.
Cenário-base do projeto
Uma instância, múltiplas aplicações
Ubuntu + Docker Compose + proxy HTTPS. Containers isolados por aplicação, deploy inicialmente manual e integrações via Siebot API Hub.
MVP / estudo de capacidadeProvedores
3
Hostinger · Lightsail · EC2
Cenários Hostinger
3
4 / 8 / 16 GB
Aplicações de teste
1–40+
conforme CPU / RAM
Câmbio de referência
R$ 5,02
USD/BRL editável
Relatório técnico detalhado • Citizen Apps / Infraestrutura
As 3 tasks respondidas com evidências e limites claros
Análise do ZIP real, características Hostinger/AWS, política de isolamento, DNS, SSL, rota apps.siebot.cloud/controle_visitas, riscos encontrados e plano de validação. Informações oficiais separadas de simulações e testes ainda pendentes.
01 / Seleção de infraestrutura
Planos para colocar na mesa
Clique em um card para selecioná-lo no simulador. Hostinger inclui preço promocional e renovação; AWS é preço-base estimado em USD.
HOSTINGER VPS · três opções
AWS LIGHTSAIL · Linux / IPv4 público
AWS EC2 · t3a / us-east-1 / 730 h
Hostinger: os valores promocionais não constituem preço mensal avulso; a página informa pagamento integral antecipado. A tabela de horizonte multiplica uma tarifa selecionada e NÃO representa um contrato misto com período promocional seguido de renovação. Preços promocionais divulgados no site brasileiro e renovação informada para contratação de 24 meses; pagamento antecipado pode ser exigido. Lightsail: valores do pacote Linux + IPv4. EC2: inclui premissa de 100 GB gp3 (US$ 8/mês) + um IPv4 público (US$ 3,65/mês), sem tráfego, snapshots e taxas adicionais. Para AWS EC2, preços de computação se referem à região us-east-1, não a São Paulo.
02 / Laboratório
Teste simulado de escala e potencial
Modelo simplificado que combina teto de RAM, carga média de CPU e disco. Não mede throughput, IOPS ou P95 reais.
Configuração da simulação
Hostinger KVM 2
10 containers1 a 60
512 MB128–2048 MB
0,15 vCPU0,02–1 vCPU
1 GB0–10 GB
25%15–45%
Ajuste os controles para comparar consumo e disponibilidade.
Capacidade por RAM
—
containers
Capacidade por CPU
—
containers
Teto teórico conjunto
—
containers
Resultado da carga configurada
—
Cenário de simultaneidade
—
Como ler esta estimativa
CPU média é uma aproximação de consumo simultâneo; não equivale a reserva garantida nem considera créditos burstable, oversubscription, filas, banco externo ou picos curtos. A capacidade de produção deve ser definida com k6 e monitoramento real.
03 / Comparação financeira
Mensalidade, renovação e projeção anual
Premissas editáveis e comparação sem misturar promoções de contratação com custos recorrentes.
Câmbio inicial ilustrativo, próximo da abertura de 08/10/2026; não é taxa de cartão nem trava cambial. Extra mensal é um campo manual agregado, aplicado igualmente a todos os planos para efeito comparativo. Para Hostinger, o valor mensal é equivalente de um compromisso pré-pago; não é uma garantia de cobrança mês a mês. A projeção multiplica um preço estático e não simula mudanças futuras de oferta, renovação intermediária ou juros.
| Provedor / plano | RAM | vCPU | Disco | Mensal (R$) | 12 meses (R$) | USD / mês* |
|---|
*USD de planos Hostinger corresponde apenas ao equivalente convertido do preço em reais. Para EC2, custos de rede, créditos extras de CPU e outros serviços não incluídos. Para AWS, conversões em reais não contemplam tributos e spreads.
04 / Desenho do ambiente
Uma VPS, vários projetos isolados
Como definido no estudo: separação entre cadastro/governança e execução em Docker; a criação dos containers poderá ser manual.
Usuárioapps.siebot.cloud
→
Traefik / NginxHTTPS, TLS, roteamento
→
Dockervisitas · estoque · relatórios
→
API HubTokens, escopos, dados
Hospedagem
Cada Citizen App tem Dockerfile/Compose, restrições de RAM e CPU, healthcheck, rede segregada e deploy versionado. O proxy é o ponto de entrada público.
Governança
O Citizen Apps registra responsáveis, aprova solicitações de APIs e audita alterações. O portal não recebe acesso irrestrito ao Docker daemon.
05 / Fluxos de execução
Da autorização à aplicação no ar
Diagramas de sequência para comparar o que acontece em cada infraestrutura. As etapas representam uma arquitetura proposta para o Citizen Apps, não uma implantação já executada.
Experiência de VPS semelhante, com instância, IP estático, firewall e snapshots gerenciados no console AWS.
Maior granularidade de computação e rede: instância, EBS, Security Group, IAM e registro de imagem opcional.
Sequência por provedor
Hostinger KVM VPS + Docker Compose
Selecione uma opção para atualizar o diagrama e a explicação.
Fluxo de cadastramento, aprovação, publicação do container e consumo seguro das APIs.
Em telas menores, deslize horizontalmente para acompanhar as raias. Os números correspondem às etapas explicadas abaixo.
Requisição ou comandoLimites e redes privadasAprovação anterior ao deploy
Hostinger: configurar IP, DNS, firewall, backups e acesso SSH antes de subir containers.
O que ocorre em cada etapa
Em todas as opções, cadastro e autorização permanecem no portal Citizen Apps; o operador realiza o deploy manual/CI controlado; o proxy HTTPS recebe o tráfego e o backend acessa o Siebot API Hub com permissões restritas. Contêiner não é equivalente a VM isolada, e a quantidade suportada requer benchmark real.
06 / Projeto de execução
Da aprovação ao container publicado
Modelo proposto para o Citizen Apps: um control plane de governança e um hosting plane de execução. O deploy inicial é manual e auditável.
Plano de controle
O portal PHP cadastra aplicação, responsável, tenant, tecnologia, finalidade, ambiente e solicitações de API. O cadastro não dispara Docker automaticamente.
Permissões e escopos precisam ser validados no servidor, nunca apenas na interface.
Plano de hospedagem
Linux, Docker Engine, Compose, proxy reverso e uma imagem por Citizen App. Separar volumes, permissões, redes e logs. Definir quotas de CPU/memória.
Containers compartilham o kernel do host: isolamento não equivale a uma VM completa.
Plano de dados
Aplicações chamam o Siebot API Hub com credenciais limitadas. Evitar acesso direto aos bancos corporativos. Tokens e segredos ficam fora da imagem e do Git.
Banco externo reduz uso do SSD local, mas impõe dependência da rede/API.
Sequência operacional recomendada
1
Provisionar e proteger a VPS
Escolher região, IP público e Ubuntu LTS; configurar acesso SSH por chave, usuário administrativo não-root, firewall e atualizações de segurança. Manter SSH restrito a IPs administrativos quando possível.
2
Instalar Docker Engine e Compose
Instalar pelo repositório oficial, validar daemon, cgroups e limites. Proteger acesso ao grupo docker, que na prática oferece privilégios elevados ao host.
3
Publicar um proxy HTTPS
Apontar o DNS apps.siebot.cloud ao servidor. Liberar 80/443; usar Nginx ou Traefik com certificados TLS e redirecionamento HTTP→HTTPS. Evitar publicar diretamente as portas dos containers.
4
Implantar uma aplicação piloto
Criar Dockerfile, Compose, healthcheck, limites de CPU/RAM/PIDs, volumes necessários e rede privada. Publicar manualmente, testar rollback e reinicialização após reboot.
5
Validar integração e governança
Conectar via API Hub, testar token sem permissão, token revogado, tenant incorreto, timeout e indisponibilidade do gateway. Registrar responsável, versão e procedimento de resposta a incidentes.
6
Escalar somente após benchmark
Repetir ensaios com 1, 5, 10, 20 e 40 containers; fixar P95/erros máximos aceitáveis e uma margem de capacidade. Comparar custos totais com a demanda real antes de aumentar o plano.
Template ilustrativo de Compose
services:
controle_visitas:
image: registry.exemplo/controle_visitas:1.0.0
restart: unless-stopped
cpus: "0.50"
mem_limit: 512m
pids_limit: 100
read_only: true
security_opt:
- no-new-privileges:true
tmpfs:
- /tmp
networks: [app_net]
# secrets e volumes conforme necessidade
networks:
app_net:
internal: trueIlustrativo: o proxy precisará de conectividade controlada com a aplicação. A configuração final depende da stack, portas, volumes e healthcheck.
Path vs. subdomínio
Path: apps.siebot.cloud/controle_visitas. Facilita DNS e TLS, mas exige que o aplicativo suporte base path em redirecionamentos, CSS, JS e cookies.
Subdomínio: controle-visitas.apps.siebot.cloud. Favorece separação de origem no navegador, mas requer estratégia de DNS e certificados wildcard ou individuais.
O estudo detectou que o tenant era derivado do primeiro trecho do hostname. Ao mudar de siebert.siebot.cloud para apps.siebot.cloud, essa lógica deve ser corrigida para não resolver tenant como apps.
Decisão de segurança:
Não dar ao portal PHP acesso irrestrito ao socket Docker. Automatizar somente após haver pipeline isolado e revisado.
07 / Governança de risco
O que pode inviabilizar a produção
Itens específicos do projeto e da infraestrutura que devem constar da decisão, além do preço da VPS.
Segurança de acesso
Rever o login compartilhado que expõe credenciais do usuário à Citizen App; avaliar autenticação central com OIDC / Authorization Code + PKCE. Separar identidade humana de token de aplicação.
Autorização de API
A aprovação administrativa deve ser estritamente limitada às conexões solicitadas. Validar no back-end tenant, aplicação, escopo, ambiente e vínculo do token.
Disponibilidade
Uma VPS única é ponto único de falha. Planejar recuperação, snapshots, backup externo, teste de restauração, monitoramento e eventual segunda instância para maior disponibilidade.
Capacidade
2 vCPUs podem saturar antes de 8 GB RAM. Burst/CPU credits em EC2 t3a e limites efetivos de CPU do provedor exigem atenção. Não confundir container ocioso com usuário simultâneo.
Custos além do plano
Contabilizar impostos, contratação antecipada, renovação, câmbio, tráfego, backup, observabilidade, suporte operacional e horas de manutenção. Para EC2, tráfego e créditos excedentes podem alterar significativamente o total.
Reprodutibilidade
Corrigir migrations inconsistentes do repositório Citizen Apps, documentar deploy, fixar versões de imagens e manter caminho de rollback antes de criar novos ambientes.
08 / Referência técnica
Termos, unidades e limites
Uma legenda para discussão com gestão, desenvolvimento e infraestrutura.
vCPU
Unidade virtual de processamento alocada à instância; não mede sozinha a velocidade real. Frequência, arquitetura, créditos e concorrência importam.
RAM / MiB / GiB
Memória ativa dos processos. O simulador considera GB × 1024 MB como aproximação prática; provedores podem divulgar GB e GiB com convenções distintas.
NVMe / SSD / EBS
Formas de armazenamento. Capacidade em GB não informa desempenho de I/O, durabilidade de backups ou taxa de escrita.
Throughput / RPS
Requisições respondidas por segundo. Deve ser medido junto com latência e erros, não isoladamente.
P95 / P99
Percentis de latência: 95% ou 99% das requisições concluíram até aquele tempo. São úteis para observar degradação durante carga.
CPU burst / créditos
Alguns tipos de VM permitem picos temporários acima de uma base; funcionamento sustentado pode ficar limitado ou gerar cobrança.
Reverse proxy / TLS
O proxy recebe HTTPS, apresenta certificados e encaminha cada rota ao serviço interno, sem expor portas individuais diretamente.
Volume / imagem Docker
Imagem é o pacote versionado da aplicação; volume é armazenamento persistente que não desaparece com a recriação do container.
RTO / RPO
RTO é o tempo máximo aceitável de recuperação; RPO é a perda máxima tolerável de dados em tempo.
Isolamento de tenant
Conjunto de controles para impedir que uma aplicação ou usuário acesse dados de outro contexto organizacional.
09 / Critérios de validação
Do modelo à medição real
Este dashboard é uma peça de apresentação. As capacidades simuladas são hipóteses de planejamento, não ensaios executados nas máquinas.
Protocolo de benchmark proposto
- Implantar aplicações representativas PHP, Node e Python.
- Medir RAM em repouso e carga, vCPU, disco e I/O com 1, 5, 10, 20 e 40 containers.
- Gerar tráfego consistente via k6/wrk com diferentes níveis de concorrência.
- Registrar P50/P95/P99, erros, throughput, restart e tempo de resposta.
- Eleger limite operacional com margem e sem degradação excessiva.
Segurança / cuidados
Usar secrets externos à imagem, não-root, limites de PID, volumes apenas quando necessários, TLS e backup fora da VPS. Validar isolamento de tenant, fluxo de autenticação e escopos de API antes da produção.
Decisão inicial
Hostinger KVM 2 e Lightsail de 8 GB são bons pontos de partida para laboratório. KVM 4 pode oferecer margem superior de CPU e memória, mas a decisão definitiva depende de ensaios e requisitos de localização e disponibilidade.
Fontes e notas
Hostinger Brasil · VPS KVM · preços promocionais, renovação e recursosAWS Lightsail · especificações e preços Linux/IPv4AWS EC2 · t3a · valores de us-east-1AWS EBS · preços de armazenamentoAWS VPC · cobrança de IPv4 públicoDocker · segurança do daemon e dos containersDocker · restrições de recursosFontes revisadas em 08/10/2026. Câmbio usado como referência ilustrativa, inicializado em R$ 5,02 por dólar. Preços comerciais podem mudar sem aviso. EC2 com disco gp3 100 GB a US$ 0,08/GB-mês e IPv4 a US$ 0,005/h são hipóteses para us-east-1. Os preços do Lightsail podem ter diferentes franquias de tráfego por região. A residência de dados e o custo de transferência devem ser validados antes de contratar.