Syncthing — ciągła synchronizacja plików bez chmury

Synchronizacja plików między maszynami ma dwa dobrze znane rozwiązania i oba mają tę samą wadę. Dropbox i Dysk Google działają bez zarzutu, kosztują proporcjonalnie do pojemności i trzymają dane u siebie — co przy części zastosowań jest po prostu wykluczone. Materiały klienta objęte umową powierzenia. Katalog projektowy z dokumentacją, której nie wolno wynieść. Kopia plików produkcyjnych, której nie chcemy w cudzej chmurze.

Drugie rozwiązanie to rsync w cronie. Działa, jest przewidywalny i ma dwa ograniczenia wpisane w konstrukcję: synchronizuje w jedną stronę i o ustalonej godzinie. Do kopii zapasowej to wystarcza. Do katalogu, w którym dwie osoby pracują na tych samych plikach — nie.

Syncthing (github.com/syncthing/syncthing) robi to trzecią drogą: synchronizuje ciągle, w obie strony i bez serwera pośredniczącego. Urządzenia rozmawiają ze sobą bezpośrednio, a jeśli nie mogą — przez przekaźnik, który nie widzi treści. Poniżej: jak to działa, jakie decyzje trzeba podjąć przy projektowaniu topologii (typy folderów są tu ważniejsze, niż się wydaje), co zmieniła wersja 2.0 — i gdzie leży granica, za którą Syncthing przestaje być właściwym narzędziem, bo to jest część, na której ludzie tracą dane.

Stan projektu

Dane z API GitHuba na 21 września 2026:

88 415 gwiazdek i 5457 forków — jeden z najpopularniejszych projektów w kategorii self-hostingu w ogóle,
repozytorium założone 26 listopada 2013, czyli trzynaście lat ciągłego rozwoju. Kod w Go, licencja MPL-2.0,
najnowsze wydanie v2.1.5 z 8 września 2026, poprzedzone kandydatami v2.1.4-rc.1 i rc.2 z sierpnia — projekt prowadzi regularny proces wydawniczy z wersjami kandydującymi, co przy narzędziu operującym na cudzych plikach jest właściwą praktyką,
382 otwarte zgłoszenia, ostatni commit z 8 września 2026,
projekt ma odznakę CII Best Practices od Core Infrastructure Initiative.

Trzynaście lat i osiemdziesiąt osiem tysięcy gwiazdek przy narzędziu, któremu powierza się pliki, to najmocniejszy argument, jaki można podać — i rzadki przypadek, w którym nie trzeba się zastanawiać, czy projekt przeżyje najbliższe lata.

Cele projektu wyjaśniają wszystkie decyzje

README zawiera listę celów w kolejności ważności i warto ją znać, bo wyjaśnia zarówno to, co w Syncthingu jest, jak i to, czego w nim nie ma:

Bezpieczny od utraty danych — ochrona danych użytkownika jest nadrzędna, projekt podejmuje każdą rozsądną ostrożność, żeby nie uszkodzić plików,
Bezpieczny przed atakującym — dane nie mogą być podatne na podsłuch ani modyfikację przez nieuprawnionych, niezależnie od pozostałych celów,
Łatwy w użyciu,
Automatyczny — interakcja użytkownika wymagana tylko wtedy, gdy jest absolutnie konieczna,
Powszechnie dostępny — ma działać na każdym typowym komputerze, z uwzględnieniem tego, że nie każdy ma najnowszy sprzęt,
Dla osób prywatnych — projekt jest przede wszystkim o wzmocnieniu indywidualnego użytkownika.

Punkt szósty jest kluczem do zrozumienia ograniczeń. Syncthing celowo nie jest narzędziem do zarządzania flotą urządzeń w firmie — i dlatego nie ma w nim centralnej konsoli, polityk ani grupowego wdrażania konfiguracji. To nie brak, to zapisany w celach zakres.

Jak to działa bez serwera

