Найкращий п'ятишаровий самостійно розміщений стек приватності

У березні 2025 року Krebs on Security повідомив що федеральні слідчі США пов'язали крадіжку криптовалюти на $150 мільйонів безпосередньо зі зламом LastPass 2022 року. Механізм був простий: деякі клієнти зберігали seed-фрази в LastPass Secure Notes, зловмисники отримали зашифровані резервні копії сховищ, а слабкий чи старіший захист сховищ дозволив зламати частину вмісту сховищ офлайн.

Урок не в тому, що LastPass був унікально недбалим. Урок у тому, що кожен злам, про який ви читаєте, це чиїсь дані, які монетизують, поки лист із вибаченнями лежить у вашій скриньці. Самостійне розміщення змінює, хто може зробити таке з вашими даними. Воно не змінює того факту, що хтось завжди може.

Цей допис для читачів, чия модель загроз це комерційне розкриття даних, тобто монетизація Big Tech і злами постачальників, а не стеження державного рівня, журналістика високого ризику, активізм чи юридичне розкриття. Архітектура нижче це п'ятишаровий стек саме для цієї моделі загроз.

Коротко

Цей стек має п'ять шарів. Кожен шар прибирає одну поширену залежність від Big Tech, але жоден із них не робить вас невидимими.

• Мережа: WireGuard замінює комерційний VPN і обмежує видимість для провайдера чи локальної мережі.
• Ідентичність: Vaultwarden замінює розміщені менеджери паролів і зменшує ризик зламу на боці постачальника.
• Пошук: SearXNG зменшує профілювання пошуку, пропускаючи запити через ваш VPS і тримаючи їх поза вашим обліковим записом пошуку, у який ви ввійшли.
• Файли й фото: Nextcloud AIO та Immich замінюють Google Drive і Google Photos, скорочуючи сканування хмарного вмісту й об'єднання даних між продуктами.
• Командні комунікації: Mattermost чи Rocket.Chat переносять історію командного чату зі Slack, Discord чи Teams.
• Головні обмеження: Ваш постачальник VPS усе ще може бачити метадані інфраструктури, ваш провайдер усе ще може бачити, що ви під'єднуєтесь до свого сервера, і цей стек не побудований для супротивників державного рівня.
• Примітка щодо юрисдикції: Хостинг у ЄС посилює аргумент про суверенітет даних, але це не чарівний щит.

Самостійне розміщення зміщує довіру, воно її не прибирає

Існує давня суперечка на Hacker News, і вона правильна на перший погляд: "самостійне розміщення на VPS не вирішує приватність, ви просто довіряєте іншому постачальнику." Кожен, хто проєктує архітектуру приватності, має взаємодіяти з цим напряму, а не обходити це. Чесна відповідь у тому, що зміщення довіри асиметричне. Воно не еквівалентне.

Почніть з того, що самостійне розміщення зменшує. Бізнес-модель вашого SaaS-постачальника більше не полягає в добуванні ваших даних, бо постачальника немає. Ризик зламу на боці постачальника змінює форму: сховище Vaultwarden зашифроване на стороні клієнта, але сервіси, читабельні на сервері, як-от Nextcloud, Mattermost і Rocket.Chat, усе одно потребують належного загартування, резервних копій і контролю доступу.

Урок LastPass не в тому, що шифрування сховищ ніколи не існувало. Він у тому, що вкрадені зашифровані резервні копії сховищ, незашифровані метадані, старіші налаштування KDF і слабкі майстер-паролі створили шлях для офлайн-злому. Поведінкове профілювання між сервісами також зменшується, бо менше міжсервісних даних, які одна компанія може зібрати. Прив'язка до підписки спадає.

Тепер, що самостійне розміщення не усуває. Гіпервізор вашого постачальника VPS може, в принципі, читати пам'ять вашої VM. Ваш постачальник VPS бачить метадані рівня інфраструктури: до яких IP ви під'єднуєтесь, коли і скільки даних рухається.

Ваш провайдер усе ще бачить, що ви під'єднуєтесь до свого сервера. Юрисдикційні юридичні запити все одно застосовуються на рівні постачальника VPS, а судове рішення це все одно судове рішення. Скомпрометований VPS, застосунок, база даних чи обліковий запис адміністратора все одно можуть розкрити дані.

