Casos em que o Syncthing é adequado:

• Sincronizar arquivos entre Windows, macOS, Linux, Android e NAS;
• Querer um VPS como nó de retransmissão e réplica sempre online;
• Não querer entregar os arquivos a um serviço de nuvem de terceiros;
• Precisar de conexões diretas rápidas na LAN e alternar automaticamente entre conexão direta ou Relay na internet;
• Querer controlar por pasta o envio, o recebimento, a retenção de versões e as regras de ignorados;
• Conseguir manter você mesmo o VPS, as permissões, o firewall e os backups independentes.

Casos em que não é adequado:

• Precisar que várias pessoas editem o mesmo documento do Office online;
• Precisar de links de compartilhamento no navegador, visualização online e permissões complexas;
• Tratar o diretório de sincronização como único backup, sem snapshots nem backups offline;
• Precisar de auditoria empresarial rigorosa, aprovação de arquivos e prevenção de vazamento de dados;
• Ter muitos arquivos pequenos mudando com frequência sem avaliar o custo de disco, banco de dados e varredura.

Se você precisa mais de acesso web e compartilhamento no estilo de nuvem, consulte o tutorial de OpenList em VPS. Se gerencia principalmente contratos, notas fiscais e digitalizações, consulte o tutorial de arquivamento de documentos com OCR do Paperless-ngx.

O Syncthing é ideal para "estes dispositivos são todos meus e quero que os arquivos se mantenham consistentes automaticamente". Ele não tem um sistema de contas central; cada dispositivo confia em outro por meio do Device ID, e as transferências de arquivos usam criptografia TLS.

Uma arquitetura típica é a seguinte:

手机 ───────────────┐
                    │
笔记本 ── 直连/Relay ├── VPS Syncthing 常在线节点
                    │
家中 NAS ───────────┘

O VPS oferece três vantagens principais:

1. Quando outros dispositivos não estão online ao mesmo tempo, o VPS guarda a cópia mais recente;
2. Quando a rede doméstica não tem entrada pública, é mais fácil os dispositivos se conectarem ao VPS;
3. Você pode manter diretórios de versões e backups extras no VPS.

Porém, se o celular e o notebook estão na mesma LAN, o Syncthing normalmente tentará uma conexão direta na LAN e não precisará passar pelo VPS. Não o interprete como uma nuvem tradicional em que todo o tráfego precisa passar pelo VPS.

Este artigo se baseia na versão estável verificada em agosto de 2026:

Syncthing v2.1.3
Docker image: syncthing/syncthing:2.1.3

Portas comuns:

O Syncthing também pode usar Relays públicos. Mesmo que a 22000 não esteja aberta ao público, os dispositivos ainda podem se conectar por um Relay, mas a velocidade e a latência costumam ser piores do que em uma conexão direta.

O Syncthing em si é leve; os recursos são consumidos principalmente pela varredura de arquivos, cálculo de hashes, indexação do banco de dados e retenção de versões:

A capacidade do disco deve cobrir pelo menos:

当前同步数据
+ 文件版本目录
+ 临时下载文件
+ Syncthing 索引数据库
+ 独立备份预留

Se o diretório de origem tem 100 GB e você ativa a retenção de versões de longo prazo, um VPS de 80 GB certamente não será suficiente. O histórico de versões deve ter um período de retenção e um número máximo; ele não pode crescer sem limite.

Confirme o Docker e o Compose:

docker version
docker compose version

Se você não tem Docker, consulte primeiro o guia prático de implantação com Docker.

Crie os diretórios de configuração, dados de sincronização e versões:

sudo mkdir -p /opt/syncthing/config
sudo mkdir -p /opt/syncthing/data
sudo mkdir -p /opt/syncthing/versions
sudo chown -R 1000:1000 /opt/syncthing
sudo chmod 750 /opt/syncthing
cd /opt/syncthing

O contêiner oficial usa UID 1000 e GID 1000 por padrão. Verifique primeiro as permissões dos diretórios de destino no host, para evitar que o contêiner inicie mas não consiga gravar os arquivos sincronizados.

Crie /opt/syncthing/compose.yaml:

