Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
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
Herramientas/GitLabGitLab/schroeder-sys/pantheon-souverainete
Cloud Infrastructure SecurityEncryption/Decryption ToolsConfiguration AuditingNetwork SecurityCloud SecurityDevSecOpsPrivacyIdentity & Access Management (IAM)Learning & EducationCurated ResourcesDNS Analysis
66hace 1 díaAún no revisado
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)

Ver Repositorio

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
Contenido no disponible en el idioma solicitado. Mostrando versión en inglés.

🏠 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.

Descargar herramienta