Nie ma centralnego serwera przechowującego pliki. Zamiast tego każde urządzenie ma tożsamość kryptograficzną: identyfikator urządzenia to skrót SHA-256 jego certyfikatu, przedstawiony w czytelnej dla człowieka formie. Cały ruch między urządzeniami jest chroniony TLS-em, a przy zestawianiu połączenia odcisk certyfikatu jest porównywany z listą zaakceptowanych urządzeń.

Z tego wynika cały model zaufania i jest on zaskakująco prosty: dodanie urządzenia do klastra to wymiana identyfikatorów. Nie ma kont, haseł do usługi ani zaproszeń przez pośrednika. Jeśli mój identyfikator nie jest na Twojej liście, nie zestawimy połączenia — i odwrotnie.

Do tego dochodzi jeszcze jedna warstwa weryfikacji, o której dokumentacja wspomina osobno: przychodzące żądania o dane pliku są sprawdzane co najmniej pod tym kątem, że żądana nazwa musi istnieć w lokalnym indeksie i w globalnym modelu. Urządzenie z klastra nie może więc poprosić o dowolny plik z dysku.

Odkrywanie i przekaźniki — z jawnym rachunkiem prywatności

Skoro nie ma serwera, urządzenia muszą się jakoś znaleźć. Syncthing ma na to trzy mechanizmy i — co jest rzadkością wartą pochwały — dokumentacja zawiera osobny rozdział o wycieku informacji, wypisujący konsekwencje każdego z nich.

Odkrywanie globalne (domyślnie włączone): urządzenie wysyła ogłoszenie co 30 minut do serwerów odkrywania, zawierające identyfikator urządzenia i porty nasłuchu. Zapytania o adres innego urządzenia zawierają jego identyfikator. Połączenie jest po TLS z weryfikacją certyfikatu serwera. Konsekwencje, które dokumentacja podaje wprost:

podsłuchujący w internecie może wywnioskować, które maszyny mają włączonego Syncthinga i jakie mają identyfikatory,
operator serwera odkrywania może mapować adresy urządzeń na adresy IP i wnioskować, które urządzenia są ze sobą połączone,
domyślne serwery odkrywania są hostowane przez jedną osobę z projektu. Wskazanie własnego serwera powoduje, że do domyślnych nie idą żadne dane.

Odkrywanie lokalne (domyślnie włączone): rozgłoszenia IPv4 i multicast IPv6 co 30 sekund, z identyfikatorem urządzenia i portem. Podsłuchujący w sieci lokalnej dowie się tego samego, tylko lokalnie.

Przekaźniki (domyślnie włączone, ale używane tylko wtedy, gdy bezpośrednie połączenie jest niemożliwe): ruch jest przekazywany przez publiczny przekaźnik. Kluczowa właściwość — połączenie pozostaje szyfrowane end-to-end, a przekaźnik retransmituje zaszyfrowane dane jak router. Ale urządzenie musi się w przekaźniku zarejestrować, więc operator zna nasz adres IP i identyfikator, a także widzi wolumen ruchu. Syncthing okresowo próbuje wrócić na połączenie bezpośrednie i porzuca przekaźnik, gdy się to uda — bo przekaźnik jest wyraźnie wolniejszy. Własne przekaźniki wskazuje się w adresie nasłuchu:

relay://private-relay-1.example.com:443/?id=ITZRNXE-YNROGBZ-HXTH5P7-VK5NYE5-QHRQGE2-7JQ6VNJ-KZUEDIU-5PPR5AM

Praktyczny wniosek dla wdrożenia firmowego: w zamkniętej sieci wyłącza się oba mechanizmy odkrywania i przekaźniki, a adresy urządzeń podaje statycznie. Wtedy poza naszą infrastrukturę nie wychodzi nic — ani ogłoszenie, ani zapytanie. Utrata jest jedna: urządzenia o dynamicznych adresach spoza sieci lokalnej przestają być osiągalne.

Typy folderów, czyli miejsce, w którym projektuje się topologię

To jest najczęściej pomijana część konfiguracji i jednocześnie ta, która decyduje, czy Syncthing będzie narzędziem, czy źródłem utraty danych. Folder udostępniany urządzeniu ma jeden z trzech trybów.

Send & Receive — domyślny, dwukierunkowy. Zmiany idą w obie strony.