services:
  syncthing:
    image: docker.io/syncthing/syncthing:2.1.3
    container_name: syncthing
    hostname: vps-syncthing
    network_mode: host
    restart: unless-stopped
    environment:
      PUID: "1000"
      PGID: "1000"
      UMASK: "0022"
      STGUIADDRESS: ""
    volumes:
      - ./config:/var/syncthing/config
      - ./data:/var/syncthing/data
      - ./versions:/var/syncthing/versions
    healthcheck:
      test:
        - CMD-SHELL
        - curl -fkLsS -m 2 127.0.0.1:8384/rest/noauth/health | grep -q OK
      interval: 1m
      timeout: 10s
      retries: 3

A documentação oficial do Docker recomenda host network, porque a rede bridge padrão faz o Syncthing ver apenas o endereço do contêiner, o que afeta a descoberta na LAN e a decisão de conexão direta. Com host network, o Syncthing controla seus próprios endereços de escuta e portas, então a configuração do firewall precisa ser mais cuidadosa.

Deixe STGUIADDRESS vazio para que o Syncthing use o endereço da GUI do arquivo de configuração. A configuração inicial normalmente escuta em 127.0.0.1:8384, evitando expor a interface de administração diretamente à internet.

Verifique a configuração:

cd /opt/syncthing
docker compose config --quiet

Inicie:

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=150 syncthing

Verifique o estado de saúde da GUI:

curl -fsS http://127.0.0.1:8384/rest/noauth/health

Quando estiver saudável você verá OK. Se a conexão for recusada, verifique os logs do contêiner e o endereço de escuta:

sudo ss -lntup | grep -E ':(8384|22000)\b'
docker compose logs --tail=250 syncthing

Crie um túnel no seu próprio computador:

ssh -L 8384:127.0.0.1:8384 your_user@your_vps_ip

Abra no navegador:

http://127.0.0.1:8384

Após fazer login pela primeira vez, faça três coisas imediatamente:

• Defina um nome de usuário da GUI e uma senha forte e separada;
• Confirme que o GUI Listen Address continua sendo 127.0.0.1:8384;
• Dê nomes claros aos dispositivos, como vps-sync, home-nas, work-laptop.

O Device ID identifica o certificado do dispositivo, não é a senha da GUI. Compartilhe-o apenas com os dispositivos que precisam ser pareados; a API Key da GUI e a senha de administrador devem ser mantidas em segredo.

Se você quer que os dispositivos se conectem diretamente ao VPS, abra a 22000 TCP e UDP:

sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp
sudo ufw status numbered

Normalmente não abra a 21027/UDP em um VPS público. Ela é usada principalmente para descoberta por broadcast na LAN; a sincronização pela internet depende de descoberta global, endereços estáticos ou Relay.

Confirme que a 8384 não está exposta publicamente:

sudo ufw status
sudo ss -lntp | grep ':8384'

Enquanto a GUI escutar em 127.0.0.1, mesmo que o firewall permita a 8384 por engano, o mundo externo normalmente não conseguirá se conectar. Mas uma configuração segura deve restringir tanto o endereço de escuta quanto o firewall; não dependa de apenas uma camada.

Se todos os dispositivos já entraram no WireGuard, você pode não abrir a 22000 pública e permitir apenas a sub-rede da VPN:

sudo ufw allow from 10.66.66.0/24 to any port 22000 proto tcp
sudo ufw allow from 10.66.66.0/24 to any port 22000 proto udp

No endereço do dispositivo remoto do cliente, insira:

tcp://10.66.66.1:22000
quic://10.66.66.1:22000

Depois você pode desativar a descoberta global e o Relay para reduzir a exposição de metadados externos. Para implantar o WireGuard, consulte o tutorial de WireGuard VPN em VPS.

Atenção: após desativar a descoberta e o Relay, uma configuração de endereço errada não terá caminho de fallback automático. Confirme o roteamento da VPN e a acessibilidade da porta 22000 antes de desativar os mecanismos de conexão automática.

Encontre o Device ID deste dispositivo na GUI do VPS e, em outro dispositivo, escolha Add Remote Device. Insira o Device ID do VPS e defina o nome e o endereço do dispositivo.

Processo de pareamento recomendado:

1. No dispositivo A, adicione o dispositivo B;
2. No dispositivo B, aceite o dispositivo pendente;
3. As duas partes verificam o Device ID exibido;
4. Não compartilhe ainda diretórios importantes; compartilhe apenas uma pasta de teste;
5. Após confirmar o tipo de conexão, o upload/download e o comportamento de exclusão, migre os dados.

Um dispositivo exibindo Connected não significa que a pasta já esteja compartilhada. A confiança no dispositivo e o compartilhamento de pastas são duas camadas de configuração distintas; você precisa selecionar os dispositivos permitidos nas configurações da pasta.

Adicione uma pasta no VPS:

Folder Label: Personal Sync
Folder ID: personal-sync
Folder Path: /var/syncthing/data/personal
Folder Type: Send & Receive

O diretório correspondente no host é:

/opt/syncthing/data/personal

Crie e corrija as permissões:

sudo mkdir -p /opt/syncthing/data/personal
sudo chown -R 1000:1000 /opt/syncthing/data/personal

O Folder ID deve ser idêntico entre os dispositivos que compartilham a pasta, mas o Folder Path pode ser diferente em cada dispositivo. Por exemplo, o Windows usa D:\Sync\Personal e o VPS usa /var/syncthing/data/personal.

O versionamento do Syncthing protege principalmente contra "exclusões e sobrescritas sincronizadas de outros dispositivos". Tipos comuns:

• Trash Can: move os arquivos antigos para o diretório de versões;
• Simple File Versioning: adiciona carimbos de data/hora às versões antigas e mantém um número fixo;
• Staggered File Versioning: mantém as versões recentes de forma densa e as antigas progressivamente mais esparsas;
• External File Versioning: chama um script personalizado para tratar as versões.

Em cenários domésticos e pessoais, você pode começar com o Staggered File Versioning e definir o diretório de versões como:

/var/syncthing/versions/personal

Caminho correspondente no host:

/opt/syncthing/versions/personal

Limitação importante: o versionamento normalmente trata as alterações vindas de dispositivos remotos. Se você sobrescrever um arquivo diretamente no mesmo dispositivo localmente, uma versão do Syncthing não é necessariamente criada. Dados realmente importantes ainda precisam de snapshots, restic ou backups em armazenamento de objetos.

Crie o .stignore na raiz da pasta de sincronização para ignorar caches, artefatos de build e arquivos temporários:

(?d).DS_Store
Thumbs.db
~*
*.tmp
node_modules
.git
.cache

Verifique as regras primeiro em um diretório de teste. Ignorar arquivos de banco de dados, configurações de aplicativos ou diretórios ocultos pode fazer faltar dados críticos durante a recuperação.

O .stignore é uma regra local do dispositivo; não presuma que ele se propagará automaticamente a todos os dispositivos como você espera. Ao usar vários dispositivos, verifique as regras de ignorados e os resultados da varredura em cada um.

Quando dois dispositivos offline modificam o mesmo arquivo ao mesmo tempo, ao se reconectarem pode ser gerado um arquivo semelhante a:

report.sync-conflict-20260808-103000-DEVICE.txt

Etapas de tratamento:

1. Pause a pasta correspondente;
2. Compare o arquivo original e o arquivo de conflito;
3. Mescle manualmente ou mantenha a versão correta;
4. Exclua a cópia de conflito desnecessária;
5. Retome a sincronização e observe se os conflitos reaparecem.

O Syncthing não entende a estrutura interna do Word, do Excel ou de bancos de dados e não consegue mesclar arquivos complexos automaticamente. Arquivos com gravação contínua, como SQLite, discos de máquinas virtuais e bancos de dados de e-mail, não são adequados para sincronização direta em tempo real; use a exportação própria do aplicativo ou um backup consistente.

Windows, macOS e Linux podem usar os clientes da plataforma correspondente. No Android, as opções comuns incluem clientes mantidos pela comunidade; o iOS é limitado pela execução em segundo plano e pelo sistema de arquivos, e o comportamento de clientes de terceiros difere da versão de desktop.

No celular, observe:

