Hospedar o seu próprio servidor

O serviço por trás do Eidos online também roda no seu próprio servidor, para um time que mantém a definição do seu produto nas próprias mãos. Um projeto nele funciona como no Eidos online: sincronização, membros, níveis e convites, e histórico. Os arquivos, o histórico e as contas dele ficam só no seu servidor, e os membros dele entram com as contas próprias dele, nunca com o Eidos online.

No começo: leia isto primeiro

O servidor está pronto para ser testado com um time pequeno, e parte do que um serviço de produção precisa ainda não está lá:

• Sem pacote. Ainda não há pacote npm, imagem Docker nem unidade de serviço do sistema. O servidor é compilado a partir do código-fonte do Eidos MD, como abaixo.
• Sem email. O servidor ainda não consegue enviar email. Ele imprime cada código de entrada (--print-codes), e cada convite por email, na própria saída, e quem o roda os repassa.

Do que você precisa

• Uma máquina que o seu time alcance, macOS ou Linux, com Node.js 22.5 ou posterior e pnpm 11.
• git, e acesso ao código-fonte do Eidos MD.
• Para qualquer coisa além de um teste em uma rede, um nome de domínio e um proxy reverso que sirva HTTPS (abaixo).
• Disco para os seus projetos. Não há limite de armazenamento além do seu.

Cada pessoa continua usando o app de desktop; o servidor é só onde os projetos delas se encontram.

Compilar e executar

Pegue o código-fonte, instale as dependências do serviço e compile-o:

git clone https://gitlab.com/the-virtual-panda/eidosmd.git
cd eidosmd
pnpm install --frozen-lockfile --filter @eidosmd/service...
pnpm --filter @eidosmd/service build

Inicie-o com uma pasta para os dados dele e o email do dono dele:

node service/dist/src/serve.js --data ./eidos-data --owner [email protected] --print-codes

O dono é a pessoa que roda o servidor e tem a licença dele. O servidor precisa de --owner no primeiro início, e o guarda; inicie-o de novo com outro email e o dono muda. O dono entra no servidor como qualquer outra pessoa, com esse email.

Ele responde com onde guarda os dados e onde escuta:

eidos service: /home/eidos/eidos-data
  http://127.0.0.1:6280  (sign-in at http://127.0.0.1:6280/api/auth)

No Node 22 ele também imprime um ExperimentalWarning sobre o SQLite, em que as contas são guardadas. É inofensivo.

Quando alguém entra, o código da pessoa aparece na mesma saída:

sign-in code for [email protected]: 196907

Repasse-o a ela, e ela o digita no diálogo de entrada do app como digitaria um código vindo de um email. Ctrl+C, ou um SIGTERM de quem quer que o rode, para o servidor e fecha a conexão de cada app; cada app mantém as suas alterações e as envia quando o servidor volta.

Mantenha-o rodando

Ainda não vem nenhuma unidade systemd nem imagem de contêiner. Rode o comando acima sob o gerenciador de serviços que você já usa, com o diretório de trabalho no checkout, e reinicie-o em caso de falha.

Configuração