Send Only — kopia odniesienia. Zmiany z pozostałych urządzeń są odbierane, ale nie stosowane, więc folder może pokazać stan „niezsynchronizowany", mimo że wszystko działa poprawnie. Gdy to nastąpi, w szczegółach folderu pojawia się czerwony przycisk Override Changes — i jego działanie warto zrozumieć przed kliknięciem: narzuca stan tego hosta całemu klastrowi. Zmiany w plikach zostaną nadpisane wersją z tego hosta, a pliki, których na nim nie ma, zostaną usunięte wszędzie.

Receive Only — logiczne przeciwieństwo. Zmiany z klastra są stosowane i rozprowadzane dalej, ale lokalne modyfikacje nie wychodzą. Lokalne zmiany są zachowywane i nie powodują lokalnego stanu „niezsynchronizowany", ale u innych to urządzenie wygląda na nieaktualne. Do cofnięcia lokalnych zmian jest przycisk Revert Local Changes: dodane pliki zostaną usunięte, zmodyfikowane i usunięte — ściągnięte ponownie z klastra.

Praktyczna konsekwencja, którą warto zapamiętać jako regułę: serwer, który ma trzymać kopię plików, dostaje folder w trybie receive only, nie dwukierunkowy. W trybie dwukierunkowym przypadkowe usunięcie pliku na laptopie propaguje się na kopię i kopia przestaje być kopią.

Konflikty rozstrzygane deterministycznie

Przy synchronizacji dwukierunkowej konflikt jest kwestią czasu, więc warto znać dokładne reguły — a są one w pełni deterministyczne, nie losowe.

Gdy plik został zmodyfikowany na dwóch urządzeniach jednocześnie i treść faktycznie się różni, jeden z nich jest przemianowywany na:

<nazwa>.sync-conflict-<data>-<czas>-<modifiedBy>.<rozszerzenie>

Reguły rozstrzygania:

przegrywa plik o starszym czasie modyfikacji i to on zostaje oznaczony jako konfliktowy,
przy równych czasach modyfikacji przegrywa plik z urządzenia o większej wartości pierwszych 63 bitów identyfikatora — arbitralne, ale przewidywalne i identyczne na wszystkich urządzeniach,
gdy konflikt jest między modyfikacją i usunięciem, a usunięcie wygrywa, plik również trafia do kopii konfliktowej.

Jest jeszcze jedna właściwość, która na początku wygląda na błąd, a jest świadomą decyzją: pliki konfliktowe są traktowane jak zwykłe pliki i propagują się po całym klastrze. Uzasadnienie z dokumentacji: konflikt jest wykrywany i rozstrzygany na jednym urządzeniu, ale jest równie prawdziwym konfliktem wszędzie indziej — a Syncthing nie wie, która wersja jest „lepsza" z perspektywy człowieka. Efekt bywa zaskakujący (nagle wszędzie mamy dwa pliki), ale alternatywą byłoby ciche utracenie jednej z wersji.

Wersjonowanie — cztery strategie

Wszystkie odkładają zastępowane i usuwane pliki do katalogu .stversions w folderze, różnią się polityką ich życia.

Kosz (Trash Can) — najprostsza: plik zastąpiony albo usunięty zmianą z innego urządzenia trafia do kosza, a wcześniejsza kopia o tej samej nazwie jest nadpisywana. Opcja cleanoutDays usuwa pliki starsze niż N dni; zero oznacza brak automatycznego usuwania,
Prosta (Simple) — jak kosz, plus liczba zachowywanych wersji. Przy wartości 5 i pięciu zmianach pliku zdalnie zobaczymy pięć kopii ze znacznikami czasu,
Schodkowa (Staggered) — najciekawsza, bo gęstość historii maleje z jej wiekiem. Przedziały: pierwsza godzina — najstarsza wersja z każdych 30 sekund; pierwszy dzień — z każdej godziny; pierwsze 30 dni — z każdego dnia; dalej — z każdego tygodnia, aż do maksymalnego wieku podanego w dniach (0 = na zawsze). Zwróć uwagę, że zachowywana jest najstarsza wersja w przedziale — i to jest właściwy wybór, bo chroni stan pliku sprzed nadpisania, a nie po nim,
Zewnętrzna (External) — delegacja do własnej komendy uruchamianej bezpośrednio przed zastąpieniem pliku. Warunek: komenda musi usunąć plik z folderu, inaczej Syncthing zgłosi błąd. Tu wchodzi dowolna własna logika, na przykład wysłanie starej wersji do S3.

