Para quem é isso
- Você não quer infraestrutura de mais ninguém no caminho dos seus arquivos.
- Você lida com material sensível — arquivos jurídicos, registros financeiros, conteúdo regulado — que não pode passar pelos servidores de outra pessoa.
- Você já tem um servidor, NAS ou VPS sempre ligado, preparado para esse tipo de job.
- Você move volume suficiente para que usar a sua própria banda saia mais barato do que pagar pela nossa.
Como vai funcionar
- Instale o runner em um hardware que você controla — um NAS, uma VPS, uma máquina Linux sempre ligada ou um Raspberry Pi 24/7.
- Conecte-o à sua conta Syncologic usando um código de pareamento de uso único.
- Conecte os provedores de origem e destino pelo painel.
- Quando começar um job, escolha o runner que você acabou de parear em vez da opção hospedada.
- O runner puxa o trabalho, transfere os arquivos entre as APIs dos provedores e devolve um relatório quando terminar.
O diagrama do hero acima mostra o caminho. Os arquivos vão direto da API da origem para o seu runner e em seguida para o destino. A gente vê qual é o job e quando rodou — nunca o conteúdo dos arquivos.
Sem mexer no firewall
Funciona atrás de NAT residencial, atrás de proxy corporativo, atrás de qualquer coisa que permita HTTPS de saída. Você não abre porta nenhuma. O runner faz uma conexão de saída para a gente e fica esperando trabalho; quando um job é despachado, ele puxa um lease de execução de curta duração, roda a transferência e devolve eventos de progresso.
Sem regras de firewall de entrada. Sem IP público. Sem proxy reverso. Sem túnel.
Onde você rodaria
O runner é pequeno o bastante para conviver com outros serviços leves em hardware que você já tem — um Synology, QNAP ou TrueNAS ligado 24/7, um servidor Linux de homelab ou mini-PC, uma VPS pequena (Hetzner, Fly, DigitalOcean, OVH), uma workstation sempre ligada funcionando como pequeno servidor doméstico, ou um dispositivo da classe Raspberry Pi para backups mais lentos e de baixo throughput.
Ele se importa com uma rede confiável e disco suficiente para buffers de staging; não se importa com a distro ou o hardware que você escolheu.
Suas credenciais ficam com você
Os tokens OAuth dos provedores ficam vinculados ao runner — criptografados em repouso com uma chave derivada da sua inscrição, sem nunca sair do runner. A gente vê identificadores de provedor, escopos e metadados de execução; nunca refresh tokens, nunca conteúdo de arquivos.
Desative o runner e revogue a inscrição no painel — os tokens que ele guardava ficam inúteis.
Hospedado versus seu próprio servidor
Os dois modos usam o mesmo painel, as mesmas definições de job, a mesma prévia e os mesmos relatórios de conclusão. A única diferença é por onde os bytes passam — e o que isso significa para custo e confiança.
Nos nossos servidores (Cloud Runner)
- Por onde os bytes passam: origem → nossa infraestrutura → destino.
- Onde ficam as credenciais: criptografadas na nossa infraestrutura, de curta duração.
- Esforço de setup: nenhum — escolha no dropdown.
- Quando faz mais sentido: praticidade, jobs muito grandes que você não quer hospedar.
- Modelo de preço: baseado em uso na nossa infraestrutura.
- Requisitos de rede: nenhum.
No seu próprio servidor (Private Runner)
- Por onde os bytes passam: origem → seu servidor → destino.
- Onde ficam as credenciais: no seu runner, sem nunca sair de lá.
- Esforço de setup: instalar e parear uma vez.
- Quando faz mais sentido: privacidade, dados sensíveis, homelabs, usuários de alto volume.
- Modelo de preço: você paga pelo software e entra com a banda.
- Requisitos de rede: HTTPS de saída a partir do runner.
Código visível
Você pode auditar como o runner move os arquivos antes de instalar — o código é publicado para qualquer pessoa ler. Pretendemos manter essa propriedade enquanto crescemos.
Onde você rodaria seu Private Runner — NAS, servidor de homelab, VPS ou workstation? Conte para a gente na lista de espera abaixo — é a primeira pergunta que vamos fazer depois do seu e-mail.