Opção	O que faz
--data <folder>	Obrigatória. A pasta em que o servidor guarda tudo. É criada se não existir.
--owner <email>	O email da conta que roda o servidor e tem a licença dele. Obrigatória no primeiro início; dada depois, muda o dono.
--port <n>, -p <n>	A porta em que escutar. 6280 por padrão. O servidor escuta em toda interface de rede, então mantenha a porta atrás de um firewall quando um proxy a serve.
--url <address>	O endereço em que as pessoas alcançam o servidor, como https://eidos.example.com. Por padrão http://127.0.0.1:<port>. Atrás de um proxy, deve ser o endereço do proxy: a entrada confere que as requisições vêm dele, e as recusa caso contrário.
--print-codes	Imprime cada código de entrada na saída do servidor. Obrigatória por enquanto, já que o servidor ainda não tem email.
--web-origin <origin>	Confia em outra origem de onde um navegador entra, como um site de conta que você hospeda. Repita-a para várias. A maioria dos servidores não precisa dela.
--licence-file <file>	Um arquivo com a chave de licença do servidor. A chave também pode vir da variável de ambiente EIDOS_LICENCE, ou ser salva em Este servidor no app. Veja a licença.
--database <address>	Guarda as contas, os projetos e o histórico no PostgreSQL, postgres://usuario:senha@host/banco, em vez da pasta de dados. Ou EIDOS_DATABASE_URL. Veja Armazenamento.
--assets <where>	Guarda os arquivos de recursos numa pasta à sua escolha, num bucket compatível com S3 (s3://bucket) ou num contêiner do Azure Blob Storage (azure://conta/conteiner), em vez da pasta de dados. Ou EIDOS_ASSETS_URL. Veja Armazenamento.

O segredo. As sessões são assinadas com um segredo. Defina-o na variável de ambiente EIDOS_SERVICE_SECRET, ou deixe-a sem definir e o servidor cria um no primeiro início e o guarda em secret na pasta de dados, legível só pelo usuário com que ele roda. Guarde-o: um servidor iniciado com outro segredo encerra a sessão de todo dispositivo, e cada um diz Sincronização pausada até a sua pessoa entrar de novo.

Apple e Google. A entrada oferece Continuar com a Apple e Continuar com o Google assim que as chaves deles estão no ambiente do servidor, e só códigos por e-mail até lá. Para o Google, defina EIDOS_GOOGLE_CLIENT_ID e EIDOS_GOOGLE_CLIENT_SECRET de um cliente web do Google Cloud cujo URI de redirecionamento seja <url>/api/auth/callback/google. Para a Apple, defina EIDOS_APPLE_CLIENT_ID (um Services ID), EIDOS_APPLE_TEAM_ID, EIDOS_APPLE_KEY_ID e EIDOS_APPLE_PRIVATE_KEY (o texto do arquivo .p8 da chave de Sign in with Apple), com <url>/api/auth/callback/apple como URL de retorno do Services ID; a Apple só aceita um endereço HTTPS. O próprio servidor assina o segredo de cliente da Apple com a chave, então ele nunca precisa ser renovado. Um endereço usado com a Apple ou o Google e por e-mail é uma conta só.

A pasta de dados contém:

accounts.sqlite	As contas e as suas sessões.
projects/	Uma pasta por projeto: os documentos ao vivo dos seus arquivos, o seu histórico, os seus membros e os seus convites.
secret	O segredo das sessões, quando não está definido no ambiente.
server.json	O dono do servidor, o id que ele criou para si no primeiro início, a sua chave de licença e a última resposta à sua verificação de licença. Legível só pelo usuário com que ele roda.

Armazenamento

Por padrão, o servidor guarda tudo na pasta de dados: as contas num arquivo SQLite, os projetos e o histórico como arquivos, e os arquivos de recursos em blobs/. É tudo de que um servidor numa só máquina precisa. Para o servidor de uma empresa, ele pode guardá-los na sua própria infraestrutura, cada parte escolhida separadamente:

O quê	Onde	Como
Contas, projetos, histórico, planos e o estado da licença	A pasta de dados (SQLite e arquivos)	o padrão
	PostgreSQL	--database postgres://usuario:senha@host/banco
Arquivos de recursos (imagens, PDFs)	A pasta de dados	o padrão
	Qualquer pasta, como um compartilhamento de rede montado ou o Azure Files	--assets /srv/eidos-assets
	Um bucket compatível com S3: Amazon S3, Cloudflare R2, MinIO	--assets s3://bucket[/prefixo]
	Um contêiner do Azure Blob Storage	--assets azure://conta/conteiner[/prefixo]

PostgreSQL com os arquivos de recursos no disco do próprio servidor:

EIDOS_SERVICE_SECRET=… node service/dist/src/serve.js --data ./eidos-data --owner [email protected] --url https://eidos.exemplo.com --print-codes \
  --database postgres://eidos:…@db.exemplo.com/eidos --assets /srv/eidos-assets

O servidor cria as próprias tabelas no banco, ao lado das tabelas das contas, na primeira vez que inicia. Dê a ele um banco só seu.

Um bucket S3 usa AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_REGION (us-east-1 se não for definido) do ambiente, e EIDOS_S3_ENDPOINT para um serviço que não seja o da Amazon, como https://<conta>.r2.cloudflarestorage.com. As chaves precisam ler, gravar e excluir objetos no bucket.

Um contêiner do Azure usa EIDOS_AZURE_SAS, uma assinatura de acesso compartilhado para o contêiner (ou a conta) com leitura, gravação e exclusão. Crie uma no portal do Azure, em Assinatura de acesso compartilhado da conta de armazenamento, ou com az storage container generate-sas, e dê a ela uma validade longa: no dia em que vencer, o servidor deixa de conseguir ler e gravar os recursos.

Ao iniciar, o servidor verifica cada armazenamento gravando um arquivo pequeno e removendo-o em seguida. Um banco que ele não alcança, ou chaves que não conseguem gravar, o param ali, com uma mensagem que nomeia o armazenamento e o motivo. Ele nunca imprime uma senha ou uma chave, e Este servidor no app diz onde cada parte é guardada.

Com os registros no PostgreSQL e os recursos num bucket ou contêiner, o servidor não guarda no próprio disco nada de que um backup precise. Defina o segredo com EIDOS_SERVICE_SECRET e o --data pode ficar de fora: uma máquina nova iniciada com o mesmo banco, os mesmos recursos e o mesmo segredo é o mesmo servidor, com contas, projetos e licença. Um servidor continua sendo um só processo: rode um de cada vez contra um banco.

HTTPS e um proxy reverso

O servidor fala HTTP simples. Coloque-o atrás de um proxy reverso que sirva HTTPS, deixe passar as conexões WebSocket e encaminhe para a porta do servidor, e inicie o servidor com --url definido como o endereço que as pessoas usam.

node service/dist/src/serve.js --data ./eidos-data --owner [email protected] --url https://eidos.example.com --print-codes

Com o Caddy, que obtém e renova o certificado sozinho e deixa passar os WebSockets por padrão, o Caddyfile inteiro é:

eidos.example.com {
  reverse_proxy 127.0.0.1:6280
}

Com o nginx, o que importa são os cabeçalhos do WebSocket e um tempo limite de leitura longo; o certificado fica por sua conta:

server {
    listen 443 ssl;
    server_name eidos.example.com;
    ssl_certificate     /etc/ssl/eidos.example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/eidos.example.com/privkey.pem;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:6280;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 1h;
    }
}