Математика довіри це те, що має значення. Постачальник VPS має менший комерційний стимул добувати ваші дані, ніж Google чи Meta, бо місячна плата і є бізнес-моделлю, а ваші дані ні. Постачальник VPS має менше агрегованих даних про вас, а саме ваш один сервер, а не вашу історію пошуку, історію місцезнаходжень і скриньку разом.

У ЄС постачальник працює під GDPR і конкретними договірними умовами. Ніщо з цього не робить VPS безпечнішим за Google у кожному вимірі. Це інша модель загроз з іншим профілем розкриття, і для моделі загроз, яку розглядає цей допис, це значуще покращення.

Є ще одна відмінність, щодо якої варто бути точним. Приватність це "вони не знають, що я роблю". Анонімність це "вони не знають, що це роблю я". Самостійне розміщення на комерційному VPS покращує приватність від SaaS-постачальників і сторонніх платформ.

Воно не дає вам анонімності від вашого постачальника VPS. Якщо вам потрібна анонімність, ви використовуєте Tor, а не VPS, і решта цього допису це неправильний інструмент.

Ключовий висновок розділу: VPS зміщує вашу довіру від SaaS-постачальника, чия бізнес-модель це монетизація ваших даних, до постачальника інфраструктури, чия бізнес-модель це продаж вам сервера. Для моделі загроз більшості читачів це значуще покращення, але це не невидимість.

П'ятишаровий стек одним поглядом

П'ять шарів, розгорнуті в такому порядку: мережа, ідентичність, пошук, файли, комунікації. Кожен адресує окрему загрозу. Ви можете розгортати їх поетапно, і ви можете пропускати шари, що не стосуються вас. Модель корисніша за список застосунків, бо масштабується з вашими занепокоєннями, а не з кількістю сервісів, що працюють на вашому сервері.

Ключовий висновок розділу: Почніть з WireGuard, Vaultwarden і SearXNG, якщо хочете найлегший стек приватності. Додавайте Nextcloud, Immich і командний чат лише після того, як будете готові до вищого використання RAM, планування сховища, резервних копій і більшого обсягу адмінської роботи.

Шар 1: мережевий шар (WireGuard)

Конфігураційний файл WireGuard для типового налаштування з одним користувачем складається з дванадцяти рядків. Його рукостискання завершується за один прохід і використовує фреймворк протоколу Noise. Модуль ядра входить до mainline Linux із версії 5.6, що означає, що протокол, який ви розгортаєте у 2026 році, той самий, що пройшов аудит і був стабільним роками. Це правильне значення за замовчуванням.

Що адресує цей шар: провайдер і спостерігачі в локальній мережі, які інакше бачили б кожен домен, до якого ви під'єднуєтесь, зловмисники в публічному Wi-Fi і ваш домашній IP, що розкривається кожному сервісу, який ви відвідуєте. Ваш трафік виходить з вашого VPS, а не з вашої квартири.

Що він не адресує: погляд вашого постачальника VPS на ваш вихідний трафік. Вони бачать, до чого під'єднується ваша кінцева точка VPN, коли і скільки. WireGuard приховує трафік від вашого провайдера. Він не приховує трафік від сервера, який керує виходом.

Витоки DNS це також окрема проблема, яка не обробляється автоматично; вам треба спрямувати ваших VPN-клієнтів на резолвер, якому ви довіряєте. Запустіть Unbound на тому ж VPS або використовуйте довірений upstream через DoT чи DoH. Повне блокування реклами на рівні DNS з Pi-hole це окрема тема й не те, що варто поєднувати з вихідним вузлом VPN для більшості користувачів (докладніше про це нижче).

WireGuard проти альтернатив, коротко. OpenVPN усе ще працює. Рукостискання більше, відбиток метаданих більший, а пропускна здатність нижча. Немає причин обирати його для нового розгортання, якщо вам конкретно не потрібна функція, якої WireGuard не пропонує.

Tailscale це інший інструмент: це mesh без конфігурації, побудований на WireGuard, і він чудовий для зшивання ваших власних самостійно розміщених сервісів між машинами. Це не те, що вам потрібно як вихідний вузол приватності в інтернет, бо площина координації розміщена Tailscale.