Wykluczanie plików

Bez tego mechanizmu synchronizacja katalogu projektowego oznacza wożenie po klastrze node_modules, vendor i plików tymczasowych systemu. Wykluczenia definiuje plik .stignore w korzeniu folderu — w innych miejscach nie jest brany pod uwagę.

Dwie właściwości tego pliku są nieoczywiste i warto je znać od razu. .stignore nigdy nie jest synchronizowany na inne urządzenia — każde ma własny. Ale może dyrektywą #include wciągnąć plik, który jest synchronizowany, i to jest droga do wspólnych reguł dla całego zespołu przy zachowaniu lokalnych wyjątków.

Składnia wzorców jest bliska temu, co znamy z .gitignore, z jedną fundamentalną różnicą: decyduje pierwszy pasujący wzorzec, nie ostatni.

// komentarz zaczyna się od dwóch ukośników

// wspólne reguły zespołu, synchronizowane w folderze
#include shared-ignores.txt

(?d).DS_Store            // usuwalne, gdy blokuje usunięcie katalogu
(?d)Thumbs.db

/node_modules            // tylko w korzeniu folderu
**/vendor                // na dowolnym poziomie
*.log
{*.tmp,*.swp}            // zbiór alternatyw

Elementy, które wracają w praktyce:

* nie przechodzi przez separator katalogów, ** przechodzi. Wzorzec te*ne dopasuje subdir/telephone, ale nie tele/phone; te**ne dopasuje oba,
Zwykła nazwa dopasowuje się na każdym poziomie — wzorzec foo obejmuje foo, subdir/foo i katalog o tej nazwie. Ograniczenie do korzenia wymaga wiodącego ukośnika,
Prefiks (?d) pozwala usunąć wykluczony plik, gdy blokuje on usunięcie katalogu. Bez niego plik ignorowany potrafi zablokować usunięcie pustego skądinąd katalogu — dokumentacja ostrzega o tym osobno, a dotyczy to zwłaszcza plików generowanych przez system,
Prefiks (?i) włącza dopasowanie bez rozróżniania wielkości liter. Na macOS i Windowsie wzorce i tak są nieczułe na wielkość,
prefiksy można łączyć w dowolnej kolejności ((?d)(?i)), ale nie w jednym nawiasie,
Negacja przez ! ma koszt wydajnościowy, o którym łatwo nie wiedzieć: wzorzec zaprzeczony niezakotwiczony w korzeniu wymusza pełne skanowanie wszystkich katalogów w poszukiwaniu pasujących nazw, mimo że i tak zostaną wykluczone. Wzorce zakotwiczone (!/baz) tego nie powodują — i to jest realna różnica w czasie skanowania dużych folderów.

Na Windowsie jest dodatkowy szczegół: \ jest separatorem ścieżki, więc do ucieczki znaków specjalnych służy |. Dyrektywa #escape=\ na początku pliku przywraca \ jako znak ucieczki i / jako separator, co pozwala używać jednego pliku wykluczeń na wszystkich systemach — a przy zespole pracującym na trzech systemach jest to warunek, żeby wspólny plik reguł miał sens.

Urządzenia niezaufane, czyli szyfrowanie po stronie klienta

Funkcja koncepcyjnie najciekawsza w całym projekcie — i oznaczona w dokumentacji jako beta, przeznaczona do testów, co trzeba wziąć poważnie.

Mechanizm: przy udostępnianiu folderu konkretnemu urządzeniu ustawia się hasło folderu. Dane wysyłane do tego urządzenia są szyfrowane, dane odbierane od niego — odszyfrowywane. Szyfrowanie używa hasła i identyfikatora folderu, przy czym dokumentacja radzi przechować bezpiecznie i niezawodnie oba (identyfikator jest wprawdzie zapisany w znaczniku folderu, ale ostrożność nie zawadzi).