• As políticas de economia de energia do sistema podem pausar a sincronização em segundo plano;
• A sincronização por rede móvel consome muitos dados;
• As permissões do diretório de fotos podem ser restringidas pelo sistema;
• O cliente pode não continuar varrendo depois que você sai dele;
• Limite o escopo da pasta antes da primeira sincronização.

Não comece sincronizando todo o armazenamento do celular ou o diretório pessoal do usuário. Comece com uma pasta de teste e verifique o carregamento, o Wi-Fi, o segundo plano e o comportamento em conflitos.

O Syncthing propaga fielmente as alterações, incluindo as ruins:

• Exclusão acidental de arquivos;
• Criptografia em massa por ransomware;
• Aplicativos gravando dados corrompidos;
• Scripts com defeito renomeando ou esvaziando diretórios;
• Usuários sobrescrevendo a versão errada em todos os dispositivos.

Prepare pelo menos um backup independente:

Syncthing 实时同步
+ VPS/存储快照
+ restic 或 rclone 异地备份
+ 定期恢复演练

Consulte o tutorial de simulação de backup e restauração em VPS.

Pare o contêiner antes de fazer backup da configuração do Syncthing:

cd /opt/syncthing
docker compose stop
sudo tar -czf syncthing-config-$(date +%F).tar.gz config compose.yaml
docker compose start
chmod 600 syncthing-config-*.tar.gz

Os dados de sincronização devem ser tratados com uma ferramenta de backup independente; não os empacote apenas no mesmo disco do VPS.

Antes de atualizar, registre a imagem atual e faça backup da configuração:

cd /opt/syncthing
docker inspect syncthing --format '{{.Config.Image}}'
sudo tar -czf syncthing-before-upgrade-$(date +%F).tar.gz config compose.yaml

Após alterar a tag da imagem, execute:

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200 syncthing

Após atualizar, verifique:

• O login na GUI e a lista de dispositivos;
• O tipo de conexão direta, QUIC ou Relay;
• O estado de varredura e sincronização das pastas;
• Se o diretório de versões ainda é gravável;
• As regras de ignorados e as senhas de pasta;
• Se a verificação de saúde passa.

O Syncthing 2.x pode atualizar o banco de dados interno. Não reverta sem critério para uma versão principal anterior sem um backup da configuração; leia primeiro as Release Notes e, se necessário, teste em um nó réplica.

• A GUI 8384 escuta apenas no local ou na rede privada WireGuard;
• A GUI tem nome de usuário e senha forte definidos, e a API Key não é pública;
• Apenas a 22000 TCP/UDP realmente necessária está aberta ao público;
• Um VPS público normalmente não abre a 21027/UDP;
• A descoberta global e o Relay podem ser desativados quando não forem necessários;
• Os Device IDs são trocados apenas com dispositivos que precisam ser pareados;
• O versionamento é ativado em pastas importantes, mas o diretório de versões não é tratado como único backup;
• Bancos de dados, discos de máquinas virtuais e arquivos de aplicativos com gravação contínua não são sincronizados;
• Arquivos de conflito, itens com falha e espaço em disco são verificados periodicamente;
• Configuração, dados e backups usam caminhos de recuperação diferentes;
• A versão é fixada e a configuração é copiada antes de atualizar;
• As senhas de pastas Receive Encrypted são guardadas em dispositivos confiáveis e em um gerenciador de senhas.

Para uso pessoal, você pode começar com um VPS de 1 núcleo e 1 GB, Syncthing v2.1.3, uma pasta de teste e gerenciamento por túnel SSH. Confirme primeiro que o pareamento de dispositivos, a criação, modificação e exclusão de arquivos, os conflitos e a recuperação de versões se comportam como esperado, e depois amplie gradualmente o escopo da sincronização.

Uma arquitetura estável de Syncthing não é "todos os dispositivos sincronizam bidirecionalmente o disco inteiro", mas sim dividir as pastas por finalidade, escolher o modo correto para cada nó, restringir a GUI e as portas de sincronização e manter um backup realmente recuperável fora do sistema de sincronização.

• Documentação oficial do Syncthing
• Syncthing v2.1.3 Release
• Documentação oficial do Docker do Syncthing
• Documentação de versionamento de arquivos do Syncthing