Примітка: зміна стандартного порту 51820/UDP може зменшити сканування з низькими зусиллями, але вона не робить WireGuard схожим на звичайний HTTPS-трафік і не обходить серйозну фільтрацію. Сприймайте це як зменшення сканування, а не як скритність.

Для розгортання в нас є покроковий посібник із налаштування WireGuard для Ubuntu що поєднується з цією архітектурою.

Ключовий висновок розділу: WireGuard на вашому VPS дає вам вихідний вузол приватної мережі, який ваш провайдер не може інспектувати, але він не приховує ваш трафік від постачальника VPS, що керує виходом.

Шар 2: шар ідентичності (Vaultwarden)

Vaultwarden працює менш ніж на 200 МБ RAM. Це реалізація API Bitwarden на Rust, сумісна з кожним офіційним клієнтом Bitwarden (розширення для браузерів, десктопні застосунки, мобільні застосунки), і вона не потребує важкого еталонного образу сервера Bitwarden. Для одного користувача чи домогосподарства це правильний розмір.

Що адресує цей шар: зломи паролів на боці постачальника, як-от збій у стилі LastPass, де вміст сховищ витік і зрештою був розшифрований офлайн. Повторне використання облікових даних між сервісами стає механічно складнішим, щойно у вас є менеджер паролів, яким ви справді користуєтесь. Агрегація профілю ідентичності між сервісами спадає, бо жодна третя сторона не бачить список.

Що він не адресує: ваш власний OpSec. Слабкий майстер-пароль, відсутність 2FA на сховищі чи успішна фішингова атака на вас повністю руйнує цей шар. Скомпрометований пристрій з браузерним розширенням, у яке ви ввійшли, руйнує його ще повніше. Vaultwarden це сховище, а не заміна базовим речам.

Є одне експлуатаційне попередження, що важить більше за будь-яке інше в цьому стеку. Самостійне розміщення вашого менеджера паролів означає, що ви відповідаєте за резервні копії. VPS, що дає збій у невдалий момент, чи сервер, який ви випадково затерли, замикає вас від кожного облікового запису, який захищає цей шар.

XDA Developers також висвітлив цей ризик напряму, попереджаючи, що самостійно розміщений менеджер паролів може замкнути вас від важливих облікових записів, якщо доступ, резервні копії чи планування відновлення дадуть збій.

Попередження: запускайте автоматизовані зашифровані резервні копії каталогу даних Vaultwarden. Тримайте зашифрований офлайн-експорт, зберігайте коди відновлення окремо й тестуйте відновлення на запасному пристрої чи тимчасовому контейнері. Не покладайтеся на одну резервну копію VPS. Це не опціонально. Це ціна винесення сховища з інфраструктури постачальника.

Якщо ви централізуєте єдиний вхід (single sign-on) між кількома самостійно розміщеними сервісами пізніше, Authentik це постачальник ідентичності з відкритим кодом, до якого більшість людей зрештою приходять. Це просунутий шар і поза межами основного стека.

Для розгортання наш посібник із самостійного розміщення Vaultwarden є супутником із розгортання. Для глибшого погляду на ландшафт менеджерів паролів див. наш посібник про найкращі самостійно розміщені менеджери паролів.

Ключовий висновок розділу: Vaultwarden виносить ваше сховище паролів із вразливої до зламів інфраструктури постачальника, але перекладає тягар резервних копій і відновлення на вас, і цей тягар реальний.

Шар 3: шар пошуку й перегляду (SearXNG)

Екземпляр SearXNG отримує ваш запит, розгалужує його до upstream-рушіїв (Google, Bing, DuckDuckGo та інших, які ви ввімкнете), прибирає деякі ідентифікаційні параметри й повертає уніфіковану сторінку результатів.

Ваші запити досягають Google, але вони досягають Google як запити з вашого VPS, а не з вашого облікового запису пошуку, у який ви ввійшли. Екземпляр з одним користувачем не створює великого пулу анонімності, тож upstream-рушії все одно можуть пов'язувати шаблони запитів із цим IP вашого VPS.

