Modo servidor
hinow-cli serve: login sem tela, política, porta, serviço e atualização automática.
Atualizado em 16 de set. de 2026
hinow-cli serve sobe o HiNow Code sem interface: a API local e a ponte com o HINOW Connect. É como um servidor, um desktop no escritório ou uma máquina de CI fica disponível para receber sessões suas de outros lugares, sem ninguém na frente dela.
hinow-cli serve --policy allowCom --policy allow, as sessões remotas rodam sem perguntar: numa máquina sem tela não há quem responda a um "posso?". Sem a opção, vale a política salva com hinow-cli connect (o padrão é ask).
O serve aceita as mesmas opções de login. Com as variáveis de ambiente, nada fica no histórico:
export HINOW_EMAIL=voce@empresa.com
export HINOW_PASSWORD='...'
hinow-cli serve --policy allow --organization "Minha empresa"Se a máquina já fez hinow-cli login, basta hinow-cli serve.
| Opção | O que faz |
|---|---|
--policy allow|ask|deny | O que acontece quando outra máquina sua começa uma sessão aqui |
--port <n> | Porta da API local (padrão: aleatória). Útil com hinow-cli attach e run --attach |
--hostname | Endereço de escuta (padrão 127.0.0.1). Só abra para a rede com senha |
--autoupdate | Instala versões novas sozinho quando nada está rodando e reinicia (verifica uma vez por dia) |
--autoupdate-interval <min> | Minutos entre verificações com --autoupdate (padrão 1440) |
-u, -p, --code, --organization, --project | Login, como em hinow-cli login |
Senha da API local
A API local não tem senha por padrão e escuta só em 127.0.0.1. Se abrir para a rede (--hostname 0.0.0.0), defina HINOW_SERVER_PASSWORD (e, se quiser, HINOW_SERVER_USERNAME).
Para o servidor subir junto com a máquina e voltar sozinho se cair, instale-o como serviço. Um comando grava o serviço com os flags que você escolher, liga na hora e registra para os próximos boots:
hinow-cli login # antes, com o mesmo usuário
hinow-cli service install --policy allow --port 4096 --autoupdate
hinow-cli service status
hinow-cli service restart
hinow-cli service uninstallOs flags depois de install são os mesmos do serve, e ficam gravados no serviço. Credenciais não entram: o serviço usa o login salvo na máquina.
| Sistema | O que é criado |
|---|---|
| Linux | Unidade systemd do usuário em ~/.config/systemd/user/hinow-serve.service (como root, /etc/systemd/system/). Para subir no boot sem ninguém logado, ele roda loginctl enable-linger; se precisar de sudo, avisa. Logs: journalctl --user -u hinow-serve -f |
| macOS | LaunchAgent em ~/Library/LaunchAgents/ai.hinow.serve.plist (como root, LaunchDaemon), com KeepAlive. Logs em ~/Library/Logs/hinow-serve.log |
| Windows | Tarefa Agendada "HiNow Code server" que roda no seu logon. Ainda não testado em Windows de verdade |
hinow-cli status
hinow-cli connect statusconnect deve mostrar online · wss://connect.hinow.ai e bridge pid ... (serve). Daí em diante a máquina aparece na lista das suas outras máquinas.
Com --autoupdate, o servidor consulta downloads.hinow.ai uma vez por dia (a primeira, minutos depois de subir). Havendo versão nova, ele só a instala quando nada está em andamento: nenhuma sessão gerando, nenhuma aprovação ou pergunta esperando resposta, nenhum evento nos últimos dois minutos. Ocupado, tenta de novo a cada cinco minutos. Aí baixa o pacote da sua variante, confere o sha256, troca o binário e reinicia: como serviço, basta sair, que o systemd ou o launchd sobem a versão nova; fora de um serviço, ele reexecuta a si mesmo com os mesmos flags.
Sem --autoupdate, o serve não se atualiza: rode hinow-cli upgrade e hinow-cli service restart.
Uma ponte por máquina
Só um processo por máquina fala com o hub. Se você abrir a interface na mesma máquina, ela assume a conexão e o serve cede; ao fechar, o serve volta sozinho.