client_max_body_size é o tamanho de um arquivo de asset, uma imagem ou um PDF, que o proxy deixa passar. Sirva o servidor na raiz do seu nome de host: um endereço com um caminho depois, como https://example.com/eidos, não é suportado.

Apontar o app para o seu servidor

No app de desktop, abra o diálogo de entrada (Entrar no menu da conta, no pé da barra de atividades, ou Adicionar uma conta quando você já tem sessão), depois Usar um servidor próprio, e digite o endereço do servidor.

Um nome de host sozinho, eidos.example.com, é alcançado por HTTPS; localhost e 127.0.0.1 por HTTP. Para um teste na sua própria rede sem HTTPS, digite o endereço inteiro, http://192.168.1.20:6280, e inicie o servidor com o mesmo --url. A conta é do próprio servidor, separada de qualquer uma no Eidos online, e o app mantém as duas lado a lado.

A partir daí tudo funciona como no Eidos online: a primeira pessoa a ativar a sincronização para uma pasta é a proprietária do projeto e convida o resto, cujos links apontam para o seu servidor.

Backups

Tudo o que o servidor guarda está na pasta de dados dele, a menos que o guarde no PostgreSQL ou num bucket (Armazenamento): nesse caso, faça backup do banco e do bucket com as ferramentas deles, e guarde o segredo junto. Para a pasta de dados: Para fazer backup, pare o servidor, copie a pasta (com secret, ou anote EIDOS_SERVICE_SECRET ao lado dela) e inicie-o de novo. Enquanto ele está parado, as pessoas continuam trabalhando e as alterações delas aguardam nas suas máquinas; elas são enviadas assim que ele volta.

Para restaurar, pare o servidor, coloque a pasta copiada no lugar da pasta de dados e inicie-o com o mesmo segredo. As alterações feitas nas máquinas das pessoas desde a cópia são enviadas de novo conforme cada app se reconecta. A pasta de cada membro também é uma cópia completa do que é compartilhado com ele.

Atualizações

No checkout, pegue o código-fonte novo, compile-o e reinicie o servidor:

git pull
pnpm install --frozen-lockfile --filter @eidosmd/service...
pnpm --filter @eidosmd/service build

Depois reinicie-o. O banco de dados das contas atualiza as próprias tabelas quando o servidor inicia. Mantenha o servidor e os apps de desktop do seu time em versões da mesma época: com quais versões do app cada servidor funciona ainda não está escrito.

A licença

Até três editores, um servidor é grátis, sem licença e sem conta na Eidos. Os seus leitores e comentaristas são grátis e sem limite, assim como os agentes, que trabalham com o acesso da pessoa por quem agem. Um editor é qualquer pessoa que pode editar pelo menos um dos projetos do servidor, contada uma vez, por mais projetos que edite, o dono também quando edita.

A partir de um quarto editor, uma licença cobre todos os editores, não só os que passam de três: um time de quatro precisa de quatro assentos, e dez assentos cobrem dez editores.