Що адресує цей шар: профілювання пошукових запитів, поведінкове націлювання реклами, прив'язане до вашої історії пошуку, у яку ви ввійшли, і довгу пам'ять облікового запису пошуку. Проблема "чому я бачу рекламу того, що шукав учора" зменшується на рівні облікового запису пошуку.

Що він не адресує: відстеження сайтами, на які ви справді переходите. Куки, фінгерпринтинг і трекери на сторонніх сторінках це проблема на боці браузера, а не на боці пошуку. Використовуйте загартовану конфігурацію браузера, щоб адресувати це.

SearXNG також не анонімізує вас від upstream-пошуковика, якщо ваш VPS надсилає йому лише ваші запити; агрегований трафік від завантаженого екземпляра ховає окремих користувачів у шумі, але екземпляр з одним користувачем усе одно може виглядати як шаблон пошуку одного користувача.

Whoogle Search це легша альтернатива. Це фронтенд для Google, простіший і робить одну річ. SearXNG агрегує кілька рушіїв, що корисніше, якщо ваша причина залишити Google була не конкретно в Google. Обирайте на основі того, скільки джерел ви насправді хочете.

Одна експлуатаційна примітка для екземплярів з одним користувачем. SearXNG пересилає запити upstream-рушіям, а Google може обмежувати частоту підозрілих шаблонів трафіку. Один користувач рідко на це натрапляє. Невеликий публічний екземпляр може. Якщо запити починають давати збій, зменшіть кількість upstream-рушіїв, налаштуйте параметри обмежувача SearXNG або більше спирайтеся на менш ворожі upstream-рушії.

Ключовий висновок розділу: SearXNG пропускає ваші пошуки через ваш VPS і тримає їх поза вашим обліковим записом пошуку, у який ви ввійшли. Він зменшує пряме профілювання пошуку, але приватний екземпляр з одним користувачем не створює великого пулу анонімності.

Шар 4: шар файлів і фото (Nextcloud AIO + Immich)

Nextcloud AIO це універсальне розгортання Nextcloud у Docker і шлях найменшого опору до робочого сервера синхронізації файлів, календаря, контактів і спільної роботи з документами.

Immich це фотографічний аналог: перегляд у вигляді стрічки часу, мобільне автозавантаження з iOS та Android, розпізнавання облич у стилі Google Photos, оброблене на вашому власному сервері чи обраному ML-хості, і чесний консенсус спільноти, що це найзручніша заміна Google Photos, яка зараз існує.

Це не легкі застосунки. Nextcloud AIO слід сприймати як базову лінію 4 ГБ / 2 vCPU; машинне навчання Immich, генерація мініатюр і перше сканування бібліотеки використають усе, що ви їм дасте.

Що адресує цей шар: сканування постачальником хмарного сховища, розпізнавання вмісту фото й обробка на боці хмари, що тримають чутливу особисту бібліотеку всередині облікового запису постачальника, і централізацію даних на рівні облікового запису, що тримає файли, фото, пошук, історію місцезнаходжень та сигнали ідентичності під одним обліковим записом компанії.

Заміна цього сервером, який ви контролюєте, ламає цю централізацію.

Що він не адресує: байти все одно живуть на томі сховища, яким керує ваш постачальник VPS. Шифрування у спокої це ваша відповідальність, а не їхня за замовчуванням. Компрометація на боці пристрою це окрема проблема; якщо ваш телефон рутований, клієнт Nextcloud на ньому розкритий незалежно від того, де живе сервер.

Якщо ваша єдина потреба це "тримати ці папки синхронізованими між моїми пристроями", Syncthing це простіший інструмент. Він peer-to-peer, не має сервера посередині й робить цю одну роботу добре. Це не заміна функцій календаря, контактів і співпраці, які надає Nextcloud; це заміна підмножини синхронізації файлів.

Для Immich конкретно одне практичне правило підбору має значення. Nextcloud AIO слід сприймати як базову лінію 4 ГБ / 2 vCPU. Immich не є легким фото-додатком, щойно машинне навчання, мініатюри й перше сканування бібліотеки входять у картину. Плануйте близько 6–8 ГБ RAM для налаштувань, насичених Immich, особливо під час міграції.

Для розгортання в нас є порівняння Nextcloud проти ownCloud для користувачів, які все ще обирають між цими двома, і ширший огляд самостійно розміщених хмарних платформ із вебінтерфейсом якщо ви досліджуєте цей простір.