Scenariusz z dokumentacji jest dokładnie tym, o co pytają klienci: mamy zaufany laptop T1 z wrażliwymi dokumentami w postaci jawnej i niezaufany serwer w chmurze U1, gdzie dane mają leżeć nieczytelne. Ustawiamy hasło folderu na T1 przy udostępnianiu go U1. Dane na dysku T1 pozostają jawne, dane wysyłane do U1 stają się nieczytelne bez hasła.

Najlepsze przychodzi dalej: można dodać drugie zaufane urządzenie T2 z tym samym hasłem folderu i synchronizować dane przez U1 — bez żadnego bezpośredniego kontaktu między T1 i T2. Czyli serwer w chmurze pełni rolę zawsze dostępnego węzła pośredniego, nie widząc treści. To jest kompletna odpowiedź na pytanie „chcę własny Dropbox, ale węzeł, który stoi zawsze, jest u dostawcy" — pod warunkiem zaakceptowania statusu beta.

Co zmieniła wersja 2.0

Wielu ludzi zna Syncthinga z linii 1.x, a wersja 2.0 z 12 sierpnia 2025 przyniosła zmiany, których część zmienia semantykę działania. Ogłoszenie zaczyna się zresztą uczciwie: „to pierwsze wydanie serii 2.0, spodziewajcie się szorstkich krawędzi i zachowajcie poczucie przygody".

Baza danych z LevelDB na SQLite. Przy pierwszym uruchomieniu następuje migracja, która przy większych instalacjach może być długa. Uzasadnienie: nowa baza jest łatwiejsza do zrozumienia i utrzymania, i — jak pisze projekt — „miejmy nadzieję, mniej wadliwa",
Usunięte elementy nie są już trzymane w bazie na zawsze — są zapominane po sześciu miesiącach. To jest zmiana semantyki, którą trzeba znać: jeśli w naszym scenariuszu usunięcia mają działać po dłuższej przerwie (urządzenie włączane raz na rok), trzeba ustawić --db-delete-retention-interval na zero albo dłuższy okres,
Trzy połączenia domyślnie między urządzeniami w wersji 2: jedno na metadane indeksu i dwa na wymianę danych,
Logi strukturalne (komunikat plus pary klucz-wartość), poziomy logowania per pakiet, nowy poziom WARNING wstawiony między INFO i ERROR (to, co dawniej nazywało się WARNING, jest teraz ERROR). Poziom INFO stał się bardziej gadatliwy i raportuje podejmowane akcje synchronizacji. Nowa flaga --log-level; opcje --verbose i --logflags zostały usunięte i są ignorowane, jeśli ktoś je poda,
Zmodernizowane parsowanie opcji. Stare długie opcje z jednym minusem nie są już wspierane — -home trzeba podać jako --home. Część opcji zmieniła nazwy, część stała się podkomendami, a wszystkie opcje trybu serve są przyjmowane również jako zmienne środowiskowe,
Usunięto wykrywanie przesuniętych danych metodą kroczącego skrótu — z uzasadnieniem, że „efektywnie nigdy nie pomagało", a bez tego skanowanie i synchronizacja są szybsze i wydajniejsze. Rzadko się widzi projekt, który usuwa własną funkcję z takim uzasadnieniem,
Nie tworzy się już „domyślny folder" przy pierwszym uruchomieniu,
Zmieniło się rozstrzyganie konfliktów z usunięciami — usunięcie może teraz wygrać, a usuwany plik trafia do kopii konfliktowej,
Część platform straciła gotowe binaria ze względu na złożoność kompilacji skrośnej z SQLite: netbsd, openbsd/386 i openbsd/arm, windows/arm, solaris, illumos, linux/ppc64, dragonfly.

Dystrybucja jest przy tym wygodna: repozytorium APT pod apt.syncthing.net oraz obrazy Dockera na Docker Hubie i w rejestrze GitHuba, z tagiem :2 śledzącym wersję główną:

docker pull docker.io/syncthing/syncthing:2
# albo
docker pull ghcr.io/syncthing/syncthing:2

Bezpieczeństwo dostaw

Element, na który przy narzędziu dotykającym plików warto patrzeć: binaria wydań są podpisane GPG kluczem dostępnym ze strony projektu, a wbudowany mechanizm automatycznej aktualizacji używa wkompilowanego podpisu ECDSA (i jest wyłączony w części kanałów dystrybucji). Binaria dla macOS i Windows są dodatkowo podpisane kodowo. Zgłoszenia podatności idą na security@syncthing.net — nie na forum i nie do publicznego trackera, co dokumentacja podkreśla osobno.

Do czego to nadaje się w naszej pracy — i do czego nie

Ta sekcja jest ważniejsza od poprzednich, bo Syncthing jest narzędziem, które łatwo zastosować niewłaściwie, a skutkiem jest utrata danych.

Dobre zastosowania:

Katalog materiałów projektowych między maszynami zespołu — grafiki źródłowe, nagrania, duże pliki, których nie chcemy w repozytorium ani w cudzej chmurze,
Kopia plików użytkowników z produkcji na serwer zapasowy — folder w trybie receive only na serwerze docelowym, z wersjonowaniem schodkowym. Zmiana na produkcji dociera w sekundach, a nie w nocy,
Przenoszenie dużych zbiorów między serwerami bez pośrednika i bez limitów transferu u dostawcy,
Katalog wymiany z klientem, gdy klient nie może albo nie chce korzystać z usług chmurowych. Urządzenie niezaufane z hasłem folderu pozwala postawić zawsze dostępny węzeł u dostawcy, nie pokazując mu treści.

Złe zastosowania — i to są konkretne sposoby stracenia danych:

Syncthing nie jest kopią zapasową. Synchronizacja propaguje usunięcie: plik usunięty na laptopie zniknie wszędzie. Wersjonowanie w .stversions to łagodzi i przy folderze receive only jest to nawet niezła kopia, ale nie zastępuje niezależnego backupu — bo błąd operatora, uszkodzenie plików albo szyfrujące oprogramowanie wymuszające okup rozejdą się po klastrze tak samo jak każda inna zmiana,
Nie synchronizuj katalogu, do którego pisze działająca aplikacja. Bazy danych, pliki blokad i cokolwiek zapisywanego w trakcie synchronizacji kończy się uszkodzonym plikiem po drugiej stronie. Katalog storage/app aplikacji w Laravelu ma sens tylko wtedy, gdy zapis idzie z jednego miejsca, a pozostałe węzły są w trybie receive only. Do współdzielonego zapisu z wielu instancji jest S3 albo wolumen sieciowy — nie synchronizacja,
Nie oczekuj centralnego zarządzania flotą. Wynika to wprost z celu „dla osób prywatnych". Przy dziesiątkach urządzeń trzeba to obudować samodzielnie (jest REST API i konfiguracja w pliku) albo wybrać narzędzie zaprojektowane pod flotę.

Pułapki

Domyślnie włączone odkrywanie globalne wysyła ogłoszenia co 30 minut do zewnętrznych serwerów. Nie zawiera treści plików, ale zawiera identyfikator urządzenia i pozwala operatorowi serwera wnioskować, które urządzenia są ze sobą połączone. W środowisku firmowym to jest ustawienie do świadomej decyzji,
Przycisk „Override Changes" narzuca stan hosta całemu klastrowi, włącznie z usunięciem plików, których na nim nie ma. Nie jest to przycisk „napraw synchronizację",
Pliki konfliktowe rozchodzą się po klastrze — to jest zamierzone, ale przy większej liczbie użytkowników potrafi zaśmiecić katalog,
Migracja z 1.x na 2.x przebudowuje bazę i przy dużych instalacjach zajmuje czas. Warto to zaplanować, a nie odkryć,
Usunięcia zapominane po sześciu miesiącach to zmiana semantyki w 2.0 — istotna dla urządzeń podłączanych rzadko,
Stare opcje wiersza poleceń przestały działać w 2.0, a --verbose i --logflags są ignorowane bez ostrzeżenia,
Szyfrowane urządzenia niezaufane są w wersji beta — dokumentacja mówi to wprost. Przy danych, których utrata jest niedopuszczalna, warto poczekać albo mieć niezależną kopię,
Część platform straciła gotowe binaria w 2.0; na nietypowym systemie trzeba budować ze źródeł (co przy Go jest zresztą jednym poleceniem),
Przy przekaźniku transfer jest wyraźnie wolniejszy niż przy połączeniu bezpośrednim. Jeśli synchronizacja „nagle zwolniła", to jest pierwsza rzecz do sprawdzenia.

