Question 1

O que eu consigo fazer hoje na ZeroServer?

Accepted Answer

Você faz deploy de uma aplicação em container na malha comunitária. Traz uma imagem Docker pronta, define porta e variáveis de ambiente, e a plataforma sobe seu container em um node da rede. Você acompanha status e logs pela CLI (zsc-cli) ou pelo Portal Web.

Question 2

Como faço o deploy?

Accepted Answer

Por duas interfaces, escolha a que preferir: - CLI: zs login, depois zs deploy, zs list, zs logs, zs stop. - Portal Web: criar deploy, listar apps, ver status e logs pela interface do Developer.

Question 3

Preciso enviar meu código-fonte?

Accepted Answer

Não. A ZeroServer nunca faz build do seu código no MVP. Você traz uma imagem de container já pronta, de um registry seu (GHCR, Docker Hub ou equivalente). Isso é uma decisão de segurança e de simplicidade; seu código-fonte não trafega nem fica na plataforma. Build gerenciado (CI para imagem) está no roadmap de Fase 2.

Question 4

Minha aplicação recebe uma URL pública?

Accepted Answer

Sim. Cada app ganha uma URL única e acessível com TLS, no formato app-xxx.apps.zeroserver.cc. O roteamento é feito por um gateway self-hosted (FRP), sem depender de terceiros proprietários, coerente com a soberania da rede.

Question 5

Dá para subir uma app com banco de dados?

Accepted Answer

Sim, com modelo multi-container. Você descreve uma app composta por manifesto (estilo compose), por exemplo API Node mais Postgres, com rede privada entre os containers. O Postgres é um container seu, sob seu controle. Serviços gerenciados (DBaaS, storage, FaaS) são Fase 2.

Question 6

Meus dados estão isolados de outras aplicações no mesmo node?

Accepted Answer

Sim, esse é o pilar do modelo. Sua aplicação roda em container isolado, sem privilégio, com namespaces e cgroups, sem acesso ao host do Provedor nem a outros workloads. Detalhes e limites honestos na seção Segurança e confiança.

Question 7

Quanto custa?

Accepted Answer

Nada hoje. Estamos em beta pré-faturamento. Quando a cobrança entrar (Fase 2), será por hora de consumo, com preço transparente e comunicado com antecedência. Você não será cobrado retroativamente pelo período de beta.

Question 8

É open-source? Posso contribuir ou auto-hospedar?

Accepted Answer

Sim, o projeto segue valores open-source. Você pode acompanhar, contribuir e, no espírito da descentralização, rodar componentes você mesmo. Veja o repositório e os guias do projeto para começar.

Question 9

O que é ser um Provedor?

Accepted Answer

Você disponibiliza o tempo ocioso da sua máquina para a rede. Instala o agente da ZeroServer (zsc-agent), a máquina aparece online no sistema e passa a poder executar workloads de Developers quando estiver ociosa.

Question 10

Como conecto minha máquina?

Accepted Answer

Instalação em um comando. Baixe o instalador do agente no site (página /agent) e rode curl | sh; o agente registra a máquina, envia heartbeat com specs e ociosidade, e ela aparece online no seu dashboard. Os binários são assinados no CI.

Question 11

Qual sistema operacional preciso?

Accepted Answer

No beta, qualquer Linux com Docker roda o agente. Existe também um SO endurecido próprio, o zs-osc (Debian com foco zero-trust), que evolui em trilha paralela e não é obrigatório para participar agora.

Question 12

O que roda na minha máquina? É seguro para mim?

Accepted Answer

Roda o container do Developer, isolado, sem privilégio e sem acesso ao seu host. O agente monitora hardware e executa somente os containers comandados pela plataforma, por um canal autenticado. Detalhes na seção Segurança e confiança.

Question 13

A aplicação de um Developer pode acessar meus arquivos ou minha rede?

Accepted Answer

Esse é o objetivo do isolamento: não. O workload roda confinado em container, sem acesso ao sistema de arquivos do host nem a outros workloads. No zs-osc, o endurecimento vai além, com rootfs somente leitura (dm-verity), imagens assinadas verificadas e firewall com bloqueio por padrão. No beta em Linux comum, o isolamento é o de container padrão do Docker; use o zs-osc para a postura mais forte.

Question 14

Quanto de recurso a ZeroServer usa? Atrapalha meu uso?

Accepted Answer

O agente detecta ociosidade por limiar e prioriza rodar quando a máquina está livre. Você contribui quando quer; nos níveis mais baixos o compromisso de disponibilidade é flexível.

Question 15

Consigo ver o que está rodando e sair quando quiser?

Accepted Answer