Ключовий висновок розділу: Nextcloud та Immich можуть винести файли й фото з хмарних облікових записів у стилі Google, але це перший шар у цьому стеку, що потребує серйозної RAM, сховища, планування резервних копій і терпіння щодо міграції.

Шар 5: шар комунікацій (Mattermost чи Rocket.Chat)

Робочі простори Slack доступні для пошуку самим Slack. Discord сканує вміст на порушення ToS. Microsoft Teams зберігає записи чату згідно з політиками вашого тенанта, а це політики, які може бачити ваш IT-відділ.

Для командного чи сімейного чату, який не повинен жити в жодному з цих місць, самостійно розміщений Mattermost чи Rocket.Chat це стандартна відповідь. Цей шар про тримання командних архівів поза SaaS, а не про приватний наскрізний чат.

Що адресує цей шар: архівування повідомлень на боці постачальника, сканування вмісту на боці постачальника й втрату доступу, що стається, коли постачальник вирішує, що ваш обліковий запис це проблема. Історія повідомлень вашої команди сидить на вашому сервері.

Що він не адресує, і це важливо: наскрізне шифрування. Mattermost і Rocket.Chat не E2EE за замовчуванням. Адміністратор сервера може читати повідомлення. Адміністратор сервера тепер це ви, що краще, ніж коли це співробітники SaaS-постачальника, але принцип усе одно важить для моделі загроз вашої команди.

Для безпечного обміну повідомленнями один на один Signal це правильна відповідь, а не самостійно розміщений сервер. Якщо шар комунікацій має бути E2EE за замовчуванням, погляньте на Matrix/Element або використовуйте Signal для особистих чатів. Самостійне розміщення вирішує командний обмін повідомленнями без постачальника; воно не замінює Signal для особистих моделей загроз.

Mattermost проти Rocket.Chat. Обидва чинні. Mattermost щільніший, більш орієнтований на підприємства й має менше опціональних функцій, увімкнених за замовчуванням. Rocket.Chat ширший, інтегрує більше типів каналів і має більшу екосистему плагінів. Будь-який підходить для типового випадку стека приватності для малої команди чи сімейного чату.

Застереження 2026 року: Перевірте точну безкоштовну редакцію перед розгортанням Mattermost. Mattermost Entry має ліміт історії у 10 000 повідомлень, тоді як Team Edition уникає цього ліміту, але має власні обмеження. Для Rocket.Chat закладайте більше, ніж крихітний VPS на 1 ГБ, бо MongoDB, завантаження й інтеграції додають накладні витрати.

Ключовий висновок розділу: Самостійно розміщений Mattermost чи Rocket.Chat виносить архів чату вашої команди від SaaS-постачальника, але якщо вам потрібне справжнє наскрізне шифрування між двома людьми, Signal усе ще правильний інструмент.

Що НЕ варто розміщувати самостійно (і чому)

Деякі речі, що виглядають так, ніби належать до стека приватності, насправді не належать. Перелік їх це частина побудови стека, вартого довіри.

Електронна пошта. Не розміщуйте електронну пошту самостійно, якщо ви ще не досвідчений оператор Linux, який конкретно цього хоче. PrivacyGuides має чітку й добре відому позицію щодо цього, і вона правильна: лише просунуті користувачі мають запускати власний поштовий сервер. Причини не в технічній цікавості. SPF, DKIM і DMARC мають бути налаштовані й підтримуватися правильними.

Репутацію IP треба заробити й підтримувати. Фільтрація спаму це постійний стан справ. Боротьба за доставлюваність з Gmail це не крок налаштування; це постійна умова. Для всіх інших керований провайдер, що поважає приватність, це справді правильна відповідь для цього шару.

Proton Mail, Tuta (раніше Tutanota) і Mailbox.org усе це хороші варіанти. Це жорстке правило цього допису: не розміщуйте електронну пошту самостійно для приватності загальної аудиторії.

Pi-hole як основний DNS-резолвер вашої домашньої мережі, на VPS. Pi-hole чудовий. Розміщення його на VPS як рекурсивного резолвера для всього інтернету вашого домогосподарства це єдина точка відмови, що ламає інтернет для всіх у домі, коли VPS дає збій. Pi-hole належить на Raspberry Pi вдома. Він не є частиною цього стека.