Podsumowanie

Syncthing jest jednym z najdojrzalszych projektów w kategorii self-hostingu i jednym z niewielu, przy których nie trzeba się zastanawiać nad ryzykiem porzucenia. Rozwiązuje realny problem — ciągłą, dwukierunkową synchronizację bez pośrednika — i robi to z architekturą, którą da się zrozumieć w całości. Co z tego wynika:

Projekt jest wyjątkowo dojrzały — 88 415 gwiazdek, pierwszy commit w listopadzie 2013, wydanie v2.1.5 z 8 września 2026, proces wydawniczy z wersjami kandydującymi, odznaka CII Best Practices,
Model zaufania jest prosty — identyfikator urządzenia to odcisk jego certyfikatu, ruch idzie po TLS, a dodanie urządzenia to wymiana identyfikatorów,
W sieci firmowej wyłącz odkrywanie globalne i przekaźniki i podaj adresy statycznie, jeśli nic nie ma wychodzić na zewnątrz,
Serwer trzymający kopię dostaje folder receive only — to jedna decyzja, która odróżnia kopię od lustra propagującego przypadkowe usunięcia,
Wybierz wersjonowanie schodkowe tam, gdzie historia ma znaczenie: gęsta przez pierwszą godzinę, rzadsza z wiekiem, z limitem w dniach,
Poznaj reguły konfliktów zanim wystąpią — przegrywa starszy czas modyfikacji, a pliki sync-conflict rozchodzą się celowo po całym klastrze,
Urządzenia niezaufane z hasłem folderu pozwalają postawić zawsze dostępny węzeł u dostawcy bez pokazywania mu treści — ale są w wersji beta,
Przy migracji z 1.x zaplanuj czas na przebudowę bazy i sprawdź, czy nie zależysz od usunięć starszych niż pół roku,
Wyklucz node_modules i vendor w .stignore, pamiętając, że decyduje pierwszy pasujący wzorzec, prefiks (?d) odblokowuje usuwanie katalogów, a niezakotwiczona negacja wymusza pełne skanowanie,
Syncthing nie jest backupem. To najważniejsze zdanie w tym wpisie i najczęściej ignorowane,
Nie synchronizuj katalogu zapisywanego przez działającą aplikację z wielu stron jednocześnie. Do tego są S3 i wolumeny sieciowe.

Licencja: Syncthing jest rozpowszechniany na Mozilla Public License 2.0 — pełnoprawnej licencji open source z copyleftem na poziomie pliku, a nie całego dzieła. Dla komercyjnego użytkownika oznacza to swobodę bez zastrzeżeń: wolno instalować Syncthinga u siebie i u klientów, w dowolnej skali, jako element świadczonej usługi, bez żadnych warunków — MPL nie stawia wymagań samemu korzystaniu z programu. Obowiązek publikacji dotyczy wyłącznie zmian wprowadzonych w plikach objętych licencją: fork z poprawkami wymaga udostępnienia tych poprawek na MPL-2.0, ale kod, który jedynie działa obok albo woła REST API Syncthinga, nie staje się przez to dziełem pochodnym. To ten sam, łagodny reżim, który omawialiśmy przy narzędziu do kopii wolumenów Dockera, i wyraźnie luźniejszy niż AGPL. Przy narzędziu, które w wielu wdrożeniach staje się cichą częścią infrastruktury, permisywność tej licencji jest dodatkowym argumentem — nie ma tu żadnego scenariusza, w którym korzystanie z Syncthinga rodzi obowiązek pokazania komukolwiek własnego kodu.