Sim. O dashboard do Provedor mostra status da máquina, uso de CPU e RAM e apps rodando, com histórico de 24h. Você controla a participação da sua máquina.

Question 16

E se minha internet cair ou eu desligar a máquina?

Accepted Answer

O agente reconecta após queda de rede e os comandos são idempotentes. Se você desligar, a máquina sai da rede e volta quando o agente subir de novo.

Question 17

Qual é a postura de segurança da ZeroServer?

Accepted Answer

Segurança não é uma feature, é o pilar do negócio. Sem confiança, o modelo de nuvem comunitária não existe. Por isso somos transparentes sobre o que já está entregue e sobre o que ainda está no roadmap.

Question 18

Qual o modelo de ameaça que vocês assumem?

Accepted Answer

Tratamos todo node como não confiável por definição: é hardware de terceiros. Isso muda o desenho inteiro. As ameaças que endereçamos incluem: um node comprometido tentando ler dados do workload; um provedor tentando fraudar telemetria para inflar remuneração; interceptação de tráfego entre serviços; e um node malicioso tentando atacar o barramento que conecta a plataforma.

Question 19

Como funciona o isolamento da aplicação?

Accepted Answer

O workload do Developer roda em container isolado, sem privilégio, com namespaces e cgroups, sem acesso ao host do Provedor nem a outros workloads. No zs-osc, o SO endurecido, a postura é mais forte ainda: rootfs somente leitura com dm-verity, imagens assinadas (Cosign) verificadas pelo containerd, e firewall com política de bloqueio por padrão. No beta rodando em Linux comum com Docker, você tem o isolamento padrão de container; a camada extra do zs-osc é opcional e evolui em paralelo.

Question 20

A comunicação é cifrada?

Accepted Answer

Todo o tráfego entre os componentes é cifrado em trânsito (TLS/HTTPS). O agente autentica com um token de máquina, nunca com a credencial do usuário. Configurações sensíveis entregues ao node vão cifradas (AES-256-GCM), liberadas só depois que a máquina é reivindicada.

Question 21

Como o barramento de mensageria é protegido?

Accepted Answer

Os comandos de deploy trafegam por um barramento de mensagens (RabbitMQ). Como o node é não confiável, esse é o ponto onde um node malicioso poderia atacar a rede inteira. O desenho zero-trust, registrado no ADR-0001, fecha isso assim: - Identidade por node, não credencial compartilhada. Cada node autentica com um JWT curto e assinado (RS256), escopado só para a sua própria fila. Um dono com 10 máquinas tem 10 identidades separadas; um node invadido não alcança os outros. - Sem roubo de comando. Um node só lê comandos destinados a ele. Não consegue consumir a fila de outro node. - Sem falsificação de resultado. Cada node só publica resultado com a própria identidade, o que barra mentir sobre o estado de outra máquina. - Sem sabotar o barramento. O node não tem permissão para alterar a topologia do broker, então não consegue derrubar o barramento. - Broker fora da internet pública. O RabbitMQ não fica exposto; é alcançado por um túnel privado (FRP stcp) via gateway da ZeroServer. - Revogação rápida. Tokens são de vida curta; ao banir um node, a plataforma recusa a renovação e derruba a conexão viva.

Question 22

Como vocês tratam dados e conformidade?

Accepted Answer

Senhas são guardadas com hashing forte (bcrypt/Argon2), nunca em texto puro. Segredos ficam fora do código e fora do git. Toda entrada é validada e endpoints públicos têm rate limiting. Seguindo a LGPD, coletamos o mínimo e buscamos anonimizar telemetria quando possível.

Question 23

O que é revisado antes de cada go-live?

Accepted Answer

Rodamos um checklist de revisão de segurança específico da rede distribuída (zsc-security-review) e bloqueamos o lançamento se houver achado crítico em autenticação, isolamento ou criptografia. É requisito, não etapa opcional.

Question 24

O que já está em vigor no beta?

Accepted Answer

Isolamento de container por workload; TLS em trânsito entre serviços; token de máquina para o agente; entrega de configuração cifrada; barramento zero-trust com identidade por node (JWT/OAuth2), com o broker fora da internet pública; hashing forte de senha; validação de entrada e rate limiting; revisão de segurança obrigatória antes do go-live.

Question 25

Por que contamos o roadmap abertamente?

Accepted Answer

Um provedor precisa saber exatamente o que roda na máquina dele e um developer precisa saber onde seus dados estão protegidos e onde ainda não estão. Prometer segurança que não existe quebra a confiança que sustenta a comunidade. Preferimos mostrar o mapa completo.

PERGUNTAS FREQUENTES

Tem uma pergunta que não está aqui?