Федерована соціальна медіа. Mastodon, Pleroma та решта цікаві й суміжні. Прийняття це головне обмеження, а не приватність. Вони правильна відповідь для деяких людей, але не основні для стека приватності, зосередженого на виведенні ваших власних даних із серверів Big Tech.

Інструменти анонімності. Tor, I2P, mixnets. Інша модель загроз, інший допис. Якщо вони вам потрібні, ви вже знаєте.

Підсумок: Proton Mail чи його аналог це керована альтернатива для одного конкретного шару, і визнання цього є частиною стека, вартого використання. Самостійне розміщення допомагає там, де ці провайдери не покривають повний робочий процес: фото, пошук, кастомна аналітика й командний чат. Для приватності загальної аудиторії електронна пошта це той єдиний шар, який цей стек має віддати на аутсорс.

Ключовий висновок розділу: Більшості користувачів не варто розміщувати електронну пошту самостійно. Керований провайдер, що поважає приватність, як-от Proton Mail, це справді краща відповідь для цього одного шару, і визнання цього є частиною побудови надійного стека.

Де його запускати: підбір VPS і юрисдикція

Питання підбору не абстрактне. Цей стек має три практичні форми: легке ядро приватності, шар файлів і насичена фото версія, що приносить машинне навчання Immich у суміш. Стрибок від однієї до наступної не косметичний. Файли, мініатюри, розпізнавання облич і перша міграція бібліотеки це те, що перетворює малий VPS на повноцінний серверний бюджет.

Читайте таблицю так:

• Мінімальний стек покриває три шари з найвищою віддачею: мережа, ідентичність і пошук.
• Базова лінія Nextcloud потребує більше запасу, бо PHP, робота з базою даних, індексація файлів, завдання синхронізації й вебінтерфейс усі працюють разом.
• Стек файлів і фото потребує більшого бюджету, бо машинне навчання Immich, мініатюри, розпізнавання облич і перше сканування фотобібліотеки можуть сильно навантажити сервер під час міграції.
• Сховище має значення, бо обчислення це лише половина плану. Файли й фото потребують місця для росту, резервних копій подалі від VPS і шляху відновлення, що все ще працює, якщо сервера немає.

Потім є юрисдикція. У червні 2025 року Microsoft свідчила перед французьким парламентом що вона не може гарантувати, що дані, розміщені в ЄС, будуть захищені від юридичного доступу США. Це свідчення вивело аргумент про суверенітет даних з теорії в мейнстримну політичну розмову.

Для користувачів, що пріоритезують суверенітет даних, юрисдикція компанії, розташування дата-центру, контракти, модель шифрування й розташування резервних копій усе має значення.

If Закон CLOUD Act розкриття є частиною занепокоєння, не сприймайте дата-центр у ЄС сам собою як повну відповідь. Постачальник зі штаб-квартирою не в США з європейським регіоном підходить чистіше, ніж європейський регіон гіперскейлера зі штаб-квартирою в США, але це все одно не робить дані юридично недоторканними.

Застереження: Юрисдикція це тертя, а не невразливість. Німецьке судове рішення це все одно судове рішення. Голландське теж. І швейцарський юридичний запит також. Європейський хостинг може зменшити деяке пряме розкриття для хмарних постачальників зі штаб-квартирою в США й додати локальний юридичний процес, але він не робить дані юридично недоторканними.

Для моделі загроз більшості читачів додане тертя корисне. Це не чарівний щит.

Ключовий висновок розділу: Легкий стек може працювати на малому VPS, але файли й фото змінюють бюджет. Використовуйте 4 ГБ / 2 vCPU як базову лінію лише для Nextcloud і плануйте ближче до 8 ГБ / 4 vCPU для насиченого фото налаштування Immich. Cloudzy Marketplace знижує зусилля на налаштування для основних застосунків, тоді як юрисдикція додає юридичне тертя, а не невидимість.

Як розгорнути стек, не перетворивши налаштування на проєкт