Além do que o servidor cobre (um quarto editor sem licença, mais editores do que assentos, ou 30 dias sem resposta da Eidos), os que se tornaram editores mais recentemente aguardam, como acontece com um assento vencido no Eidos online: continuam editando nas próprias máquinas, as alterações deles aguardam ali, contadas no widget de sincronização, e eles leem e comentam como antes. Nada é bloqueado nem removido, e as alterações deles são enviadas assim que o servidor os cobre.

Este servidor, nas Configurações do app de desktop, é a página do dono para tudo isso, mostrada enquanto ele está com a sessão iniciada no servidor: a licença (Licença para 10 editores, ou Grátis, três editores), a chave, quando o servidor verificou pela última vez, e os seus editores, quantos estão cobertos, e Alterar para escolher quais. Com quatro editores e sem licença, ela avisa: quatro editores, três deles grátis, então o servidor precisa de quatro assentos, e até lá os que se tornaram editores mais recentemente aguardam.

Comprar uma licença

Uma licença é um assento para cada editor de um servidor, ao preço de um assento do Eidos online: US$ 4,99 por mês ou US$ 49,90 por ano cada um, então quatro assentos custam US$ 19,96 por mês ou US$ 199,60 por ano, e dez custam US$ 49,90 por mês ou US$ 499,00 por ano. Ela é comprada com Licenciar um servidor, em Servidores, dentro de Plano e cobrança no site da sua conta (Licenciar este servidor em Este servidor o abre), a partir de quatro assentos, já que três ou menos não cobrem nada que o servidor não tenha de graça. Mudar depois os assentos de um servidor passa de quatro direto para nenhum, o que encerra a licença: o servidor volta a ser grátis para três editores, e nada é removido. A chave de licença, que começa com eidos_srv_, é mostrada uma única vez quando os assentos são comprados, com Copiar. Em Servidores, Alterar assentos os altera, Criar uma chave nova substitui a chave (a antiga continua pelos seus 30 dias) e Liberar solta a chave do servidor que a tem, para um servidor que sai do ar.

Dê a chave ao servidor em Este servidor (Chave de licença, depois Salvar, que a verifica na hora), ou com --licence-file <file> ou a variável de ambiente EIDOS_LICENCE quando ele inicia.

O que o servidor conta à Eidos

O servidor verifica a sua licença quando inicia, uma vez por dia, em Verificar agora, e quando a sua contagem de editores passa do que ela cobre. Uma verificação envia a chave, o id próprio do servidor, um número de uso único e quantos editores ele conta: nunca um projeto, um arquivo ou um membro. Um servidor sem chave não envia nada.

Quando não consegue alcançar a Eidos, o servidor segue com a última resposta por 30 dias, e Este servidor diz até quando. Depois de 30 dias sem resposta, ele volta a três editores de graça, sem remover nada, até que uma resposta cubra todos de novo. Uma chave que já está em uso em outro servidor oferece Trazer para cá; uma chave que foi substituída segue até acabarem os seus 30 dias, e uma licença que terminou leva o servidor de volta a três editores de graça.

Uma licença por acordo

Uma empresa com um acordo com a Eidos pode receber uma licença em vez de comprar assentos: ela cobre todos os editores, não tem data de fim e nunca é cobrada. Só a Eidos a emite. É uma chave, como uma comprada, que começa com eidos_srv_, e aparece em Servidores na conta a que é concedida, marcada Por acordo. Dê-a ao servidor do mesmo jeito: cole-a em Este servidor e clique em Salvar, ou inicie o servidor com --licence-file <arquivo> ou EIDOS_LICENCE. Este servidor passa a dizer Licenciado por acordo · editores ilimitados, com a quem foi concedida.

Ela é verificada como qualquer licença, uma vez por dia, enviando as mesmas poucas coisas, então o servidor precisa alcançar online.eidosmd.com para recebê-la. Depois disso, a Eidos não responder nunca a encerra: o servidor continua com ela por mais tempo que a verificação fique sem resposta. Guarde a chave como qualquer segredo: quem a tiver pode mover a licença para o próprio servidor.

Testes contra o staging

Para quem contribui com a Eidos, nunca para o servidor de uma equipe: um servidor pode ser verificado contra o serviço de staging da Eidos, cujas respostas são assinadas por uma chave de teste em que nenhuma versão confia. Inicie-o com --licence-service https://online-staging.eidosmd.com --trust-key eidos-staging-1=bxl5sumIh6dS9EkTok18mLz_hIvyzE1ppdRsDQUiM2k (ou EIDOS_TRUST_KEYS), e ao iniciar ele diz que está confiando numa chave de licença de teste. Sem essas opções, um servidor confia só na chave da Eidos.