Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
Le Panthéon de la Souveraineté — Infrastructure cloud modulaire, redondante et 100% souveraine pour s'affranchir des GAFAM. Guides techniques, architecture Zero-Trust et chiffrement interne (DoT/DoH) | Kitploit
أدوات/GitLabGitLab/schroeder-sys/pantheon-souverainete
Cloud Infrastructure SecurityEncryption/Decryption ToolsConfiguration AuditingNetwork SecurityCloud SecurityDevSecOpsPrivacyIdentity & Access Management (IAM)Learning & EducationCurated ResourcesDNS Analysis
66منذ يوم واحدلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
GitLabschroeder-sys/pantheon-souverainete

Le Panthéon de la Souveraineté

Infrastructure cloud modulaire, redondante et 100% souveraine pour s'affranchir des GAFAM. Guides techniques, architecture Zero-Trust et chiffrement interne (DoT/DoH)

عرض المستودع
مشاركة
المحتوى غير متوفر باللغة المطلوبة. عرض النسخة الإنجليزية.

🏠 Developed on: GitLab · 🪞 Mirror: GitHub · 🌐 Website: pantheon-souverainete.eu

🏛️ The Pantheon of Sovereignty

A 100% sovereign, redundant and secure cloud infrastructure, designed to break free entirely from the GAFAM. Version 2.1.0-alpha — Full structural overhaul. Starting from scratch.

Version Status License Stack Site


📋 Table of Contents

  1. A word about the silence
  2. Philosophy & Methodology
  3. Architecture (12 Deities)
  4. Trust Tiers & Dependencies
  5. Affiliate Links
  6. Documentation & Guides
  7. Prerequisites & Contacts
  8. Roadmap
  9. Licenses

🙏 A word about the silence (2 months)

I owe you an apology. The project has not progressed publicly over the past 2 months.

The truth: it was not an abandonment. I worked under the radar on a complete structural overhaul. V1.x had shaky foundations, so I made the decision to start over from a blank page rather than patch things up.

Concrete proof that the project is alive: the showcase website is online (pantheon-souverainete.eu).

Lesson learned: I no longer promise specific dates. The guides will arrive "when they're ready".


🧠 Philosophy & Methodology

Versioning & History

Important note: The earlier versions (1.0.0, 1.1.0) were alphas before the suffix was formally adopted. No stable version has ever been released — everything is in alpha.

VersionStatusDescription
v1.x❌ OutdatedInitial architecture, guides published as they went
v2.1.0-alpha🚧 In progressFull structural overhaul. Starting from scratch.

🤔 Philosophy on Forks

Recurring question: "Why do you use [X] rather than its fork [Y], which is more popular in the self-hosted community?"

My answer: I deliberately limit the use of forks. A fork creates a structural lag in updates relative to the upstream project, which can introduce security vulnerabilities or incompatibilities.

I only favour a fork if it brings a SIGNIFICANT gain in:

  • ✅ Security (audited code, vulnerabilities fixed faster)
  • ✅ Privacy (telemetry removed, privacy-first features)

In all other cases: I stick with the upstream project.

Example 1: Debian > Ubuntu

CriterionDebianUbuntu
OriginSourceFork of Debian
Stability✅ Rock-solid (rigorous testing)⚠️ Sometimes regressions
Security patches✅ Direct (Debian Security team)⚠️ Delay (Canonical has to merge)
PhilosophyCommunity-driven, soberCommercial, "user-friendly"

Why Debian?

"We can't afford to wait for a patch on the system itself. It's a matter of security and stability."


Example 2: AmneziaWG > WireGuard (kernel)

CritèreWireGuardAmneziaWG
OriginSource protocolWireGuard kernel fork
Obfuscation❌ No✅ Native (anti-DPI)
ConfidentialityExcellent✅ Even better
Collaboration—✅ Works with the WireGuard team

Why AmneziaWG?

"A deliberate fork because of the significant gain in confidentiality (anti-DPI obfuscation). Moreover, the Amnezia team works closely with WireGuard — it's not a 'wild' fork."


Example 3: Bitwarden > Vaultwarden

CritèreBitwarden (official)Vaultwarden (fork)
OriginSource projectRust fork (lightweight)
Clients✅ Official⚠️ Uses Bitwarden clients
Compatibility✅ Guaranteed⚠️ Incompatibility windows
Synchronized updates✅ Yes❌ No (possible lag)

Why Bitwarden and not Vaultwarden?

"Vaultwarden itself states that there may be incompatibility windows where the server is inaccessible to official Bitwarden clients. Beyond security, there is a real compatibility issue. I prefer the official version."


In summary:

  • ✅ Debian (source) > Ubuntu (fork) — System stability & security
  • ✅ AmneziaWG (fork) > WireGuard — Confidentiality gain (obfuscation)
  • ✅ Bitwarden (source) > Vaultwarden (fork) — Compatibility & security

Hosting & Sovereignty

  • Primary: Infomaniak (Switzerland) — Data in Switzerland, signed DPA, genuine environmental commitment
  • Backups: Hetzner (Germany & Finland) — Cold storage replicated across 2 DCs
  • Golden rule: No data rests on a single site.

Can I use V1 while waiting for V2.1?

Technically: Yes, the HS-02 (Firewall) and HS-03 (Gold Image) guides are technically valid.

In practice: ❌ No, it is not recommended.

Why?

  • Only 2 of the 3 Special Editions were published in V1 (HS-01 missing)
  • Security has been entirely rethought for V2.1
  • New security tools will be integrated (e.g., Lynis for hardening audits)
  • The V1 guides are therefore outdated in practice

Recommendation: Wait for the publication of the V2.1 guides for an optimal experience.

Author Profile & Transparency

I am not a certified IT professional. This project is the result of a passion for system administration, built through self-training over ~5 years.

  • Risk of error: I rely on official documentation, but I am not immune to mistakes.
  • AI assistance: The documentation and architecture benefit from AI assistance, but every command is human-verified.
  • Ethical stance: Immediate abandonment of any tool whose privacy policy is questionable.

📒 This project is a shared technical logbook.

This is my personal infrastructure, built in my free time and for my own needs. I document it and share it because I hope it can help others in their journey toward digital sovereignty.

The guides progress at my own pace — when I have time available. If the content helps you or inspires you, I am sincerely glad. If the publication pace or certain technical choices don't suit you, I completely understand: everyone has their own constraints, priorities and vision.

The goal remains simple: to pass on what I learn, in my own way, without pretension.

Limitation of Liability

Educational and personal project. The guides are provided "as is", without express or implied warranty.

  • No Guarantee of Accuracy: The author does not guarantee the absence of errors or future incompatibilities.
  • Security & Vulnerabilities: No architecture is "vulnerability-free." The guides reflect the best of my knowledge as of their writing date.
  • Deployment Responsibility: It is imperative to test any procedure in an isolated environment before production. The administrator assumes full responsibility for the security of their data.

🗺️ Architecture: The 12 Deities

⚠️ Important V2.1: All deities are undergoing revision/reintegration into the new architecture.

تنزيل الأداة