Ви можете побудувати кожен шар вручну. Це нормально, якщо робота з налаштування є частиною привабливості. Для більшості читачів це не так. Сенс цього стека в тому, щоб піти від гравітації даних Big Tech, а не витратити тиждень на налагодження Docker, портів, DNS і файлів сервісів, перш ніж запуститься перший застосунок.

Шлях із меншим тертям це почати з робочого образу VPS і загартувати звідти. Cloudzy Marketplace включає образи VPS в один клік для WireGuard, Vaultwarden, SearXNG, Nextcloud AIO та інших самостійно розміщених інструментів, тож базове розгортання не є тією частиною, що з'їдає вихідні.

Робота, що все ще має значення, це робота, яку жоден marketplace не може зробити за вас: DNS, правила фаєрвола, резервні копії, контроль доступу, оновлення й тестування відновлення.

Сервер унизу теж усе ще має значення. Цей стек це сховище, мережа, вибір регіону й запас, а не лише назви застосунків у таблиці. Cloudzy дає вам інфраструктуру VPS на NVMe, повний кореневий доступ, 13 регіонів, мережу 40 Gbps, аптайм 99,95% і 14-денний період повернення коштів.

Починайте з малого для WireGuard, Vaultwarden і SearXNG. Піднімайтеся вгору для Nextcloud. Плануйте серйозніше для Immich, щойно машинне навчання, мініатюри й міграція фото входять у картину.

Як почати

П'ять шарів, кожен адресує конкретну загрозу. Жоден із них не претендує на те, щоб зробити вас невидимими. Усі вони зменшують конкретне комерційне розкриття даних, яке ви зараз приймаєте за замовчуванням.

Оберіть той один шар, що адресує ваш найбільш конкретний поточний біль. Якщо ви будь-коли відкривали лист-сповіщення про злам, це шар ідентичності. Якщо ви помічали рекламу, що йде за вами через сайти, які ви ніколи не відвідували, це шар пошуку. Розгорніть саме той. Архітектура масштабується. Рішення почати не мусить.

Налаштування будь-якого окремого шару займає щонайбільше вихідні. Конфігураційні файли короткі. Немає причин, щоб це було складніше за це.

Часті запитання

Чи самостійне розміщення на VPS справді захищає мою приватність, чи я просто довіряю іншому постачальнику?

Так, для цієї моделі загроз. Воно зміщує довіру від SaaS-постачальників, що монетизують дані користувачів, до постачальника VPS, що продає інфраструктуру. Це зменшує комерційне розкриття й міжсервісне профілювання, але не приховує метадані VPS, записи про з'єднання провайдера, скомпрометовані пристрої чи стеження державного рівня.

Який мінімальний самостійно розміщений стек приватності мені варто почати?

Почніть з WireGuard, Vaultwarden і SearXNG. Вони покривають видимість мережі, ризик зламу постачальника паролів і профілювання пошуку, у який ви ввійшли, на VPS з 2 ГБ RAM. Додайте Nextcloud пізніше; додайте Immich лише після того, як у вас буде більше RAM, сховища й дисципліни щодо резервних копій.

Чи хостинг у Франкфурті чи Амстердамі справді кращий для приватності, ніж у США?

Європейські регіони можуть зменшити деяке пряме розкриття для постачальників зі штаб-квартирою в США, але вони не роблять дані юридично недоторканними. Юрисдикція компанії, розташування дата-центру, контракти, шифрування й розташування резервних копій усе має значення. Німецькі, голландські чи швейцарські юридичні запити все одно можуть застосовуватися.

Чи варто мені розміщувати свою електронну пошту самостійно заради приватності?

Майже для всіх ні. Самостійне розміщення електронної пошти потребує SPF, DKIM, DMARC, репутації IP, фільтрації спаму й постійної роботи над доставлюваністю. Використовуйте керованого провайдера, що поважає приватність, як-от Proton Mail, Tuta чи Mailbox.org. PrivacyGuides рекомендує самостійно розміщену пошту лише для просунутих користувачів.

Від чого WireGuard насправді мене захищає?

WireGuard маршрутизує трафік через ваш VPS, обмежуючи те, що можуть бачити ваш провайдер і локальна мережа. Він не приховує вихідний трафік від постачальника VPS. Вони все одно можуть бачити метадані з'єднань, IP призначення, час і обсяг. Це приватність від вашого провайдера, а не невидимість.